From daemon Wed Oct 21 10:09:08 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA09381 for vsta-xplod; Wed, 21 Oct 1998 10:09:08 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA09375 for ; Wed, 21 Oct 1998 10:09:06 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA11651; Wed, 21 Oct 1998 14:11:31 -0700 (PDT) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id OAA03287; Wed, 21 Oct 1998 14:11:31 -0700 (PDT) Message-Id: <199810212111.OAA03287@vandys-pc.cisco.com> To: villapla@si.uji.es cc: vsta@zendo.com Subject: Re: Strange diff behaviour In-reply-to: Your message of "Wed, 21 Oct 1998 22:56:23 +0200." <199810212056.WAA15545@nuvol.uji.es> Date: Wed, 21 Oct 1998 14:11:31 -0700 From: Andy Valencia ["Juan Jose Villaplana Querol" writes:] >Let be a directory with two (different) text files and an executable, >the diff command reports correctly the differences betweent the text >files, but after executing the executable located in this directory the >diff command does not work. If the executable is removed, diff recovers >its normal behaviour. Hmm, what kind of filesystem is underneath this directory? /tmp by any chance? Perhaps I made a mistake in the page caching or something. I may not have noticed, since I hardly ever run programs off of /tmp, and even then perhaps not more than once. I'll double check when I get home tonight, but I'm pretty sure I run and re-run diff many times without problems from DOS and vstafs filesystems. Andy From daemon Wed Oct 21 09:57:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA09346 for vsta-xplod; Wed, 21 Oct 1998 09:57:00 GMT Received: from nuvol.uji.es (nuvol.uji.es [150.128.16.10]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA09340 for ; Wed, 21 Oct 1998 09:56:50 GMT Received: (from villapla@localhost) by nuvol.uji.es (8.8.7/8.8.5) id WAA15545; Wed, 21 Oct 1998 22:56:23 +0200 (METDST) Message-Id: <199810212056.WAA15545@nuvol.uji.es> Subject: Strange diff behaviour To: vsta@zendo.com Date: Wed, 21 Oct 1998 22:56:23 +0200 (METDST) From: "Juan Jose Villaplana Querol" Cc: villapla@nuvol.uji.es (Juan Jose Villaplana Querol) Reply-To: X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello I am currently using the last version of VSTa, and have noticed an strange thing. Let be a directory with two (different) text files and an executable, the diff command reports correctly the differences betweent the text files, but after executing the executable located in this directory the diff command does not work. If the executable is removed, diff recovers its normal behaviour. Does anyone experienced this problem? Thanks in advance Juanjo ---- Juan Jose Villaplana Querol villapla@si.uji.es Servei d'Informatica Universitat Jaume I -- SPAIN From daemon Thu Oct 22 09:37:36 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA12219 for vsta-xplod; Thu, 22 Oct 1998 09:37:36 GMT Received: from nuvol.uji.es (nuvol.uji.es [150.128.16.10]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA12213 for ; Thu, 22 Oct 1998 09:37:32 GMT Received: (from villapla@localhost) by nuvol.uji.es (8.8.7/8.8.5) id WAA16635; Thu, 22 Oct 1998 22:37:16 +0200 (METDST) Message-Id: <199810222037.WAA16635@nuvol.uji.es> Subject: Re: Strange diff behaviour To: vandys@cisco.com (Andy Valencia) Date: Thu, 22 Oct 1998 22:37:16 +0200 (METDST) From: "Juan Jose Villaplana Querol" Cc: vsta@zendo.com, villapla@nuvol.uji.es (Juan Jose Villaplana Querol) In-Reply-To: <199810212111.OAA03287@vandys-pc.cisco.com> from "Andy Valencia" at Oct 21, 98 02:11:31 pm Reply-To: X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > Hmm, what kind of filesystem is underneath this directory? /tmp by any > chance? Perhaps I made a mistake in the page caching or something. I may > not have noticed, since I hardly ever run programs off of /tmp, and even > then perhaps not more than once. This directory is under a dos filesystem (is the fs/root filesystem). > I'll double check when I get home tonight, but I'm pretty sure I run and > re-run diff many times without problems from DOS and vstafs filesystems. I think I was not clear in my previous e-mail, diff stops working only for the files located in the executable's directory. The executable may be a "Hello world" written in C, any executable copied from /vsta/bin to this directory, ... Thanks Juanjo ---- Juan Jose Villaplana Querol villapla@si.uji.es Servei d'Informatica Universitat Jaume I -- SPAIN From daemon Thu Oct 22 14:56:02 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA12841 for vsta-xplod; Thu, 22 Oct 1998 14:56:02 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA12835 for ; Thu, 22 Oct 1998 14:56:00 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA09950; Thu, 22 Oct 1998 18:58:29 -0700 (PDT) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id SAA06646; Thu, 22 Oct 1998 18:58:28 -0700 (PDT) Message-Id: <199810230158.SAA06646@vandys-pc.cisco.com> To: villapla@si.uji.es cc: vsta@zendo.com Subject: Re: Strange diff behaviour In-reply-to: Your message of "Thu, 22 Oct 1998 22:37:16 +0200." <199810222037.WAA16635@nuvol.uji.es> Date: Thu, 22 Oct 1998 18:58:28 -0700 From: Andy Valencia ["Juan Jose Villaplana Querol" writes:] > I think I was not clear in my previous e-mail, diff stops working > only for the files located in the executable's directory. The > executable may be a "Hello world" written in C, any executable > copied from /vsta/bin to this directory, ... Ah, now I can guess what's biting you. If you diff "f1" and "f2", could you try putting: sleep 20000 < f1 & sleep 20000 < f2 & and then run the diff on "f1" and "f2"? I bet you'll get the correct diff output. (Arcane filesystem rambles follow.) This goes *way* back in DOS filesystem hassles. Basically, DOS is funny in that (1) a directory may or may not exist in terms of filesystem allocation blocks (the root doesn't, but all subdirs do), and (2) a file may or may not correspond to any allocated blocks. In particular, a zero-length file has no clusters and is only known by its directory entry. diff tries to optimize by looking at the inode number of files which it'll compare. The DOS server as written just uses the "struct node" pointer as the inode number, which guarantees inode number uniqueness only until last close of the file. So I bet what you're hitting is that "diff" stat's one file, gets an inode number, closes the file, and stat's the next one. The DOS server happens to use the same malloc()'ed block, therefore the successively opened files appear to get the same inode number. Bleh. I've just fixed it in my source. Inode number is now the cluster number of the directory containing the file (or 0 for root) shifted left 16 bits, OR'ed in with the directory entry offset. This will have to be revisited for FAT-32. This also interacts with an old bug, where if you ran an executable, and then mv'ed it, you could no longer remove that executable. There's an interesting problem where if your file needs to be named by its directory entry, then your "inode number" changes when you change the name of the file (well, move it to a new directory or directory slot). Inode number is the connection used to coordinate between the kernel page cache for an executable and the filesystem server which fills in the contents of these pages. I've added code to unhash the file during the rename if it was an executable which had been previously run, so that there's no kernel state to remain consistent with. It's not good enough to insist there's no open references to a file which will be renamed--GNU "ar" holds an open file descriptor to a newly built library while it renames it from foo.a_supersede to foo.a. I've coded this all up, and it appears to work right. I should probably push out a 1.6.2 as there seems to be enough interesting fixes accumulated from 1.6.1. Andy From daemon Sat Oct 24 14:19:20 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA19981 for vsta-xplod; Sat, 24 Oct 1998 14:19:20 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id OAA19975 for ; Sat, 24 Oct 1998 14:19:17 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id VAA09709 for ; Sat, 24 Oct 1998 21:21:52 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vsta@zendo.com Date: Sat, 24 Oct 1998 21:18:44 -0400 Subject: vstafs installation Message-ID: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I am trying to set up a vstafs partition so I can work completely (well, almost completely) off of vstafs. It's been pretty smooth so far, but I'm having a strange problem with gcc (specifically gas). I compile int main(void) { return 0; } with gcc -S and get test.s. That part works fine no matter which file system I'm on. The result is: .file "test.c" gcc2_compiled.: ___gnu_compiled_c: .text .align 2 .globl _main _main: pushl %ebp movl %esp,%ebp call ___main xor %eax,%eax jmp L1 .align 2,0x90 L1: leave ret Now, when I as it under dos it works. But when vstafs is mounted as root, I get the following: GNU assembler version 2.8.1 (i386-aout-vsta) test.s: Assembler messages: test.s:8: Error: invalid character '%' before (null) operand test.s:9: Error: invalid character '%' before (null) operand test.s:10: Error: invalid character '_' before (null) operand test.s:11: Error: invalid character '%' before (null) operand perm I copied the entire directory structure from the dos to the vstafs so I know that's not the problem. I've granted read access to everyone, plus I'm running as usr.root, because I thought that vstafs's security provisions were the problem but they weren't. I've looked for capitalization problems and truncated filenames that are sometimes a problem moving from dos to vstafs, but I didn't find any. I've added debug code to both servers that log FS_OPEN calls to see what's being done differently, but I'm stumped. Also, the problem still comes up even if the .s file is located in the /tmp filesystem (which is what usually happens with the gcc front-end), you just get /tmp/cc000110.s or something like that. So it's something in the directory tree somewhere. The only thing I haven't checked out is the dos CR/LF stuff. Anyone have any ideas? From daemon Sat Oct 24 14:52:13 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA20016 for vsta-xplod; Sat, 24 Oct 1998 14:52:13 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA20010 for ; Sat, 24 Oct 1998 14:52:11 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA19846 for ; Sat, 24 Oct 1998 18:54:46 -0700 (PDT) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id SAA13836 for ; Sat, 24 Oct 1998 18:54:45 -0700 (PDT) Message-Id: <199810250154.SAA13836@vandys-pc.cisco.com> To: vsta@zendo.com Subject: ISA physical I/O support Date: Sat, 24 Oct 1998 18:54:45 -0700 From: Andy Valencia Hello, folks. I've been playing with something which has festered a long time--support for ISA DMA on systems with > 16M of memory. Right now the kernel quietly ignores memory above the ISA limit, but this drove me crazy with my 64M PC. So I've just gotten wired memory hooks set up so the bounce buffer support of the floppy driver now correctly can get a low (< 16M) memory page and handle requests from buffers in the upper 48M. page_wire() now takes a third parameter, which is flags which can be defined on a per-architecture basis. On PC/ISA, one flag is for WIRE_16M, and the PC-dependent VM will try to go grab a suitable page and make it replace any existing page. I need to do some more testing, and then apply similar changes to the SCSI support. It's kind of fun to be hacking VSTa again, after a year or so of being CPU bound on Cisco development. :-) Andy Valencia From daemon Sun Oct 25 16:31:41 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA22452 for vsta-xplod; Sun, 25 Oct 1998 16:31:41 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA22446 for ; Sun, 25 Oct 1998 16:31:38 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA24896; Sun, 25 Oct 1998 19:34:16 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id TAA15416; Sun, 25 Oct 1998 19:34:16 -0800 (PST) Message-Id: <199810260334.TAA15416@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: vstafs installation In-reply-to: Your message of "Sat, 24 Oct 1998 21:18:44 EDT." Date: Sun, 25 Oct 1998 19:34:16 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I am trying to set up a vstafs partition so I can work completely >(well, almost completely) off of vstafs. It's been pretty smooth so >far, but I'm having a strange problem with gcc (specifically gas). Hi, I've tried this a couple different ways, and am pretty sure I see at least one problem, but this problem was with the generated a.out from "ld". What it comes down to is my BSS should be 0 initialized, but instead is the string "Tempest Tempest Tempest...". This rings a bell; I had to fix a DOS filesystem bug when I brought over the newer GNU language tools. Take a look at a "rcsdiff -r1.12 -r1.13 rw.c" in vsta/src/srv/dos. I probably have the same bug in vstafs (since I wrote both filesystems, and probably cribbed from DOS when I wrote vstafs). I'll play with it some more soon, but if you have the time, it might be a fun bug to nail. Andy From daemon Mon Oct 26 13:26:15 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA24632 for vsta-xplod; Mon, 26 Oct 1998 13:26:15 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id NAA24626 for ; Mon, 26 Oct 1998 13:26:13 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id TAA10159; Mon, 26 Oct 1998 19:28:52 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Mon, 26 Oct 1998 18:25:32 -0400 Subject: Re: vstafs installation Message-ID: References: <199810260334.TAA15416@vandys-pc.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) >Take a look at a "rcsdiff -r1.12 -r1.13 rw.c" in vsta/src/srv/dos. I >probably have the same bug in vstafs (since I wrote both filesystems, and >probably cribbed from DOS when I wrote vstafs). I'll play with it some more >soon, but if you have the time, it might be a fun bug to nail. Andy, I did the rcsdiff, and it looks like it deals with the behavior when you seek beyond the end of the file. It simply writes zeros in 1024-byte chunks until the real eof catches up with the new eof. I could try to transplant this behavior to vstafs, but since this is really is supposed to create a sparse file, I am wondering if vstafs has a mechanism to deal with sparse files. All one would need to do is mark down the bytes skipped, and be sure to read in all zeros when that sparse block (or sparse extent, I guess) is read again. Eric From daemon Mon Oct 26 14:00:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA24686 for vsta-xplod; Mon, 26 Oct 1998 14:00:00 GMT Received: from rramos.ucsc.edu (root@rramos.UCSC.EDU [128.114.163.51]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA24677 for ; Mon, 26 Oct 1998 13:59:56 GMT From: rayr@rramos.ucsc.edu Received: from rramos.ucsc.edu (rayr@localhost [127.0.0.1]) by rramos.ucsc.edu (8.8.7/8.8.7) with ESMTP id QAA05330 for ; Mon, 26 Oct 1998 16:46:22 -0800 Message-Id: <199810270046.QAA05330@rramos.ucsc.edu> To: vsta@zendo.com Subject: progs under ka9q/cmd Date: Mon, 26 Oct 1998 16:46:21 -0800 how do you use inetdb, proxyd, and telnetd? the situation: the ne server is running the net server (ka9q) is running i run telnetd from the vsta$ prompt as vandys i try to telnet from a different machine. i see this: bash-2.02$ telnet reg-his Trying 128.114.163.205... Connected to reg-his.ucsc.edu. Escape character is '^]'. Welcome to VSTa v1.6.1! login: Connection closed by foreign host. bash-2.02$ and syslog shows: syslog: telnetd (pid 120) notice: IO server: all clients done what are the files r,x,y for? proxyd? From daemon Mon Oct 26 13:59:29 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA24672 for vsta-xplod; Mon, 26 Oct 1998 13:59:29 GMT Received: from malasada.lava.net (malasada.lava.net [199.222.42.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA24666 for ; Mon, 26 Oct 1998 13:59:21 GMT Received: from localhost (1446 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Mon, 26 Oct 1998 15:02:32 -1000 (HST) (Smail-3.2.0.101 1997-Dec-17 #4 built 1998-Jul-3) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: install question To: vsta@zendo.com Date: Mon, 26 Oct 1998 15:02:31 -1000 (HST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I should probably be able to figure this out, but so far no luck. I downloaded vsta, unpacked it on my system on the second partition. I made a grub floppy. I used the following commands: root=(hd0,4) kernel=/vsta/boot/vsta module=/vsta/boot/cons module=/vsta/boot/namer module=/vsta/boot/wd d0:readp module=/vsta/boot/dos -p disk/wd:wd0_dos0 fs/root module=/vsta/boot/init boot and processes 7 dies (dos). I tried booting with testsh instead of init and mounted namer and eventually wd to find that there is indeed a disk/wd entry in namer and a wd0_dos0 partition existed in the wd driver. I dont see any syslog messages from the dos driver. I have partitions for wd0_p0 (fat32 partition) and wd0_dos0 (fat16 partition on which vsta resides). The fat16 drive has long filenames on it. Any ideas? Is my fat fs too feature full for the dos driver? Tim N. (ps. the roadmap.txt isntall instructions tell you to rawrite 'stage12' to the floppy, but there is no stage12 file. You have to manually cat together stage1 and stage2. This isn't mentioned). From daemon Mon Oct 26 18:26:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA25389 for vsta-xplod; Mon, 26 Oct 1998 18:26:00 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA25383 for ; Mon, 26 Oct 1998 18:25:57 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA14920; Mon, 26 Oct 1998 21:28:38 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id VAA00721; Mon, 26 Oct 1998 21:28:38 -0800 (PST) Message-Id: <199810270528.VAA00721@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: vstafs installation In-reply-to: Your message of "Mon, 26 Oct 1998 18:25:32 -0400." Date: Mon, 26 Oct 1998 21:28:37 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I did the rcsdiff, and it looks like it deals with the behavior when >you seek >beyond the end of the file. It simply writes zeros in 1024-byte chunks >until the real eof catches up with the new eof. Right. The newer GNU "ld" uses this to create its output executable files. The older GNU "ld" didn't. It's at least one of the bugs hitting here. >I could try to >transplant this >behavior to vstafs, but since this is really is supposed to create a >sparse >file, I am wondering if vstafs has a mechanism to deal with sparse >files. Nope, its data structures only represent densely allocated ones. >All one would need to do is mark down the bytes skipped, and be sure to >read in all zeros when that sparse block (or sparse extent, I guess) is >read again. And teach fsck the same thing, and also some complexity for messing around with the buffer cache sizing when you grow data out into what was previously sparse. I have never had much need for sparse files, and they also add hassles for backup tools. Anyway, I installed the tools on an older laptop, and see a problem running "as" on it. From some A/B comparisons, it looks like the tail end of the file got corrupt while copying it into the vstafs partition. I cp'ed the file from the DOS server onto /tmp, and then cp'ed the same file from vstafs, and although the have the same size, they differ in binary content (cmp is your friend here). So vstafs either corrupted it while creating the file, or while having it read() (my guess is the former). Do you want to hunt it, or shall I? It'd be a good warm-up for implementing sparse files. :-) Andy From daemon Tue Oct 27 04:06:10 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA26542 for vsta-xplod; Tue, 27 Oct 1998 04:06:10 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id EAA26536 for ; Tue, 27 Oct 1998 04:06:06 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id KAA13778; Tue, 27 Oct 1998 10:08:47 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Tue, 27 Oct 1998 09:04:24 -0400 Subject: Re: vstafs installation Message-ID: References: <199810270528.VAA00721@vandys-pc.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) Andy Valencia writes: > Anyway, I installed the tools on an older laptop, and see a problem running > "as" on it. From some A/B comparisons, it looks like the tail end of the > file got corrupt while copying it into the vstafs partition. I cp'ed the > file from the DOS server onto /tmp, and then cp'ed the same file from > vstafs, and although the have the same size, they differ in binary content > (cmp is your friend here). So vstafs either corrupted it while creating the > file, or while having it read() (my guess is the former). I did what you suggested; both files have the same size, but only the one copied from the dos partition will work correctly. But the things were even more bizarre that we had thought. The two files are identical up until just before the 128k mark. At that point vstafs had some garbage where dos has all zeroes. That was what you had thought in the last message. However, AFTER the 128k mark, they switch: vstafs has zeroes where dos now has data! Using my other friend, less, I see now that vstafs has zeroed out the string %$-+(,)*._~/<>|&^!:[, which contains the symbols that as was complaining about in my first message. To make things even weirder, the files sync up again shortly beyond that point. Also, I checked cp and it doesn't do any seeking. In fact, this problem seems to be created by doing nothing more than simple writes to vstafs. (pausing to go piddle on vsta machine.) The problem seems to have gone away. I did a cp back from the dos drive, and vstafs now has an uncorrupted version of as. Blah! I just sucessfully did a make. I still have the bad copy here, but I can't recreate the problem. :) Eric From daemon Tue Oct 27 02:46:53 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id CAA26343 for vsta-xplod; Tue, 27 Oct 1998 02:46:53 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id CAA26337 for ; Tue, 27 Oct 1998 02:46:51 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id IAA07389; Tue, 27 Oct 1998 08:49:14 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: newsham@lava.net Cc: vsta@zendo.com Date: Tue, 27 Oct 1998 07:39:58 -0400 Subject: Re: install question Message-ID: References: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) Unfortunately, the documentation for VSTa is way out of sync with the current distribution. This is one of the things it doesn't tell you: > module=/vsta/boot/dos -p disk/wd:wd0_dos0 fs/root The "-p" flag for specifying a namer path was basically made obsolete when the feature was added to library open() to interpret any path starting with // as a namer path. The syntax for some of the servers changed as a result. What you want instead is: module=/vsta/boot/dos -n fs/root -d //disk/wd:wd0_dos0 -B 512 The "stage12 file" is named grub.raw, and as you noticed, it is simply the concatenation of the stage 1 and stage 2. Eric From daemon Tue Oct 27 10:19:33 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA27488 for vsta-xplod; Tue, 27 Oct 1998 10:19:33 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA27482 for ; Tue, 27 Oct 1998 10:19:26 GMT Received: (qmail 23062 invoked by uid 120); 27 Oct 1998 21:25:51 -0000 Date: Tue, 27 Oct 1998 13:25:51 -0800 From: David Jeske To: *** VSTa *** Subject: [newsham@lava.net: Re: install question] Message-ID: <19981027132551.H22075@home.chat.net> Mail-Followup-To: *** VSTa *** Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i ----- Forwarded message from Tim Newsham ----- From: newsham@lava.net (Tim Newsham) Subject: Re: install question To: jeske@home.chat.net (David Jeske) Date: Tue, 27 Oct 1998 09:38:54 -1000 (HST) X-Mailer: ELM [version 2.4 PL25] > Where is it that this documentation mistake exists? vsta.tz:doc/roadmap.txt ----- End forwarded message ----- -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Tue Oct 27 07:14:43 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA26982 for vsta-xplod; Tue, 27 Oct 1998 07:14:43 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id HAA26975 for ; Tue, 27 Oct 1998 07:14:39 GMT Received: (qmail 22049 invoked by uid 120); 27 Oct 1998 18:21:04 -0000 Date: Tue, 27 Oct 1998 10:21:04 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: install question Message-ID: <19981027102103.B20319@home.chat.net> Mail-Followup-To: vsta@zendo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: ; from Eric Jacobs on Tue, Oct 27, 1998 at 07:39:58AM -0400 On Tue, Oct 27, 1998 at 07:39:58AM -0400, Eric Jacobs wrote: > > Unfortunately, the documentation for VSTa is way out of > sync with the current distribution. This is one of the > things it doesn't tell you: Where is it that this documentation mistake exists? > > > module=/vsta/boot/dos -p disk/wd:wd0_dos0 fs/root > > The "-p" flag for specifying a namer path was basically > made obsolete when the feature was added to library > open() to interpret any path starting with // as a > namer path. The syntax for some of the servers changed > as a result. > > What you want instead is: > > module=/vsta/boot/dos -n fs/root -d //disk/wd:wd0_dos0 -B 512 > > The "stage12 file" is named grub.raw, and as you noticed, > it is simply the concatenation of the stage 1 and stage 2. > > Eric -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Tue Oct 27 05:54:55 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26838 for vsta-xplod; Tue, 27 Oct 1998 05:54:55 GMT Received: from mail.ptt.ru ([195.34.0.100]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id FAA26832 for ; Tue, 27 Oct 1998 05:54:51 GMT Received: (qmail 24760 invoked from network); 27 Oct 1998 16:57:59 -0000 Received: from unknown (HELO dialup.ptt.ru) (195.34.27.85) by dialup.ptt.ru with SMTP; 27 Oct 1998 16:57:59 -0000 Sender: yoda Message-ID: <3635FBD8.2A5ABF5C@dialup.ptt.ru> Date: Tue, 27 Oct 1998 19:59:04 +0300 From: Yuriy Organization: home X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) X-Accept-Language: ru,en MIME-Version: 1.0 To: vsta@zendo.com Subject: Shared lib's help ! Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi everybody ! I tryed to make my own shared library with the only function that returns 1... libmy.c: unsigned int m_func(unsigned int arg) { return 1; } libmy.db : library libmy.a _m_func I wrote little program which calls this function and prints result (compilation flag -lmy) ... It returns 0 !? And GDB exites with 0... Help me please ! Were is my mistake ? P.S. Sorry for my english ! Yuriy From daemon Tue Oct 27 10:24:11 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA27502 for vsta-xplod; Tue, 27 Oct 1998 10:24:11 GMT Received: from staff.cs.usyd.edu.au (staff.cs.usyd.edu.au [129.78.8.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA27496 for ; Tue, 27 Oct 1998 10:24:07 GMT Message-Id: <199810271024.KAA27496@bodhi.zendo.com> Subject: Re: install question To: newsham@lava.net (Tim Newsham) Date: Wed, 28 Oct 1998 08:27:11 +1000 (EST) From: "Michael Henry" Cc: vsta@zendo.com In-Reply-To: from "Tim Newsham" at Oct 26, 98 03:02:31 pm Content-Type: text > module=/vsta/boot/dos -p disk/wd:wd0_dos0 fs/root I had the exact same problem, and after many attempts, and finally downloading Jeske's floppy version, I figured out that the above line is wrong. If you look in the archives for this mailing list you should find the correct line. (I can't remember it off the top of my head). > (ps. the roadmap.txt isntall instructions tell you to rawrite > 'stage12' to the floppy, but there is no stage12 file. You have > to manually cat together stage1 and stage2. This isn't mentioned). The documentation is crap. From daemon Tue Oct 27 06:01:13 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA26855 for vsta-xplod; Tue, 27 Oct 1998 06:01:13 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA26849 for ; Tue, 27 Oct 1998 06:01:11 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA18426; Tue, 27 Oct 1998 09:03:53 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id JAA01776; Tue, 27 Oct 1998 09:03:53 -0800 (PST) Message-Id: <199810271703.JAA01776@vandys-pc.cisco.com> To: Yuriy cc: vsta@zendo.com Subject: Re: Shared lib's help ! In-reply-to: Your message of "Tue, 27 Oct 1998 19:59:04 +0300." <3635FBD8.2A5ABF5C@dialup.ptt.ru> Date: Tue, 27 Oct 1998 09:03:53 -0800 From: Andy Valencia [Yuriy writes:] >I wrote little program which calls this function and prints result >(compilation flag -lmy) ... >It returns 0 !? >And GDB exites with 0... >Help me please ! Were is my mistake ? Looks like you're on the right track. How did you make it? It's important that the stubs and *.shl's all be generated from a common invocation of mkshlib. So did you add your library to SHLIBIN and SHLIBS in src/lib/makefile? Other than that, I'd say you need to use gdb's "stepi" and "x/i $pc" to see where your execution has gone awry. Andy From daemon Tue Oct 27 04:25:38 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA26586 for vsta-xplod; Tue, 27 Oct 1998 04:25:38 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id EAA26580 for ; Tue, 27 Oct 1998 04:25:35 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA10968; Tue, 27 Oct 1998 07:28:17 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id HAA01493; Tue, 27 Oct 1998 07:28:17 -0800 (PST) Message-Id: <199810271528.HAA01493@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: vstafs installation In-reply-to: Your message of "Tue, 27 Oct 1998 09:04:24 -0400." Date: Tue, 27 Oct 1998 07:28:16 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I did what you suggested; both files have the same size, but >only the one copied from the dos partition will work correctly. >But the things were even more bizarre that we had thought. The >two files are identical up until just before the 128k mark. At that >point vstafs had some garbage where dos has all zeroes. That was >what you had thought in the last message. However, AFTER the 128k >mark, they switch: vstafs has zeroes where dos now has data! Using >my other friend, less, I see now that vstafs has zeroed out the string >%$-+(,)*._~/<>|&^!:[, which contains the symbols that as was >complaining about in my first message. To make things even weirder, >the files sync up again shortly beyond that point. This isn't as weird as it sounds. Just coincidentally, vstafs uses contiguous buffers up to 64k in size to map onto the extents of a file. In a virgin install onto vstafs, all files end up being entirely contiguous, so vstafs buffers the file as 64k, 64k, and then a smaller fragment to cover the end of the file. Variable sized buffers in the buffer cache was easily the most complex part of vstafs, so no surprise that a bug has popped up here. >Also, I checked cp and it doesn't do any seeking. In fact, this problem >seems to be created by doing nothing more than simple writes to >vstafs. (pausing to go piddle on vsta machine.) >The problem seems to have gone away. I did a cp back from the dos >drive, and vstafs now has an uncorrupted version of as. Blah! I just >sucessfully did a make. Thank heavens. Wouldn't want an easy bug to hunt. :-) >I still have the bad copy here, but I can't recreate the problem. >:) I've pawed through the file structure with vstafs/cmd/fsdb and no real surprises. So it's in the R/W path in incremental file growth, probably. I can probably recreate this by nuking my vstafs /vsta install, and then reinstalling, but stopping right after the point where /vsta/bin/as goes in. Andy From daemon Tue Oct 27 04:11:11 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA26559 for vsta-xplod; Tue, 27 Oct 1998 04:11:11 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id EAA26553 for ; Tue, 27 Oct 1998 04:11:09 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA10274; Tue, 27 Oct 1998 07:13:51 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id HAA01376; Tue, 27 Oct 1998 07:13:51 -0800 (PST) Message-Id: <199810271513.HAA01376@vandys-pc.cisco.com> To: rayr@rramos.ucsc.edu cc: vsta@zendo.com Subject: Re: progs under ka9q/cmd In-reply-to: Your message of "Mon, 26 Oct 1998 16:46:21 PST." <199810270046.QAA05330@rramos.ucsc.edu> Date: Tue, 27 Oct 1998 07:13:50 -0800 From: Andy Valencia [rayr@rramos.ucsc.edu writes:] >the situation: >the ne server is running >the net server (ka9q) is running >i run telnetd from the vsta$ prompt as vandys (Presumably you started KA9Q with an appropriate config.) >I try to telnet from a different machine. >I see this: >bash-2.02$ telnet reg-his >Trying 128.114.163.205... >Connected to reg-his.ucsc.edu. >Escape character is '^]'. > > Welcome to VSTa v1.6.1! > > login: Connection closed by foreign host. >bash-2.02$ >and syslog shows: >syslog: telnetd (pid 120) notice: IO server: all clients done Did you run telnetd as root? Root privs are needed by _PATH_LOGIN to forge the appropriate UID's to let you log in as yourself. But that should happen after you enter a username. >what are the files r,x,y for? proxyd? The single letter ones are used for testing /inet. Proxyd is for doing network transparent VSTa messaging--it's experimental. You shouldn't need anything from down in ka9q/cmd except telnetd. You might try attaching to telnetd with gdb right before you telnet into the box, and see if anybody's dying on a signal or something. Andy From daemon Tue Oct 27 11:03:55 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA27582 for vsta-xplod; Tue, 27 Oct 1998 11:03:55 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA27576 for ; Tue, 27 Oct 1998 11:03:49 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA27828; Tue, 27 Oct 1998 14:06:32 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id OAA02415; Tue, 27 Oct 1998 14:06:32 -0800 (PST) Message-Id: <199810272206.OAA02415@vandys-pc.cisco.com> To: David Jeske cc: *** VSTa *** Subject: Re: [newsham@lava.net: Re: install question] In-reply-to: Your message of "Tue, 27 Oct 1998 13:25:51 PST." <19981027132551.H22075@home.chat.net> Date: Tue, 27 Oct 1998 14:06:31 -0800 From: Andy Valencia [David Jeske writes:] >> Where is it that this documentation mistake exists? >vsta.tz:doc/roadmap.txt Fixed in 1.6.2 (coming soon to a theatre near you!). Andy From daemon Wed Oct 28 04:15:20 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA29514 for vsta-xplod; Wed, 28 Oct 1998 04:15:20 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id EAA29508 for ; Wed, 28 Oct 1998 04:15:18 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id KAA13961; Wed, 28 Oct 1998 10:17:31 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: jeske@home.chat.net Cc: vsta@zendo.com Date: Wed, 28 Oct 1998 09:09:21 -0400 Subject: Re: install question Message-ID: References: <19981027102103.B20319@home.chat.net> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) >On Tue, Oct 27, 1998 at 07:39:58AM -0400, Eric Jacobs wrote: > >>> Unfortunately, the documentation for VSTa is way out of >>> sync with the current distribution. This is one of the >>> things it doesn't tell you: >> >>Where is it that this documentation mistake exists? In the skeleton version of MENU.LST for grub, I think. It's well commented, it's just out of date. I think that a good basic introduction to the way the servers are started and namer paths and mount points work would be nice to put in the documentation. The way that VSTa deals with devices and filesystems is really different from the generic unix, and this was one of the hardest aspects for me to get started with. It's also a really innovative way to structure an operating system. I could start writing up some of this stuff if you'd like. I know VSTa is in some serious need of docs and man pages. Eric From daemon Wed Oct 28 05:18:23 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA29576 for vsta-xplod; Wed, 28 Oct 1998 05:18:23 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA29570 for ; Wed, 28 Oct 1998 05:18:21 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA02161; Wed, 28 Oct 1998 08:21:06 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id IAA04442; Wed, 28 Oct 1998 08:21:06 -0800 (PST) Message-Id: <199810281621.IAA04442@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: install question In-reply-to: Your message of "Wed, 28 Oct 1998 09:09:21 -0400." Date: Wed, 28 Oct 1998 08:21:06 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >In the skeleton version of MENU.LST for grub, I think. It's >well commented, it's just out of date. Right. One of my bigger mistakes. It's fixed in what's being assembled for the next drop, of course. >I think that a good basic >introduction to the way the servers are started and namer >paths and mount points work would be nice to put in the >documentation. The way that VSTa deals with devices and >filesystems is really different from the generic unix, and >this was one of the hardest aspects for me to get started >with. It's also a really innovative way to structure an >operating system. >I could start writing up some of this stuff if you'd like. I >know VSTa is in some serious need of docs and man pages. Please do! :-) Thanks, Andy From daemon Wed Oct 28 06:29:21 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA29677 for vsta-xplod; Wed, 28 Oct 1998 06:29:21 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id GAA29671 for ; Wed, 28 Oct 1998 06:29:19 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id MAA24031; Wed, 28 Oct 1998 12:32:03 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Wed, 28 Oct 1998 11:28:41 -0400 Subject: Re: install question Message-ID: References: <199810281621.IAA04442@vandys-pc.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I have a couple of questions about VSTa that I'm still fuzzy about. I know what the "perm" and "acc" stat fields do, but I still get confused dealing with "struct perm". Does that one handle both fields? When I read in an "acc" field from rstat(), I've been doing an atoi on the first value for the default access, skipping to the "/", and then calling the library function to read in the rest. Is this right? UIDs and GIDs: Do their values relate to the perm values, or are they completely different? The docs seem to say that they are the same, but I'm confused. When you log on as root, you get usr.root for your default permission, via the line in /vsta/etc/passwd. In order to get the real root permission, you'd have to be in the group (I think it's 99), not the usr group. Also, in POSIX you can stat() a file you don't have read access to. In VSTa you cannot, because you would have to FS_OPEN it first. This causes utilities like gls and vls to bail out when there are private files that you don't own in a directory. In VSTa the only thing you know about a file you can't read is its name. Kernel stuff: "struct port" in the kernel corresponds to "port_name" in a program, which is global across all processes (i.e., they can send port names to each other). "struct portref" in the kernel corresponds to "port_t", which is specific in each process and can't be shared across processes. Is this right? One last thing: the values for the "type" stat field. I see f is for file (FS_SEEKable), and d is for directory. c is for a TTY (not FS_SEEKable, returns true on isatty). "b" and "s" refer to block devices; what's the difference? "fifo" is a pipe (no FS_SEEK). "x" means other device (only FS_STAT)? Thanks, Eric From daemon Wed Oct 28 07:08:06 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA29731 for vsta-xplod; Wed, 28 Oct 1998 07:08:06 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA29725 for ; Wed, 28 Oct 1998 07:08:03 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA13372; Wed, 28 Oct 1998 10:10:48 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id KAA04910; Wed, 28 Oct 1998 10:10:48 -0800 (PST) Message-Id: <199810281810.KAA04910@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Permissions In-reply-to: Your message of "Wed, 28 Oct 1998 11:28:41 -0400." Date: Wed, 28 Oct 1998 10:10:47 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I know what the "perm" and "acc" stat fields do, but I still >get confused dealing with "struct perm". Does that one handle >both fields? No; in fact, it's "struct prot". "struct perm" describes abilities which a USER has; "struct prot" describes the protections of some filesystem object. When you stat something you're looking at its "struct prot". Why did I name the supporting routine "perm_print"? Must've been a bad day.... >When I read in an "acc" field from rstat(), >I've been doing an atoi on the first value for the default >access, skipping to the "/", and then calling the library >function to read in the rest. Is this right? Actually, permpr.c and permsup.c in vsta/src/lib, along with statsup.c provide most of the routines to handle these data structures. >UIDs and GIDs: Do their values relate to the perm values, >or are they completely different? Different, and a later evolution in the whole permission/protection scheme of the world. UID is associated with a permission, and is basically an indication of who is holding a permission. So lots of users may have sys.sys, but for purposes of accounting if nothing else, a server may want to know more about the identity of the sys.sys wielder. This is why a UID got added. It also provides an escape hatch for when you completely revoke ACC_CHMOD from a file you own. Without a special case for UID, the only way to get back at the file would be to edit the underlying blocks of the filesystem with a binary editor. I was doing just such a thing when I realized I needed for the user holding a UID to always be permitted to CHMOD the object. GID is different; it's a way of indicating zero or more permissions which should be granted. Being a member of a group means you inherit each of these permissions. So the user "root" is a member of GID "99", which if you look in vsta/etc/group has a list of exactly one, zero-length, permission. OTOH, "vandys" is in group 0, which is granted sys.sys. If you log in as "vandys", not only do you get the user's private permission (usr.vandys), but also anything granted in group 0. >The docs seem to say >that they are the same, but I'm confused. When you log on >as root, you get usr.root for your default permission, via >the line in /vsta/etc/passwd. In order to get the real >root permission, you'd have to be in the group (I think >it's 99), not the usr group. No, root gets its own permission (usr.root), but then its list of permissions is enhanced by adding the zero-length "super" group permission. The "root" account is in group 99 (the fourth field of the record, I believe). I guess the fact that his UID is 99 makes that a little less clear, sorry. >Also, in POSIX you can stat() a file you don't have read >access to. In VSTa you cannot, because you would have to >FS_OPEN it first. This causes utilities like gls and vls to >bail out when there are private files that you don't own in > a directory. In VSTa the only thing you know about a file >you can't read is its name. This mostly seems like a feature to me, although it causes wrinkles like the one you noticed. Setting aside legacy behavior, why should somebody who isn't supposed to read your file be permitted to know when and how much you wrote it, and also when you read it? >Kernel stuff: "struct port" in the kernel corresponds to >"port_name" in a program, which is global across all processes >(i.e., they can send port names to each other). "struct >portref" in the kernel corresponds to "port_t", which is >specific in each process and can't be shared across processes. >Is this right? Right, port_name's are global, and port_t's (on top of which file descriptors are emulated) are a per-process resource. >One last thing: the values for the "type" stat field. I see >f is for file (FS_SEEKable), and d is for directory. c is for >a TTY (not FS_SEEKable, returns true on isatty). "b" and >"s" refer to block devices; what's the difference? "fifo" >is a pipe (no FS_SEEK). "x" means other device (only >FS_STAT)? I think there's also "null", for fast-stub /dev/null emulation in libc. I'm not at all convinced there's a difference between "b" and "s". The only really critical one is "c", because a bunch of TTY processing happens behind your back. More than one person has spent time with their brand-new server trying to figure out what's happening to their data because they cribbed their code from a TTY server. :-> andy From daemon Wed Oct 28 12:37:56 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA00342 for vsta-xplod; Wed, 28 Oct 1998 12:37:56 GMT Received: from mx2.techline.com (mx2.techline.com [204.201.36.17]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA00336 for ; Wed, 28 Oct 1998 12:37:54 GMT From: magpie@techline.com Received: from lucy (ip421.tc1net.ips.techline.com [204.201.38.136]) by mx2.techline.com (8.8.5/8.8.5) with SMTP id PAA07935 for ; Wed, 28 Oct 1998 15:45:34 -0800 Message-Id: <3.0.2.32.19981028154046.00918690@mail.techline.com> X-Sender: magpie@mail.techline.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Wed, 28 Oct 1998 15:40:46 -0800 To: vsta@zendo.com Subject: Unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Please remove me from the mailing list. Thankyou for the fun system! I've had to remove it from my machine for now, but I'll keep an eye out for v1.6.2 and beyond. Scott W. Lucas, from the time-warp of Gray's Harbor, Washington, USA From daemon Wed Oct 28 22:47:38 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA01188 for vsta-xplod; Wed, 28 Oct 1998 22:47:38 GMT Received: from barney.specialix.co.uk ([192.65.144.44]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA01182 for ; Wed, 28 Oct 1998 22:47:33 GMT Received: by barney.specialix.co.uk with Internet Mail Service (5.5.1960.3) id ; Thu, 29 Oct 1998 09:49:43 -0000 Message-ID: From: Kevin Conway To: "'vsta@zendo.com'" Subject: unsubscribe Date: Thu, 29 Oct 1998 09:49:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Please remove me from the mailing list. Thanks kevin _______________________________________________________________ Kevin Conway | Specialix International Ltd. Senior Software Engineer | Suite #3, Cobb House, 2 Oyster Lane, | Byfleet, Surrey KT14 7DU, UK | Phone: +44(0) 1932 793522 | Fax: +44(0) 1932 793500 mailto:kevinc@specialix.co.uk http://www.specialix.co.uk/ From daemon Thu Oct 29 02:47:09 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id CAA01715 for vsta-xplod; Thu, 29 Oct 1998 02:47:09 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id CAA01709 for ; Thu, 29 Oct 1998 02:47:06 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id IAA08022; Thu, 29 Oct 1998 08:49:53 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Thu, 29 Oct 1998 07:45:22 -0400 Subject: Re: Permissions Message-ID: References: <199810281810.KAA04910@vandys-pc.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@cisco.com writes: >>>When I read in an "acc" field from rstat(), >>>I've been doing an atoi on the first value for the default >>>access, skipping to the "/", and then calling the library >>>function to read in the rest. Is this right? >Actually, permpr.c and permsup.c in vsta/src/lib, along with statsup.c >provide most of the routines to handle these data structures. do_wstat in statsup.c handles what most servers will need to do. I had a slightly different case because I was basing my struct prots off of a file in the outside filesystem, so I had to rstat those fields and set them manually. >>>UIDs and GIDs: Do their values relate to the perm values, >>>or are they completely different? >>Different, and a later evolution in the whole permission/protection >scheme >>of the world. >>UID is associated with a permission, and is basically an indication of >who >>is holding a permission. So lots of users may have sys.sys, but for >>purposes of accounting if nothing else, a server may want to know more >about >>the identity of the sys.sys wielder. This is why a UID got added. It >also >>provides an escape hatch for when you completely revoke ACC_CHMOD from >a >>file you own. Without a special case for UID, the only way to get >back at >>the file would be to edit the underlying blocks of the filesystem with >a >>binary editor. I was doing just such a thing when I realized I needed >for >>the user holding a UID to always be permitted to CHMOD the object. Got it. That's what the "owner" stat is for. This makes a lot of sense. It was really throwing me off because a number of hardware servers were returning owner=0, when there is no UID 0. One server (fd) was even returning owner=1/1, which is a permission, not a UID. >>GID is different; it's a way of indicating zero or more permissions >which >>should be granted. Being a member of a group means you inherit each of >>these permissions. So the user "root" is a member of GID "99", which >if you >>look in vsta/etc/group has a list of exactly one, zero-length, >permission. >>OTOH, "vandys" is in group 0, which is granted sys.sys. If you log in >as >>"vandys", not only do you get the user's private permission >(usr.vandys), >>but also anything granted in group 0. I've got it now. It becomes easier to see once you play with the "ids" command a little. I've looked at login.c and I see how it uses perm_ctl to give the user their assigned ids. I'm going to try to create a command to let the user muck around with their permissions in the shell. It wouldn't be able to change the real shell's permissions (I don't think), but it certainly could let you launch programs with forged ids, etc. >>>Also, in POSIX you can stat() a file you don't have read >>>access to. In VSTa you cannot, because you would have to >>>FS_OPEN it first. This causes utilities like gls and vls to >>>bail out when there are private files that you don't own in >>> a directory. In VSTa the only thing you know about a file >>>you can't read is its name. >>This mostly seems like a feature to me, although it causes wrinkles >like the >>one you noticed. Setting aside legacy behavior, why should somebody >who >>isn't supposed to read your file be permitted to know when and how >much you >>wrote it, and also when you read it? I agree completely. >Eric From daemon Thu Oct 29 03:33:14 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id DAA01791 for vsta-xplod; Thu, 29 Oct 1998 03:33:14 GMT Received: from koko.nts-online.net (koko.nts-online.net [205.231.176.4]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id DAA01785 for ; Thu, 29 Oct 1998 03:33:11 GMT Received: from datawisesystems.com (dialup-ama-33.nts-online.net [205.231.177.111]) by koko.nts-online.net (8.8.7/8.8.7) with ESMTP id IAA13943 for ; Thu, 29 Oct 1998 08:43:28 -0600 Message-ID: <36388596.D71CB945@datawisesystems.com> Date: Thu, 29 Oct 1998 09:11:18 -0600 From: "Eric C. Weaver" X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please remove me from the mailing list. Thanks eric From daemon Thu Oct 29 12:36:58 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA03020 for vsta-xplod; Thu, 29 Oct 1998 12:36:58 GMT Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA03014 for ; Thu, 29 Oct 1998 12:36:53 GMT Received: from ichips-ra.pdx.intel.com (ichips-ra.pdx.intel.com [137.102.192.31]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id XAA20829 for ; Thu, 29 Oct 1998 23:40:12 GMT Received: from pdxnw392 (pdxnw392.pdx.intel.com [137.102.203.90]) by ichips-ra.pdx.intel.com (8.8.8/8.8.7) with SMTP id PAA03778 for ; Thu, 29 Oct 1998 15:40:12 -0800 (PST) From: "Gordon Neal" To: Subject: mailing list Date: Thu, 29 Oct 1998 15:40:12 -0800 Message-ID: <003101be0395$78df67b0$5acb6689@pdxnw392.pdx.intel.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0032_01BE0352.6ABC27B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01BE0352.6ABC27B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0033_01BE0352.6ABC27B0" ------=_NextPart_001_0033_01BE0352.6ABC27B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit please remove me from your mailing list. Gordon The pioneers get the arrows .... The settlers get the corn ... ------=_NextPart_001_0033_01BE0352.6ABC27B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please remove me from your mailing list.
Gordon
 
The pioneers get the = arrows=20 ....
The settlers get the = corn=20 ...
------=_NextPart_001_0033_01BE0352.6ABC27B0-- ------=_NextPart_000_0032_01BE0352.6ABC27B0 Content-Type: image/jpeg; name="Notebook.jpg" Content-Transfer-Encoding: base64 Content-ID: <321373923@29101998-2f20> /9j/4AAQSkZJRgABAgEASABIAAD/7QSyUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAADBgJS//f/9wMPAlsDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAAqIAAAABAAAAgAAAAAIAAAGAAAADAAAAAoYAGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAIAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APROif0Kv6X81T9L j+ar/m/5K0F8rJJIfqlJfKySKn6pSXyskkp+qUl8rJJKfqlJfKySSn6pSXyskkp+qUl8rJJKfqlJ fKySSn//2ThCSU0EBgAAAAAABwABAAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90 b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgNCQ0VDAwVGhQQFBogGxoaGyAiFxcX FxciEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0NDREOERsRERsUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAYBaAD ASIAAhEBAxEB/90ABABa/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwCv0T+n4/8AxrP+qavW15J0U/r+P/xrP+qavWg8eKElsWSHZfXWYe4A+ZUMjIFTJBE/ Fc1kXbg63mJP+amk0uesGqdc19Sup2ZrLmWGQxwLR4B35v8A0V0qKlJJJIqUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSn/0J9G6oKn04zKKXOdYA6x7d1kOP8Ag/3Hs/MXY/sOl/0hYfCT/wCQavnZJArQ /S1HTXVN21+weYa7/vqzcroeQ+Q3XcYOn/mbF89pIaJfpboXRK+k1uDQPUsILyONPotZ/JatRfKq SSX6qSXyqkip+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp JfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl 8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn/2Q== ------=_NextPart_000_0032_01BE0352.6ABC27B0-- From daemon Fri Oct 30 12:55:14 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA05714 for vsta-xplod; Fri, 30 Oct 1998 12:55:14 GMT Received: from extra.ucc.su.OZ.AU (extra.ucc.su.oz.au [129.78.64.4]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA05708 for ; Fri, 30 Oct 1998 12:55:08 GMT Received: from extro.ucc.usyd.edu.au (lschan@extro.ucc.usyd.edu.au [129.78.64.1]) by extra.ucc.su.OZ.AU (8.9.0/8.9.0) with ESMTP id KAA05038 for ; Sat, 31 Oct 1998 10:58:28 +1100 (EST) Received: from localhost (lschan@localhost) by extro.ucc.usyd.edu.au (8.9.0/8.9.0) with SMTP id KAA04201 for ; Sat, 31 Oct 1998 10:58:26 +1100 (EST) Date: Sat, 31 Oct 1998 10:58:26 +1100 (EST) From: Louis Siu Ming Chan To: vsta@zendo.com Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please remove me from the mailing list. Thanks From daemon Sat Oct 31 11:27:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA10370 for vsta-xplod; Sat, 31 Oct 1998 11:27:00 GMT Received: from village.instaview.com (ziggy@village.instaview.com [198.70.144.102]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA10351 for ; Sat, 31 Oct 1998 11:26:47 GMT Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by village.instaview.com (8.8.7/8.8.7) id VAA26021 for vsta@zendo.com; Sat, 31 Oct 1998 21:24:37 -0500 From: Ziggy Stardust To: vsta@zendo.com Subject: Baling? Date: Sat, 31 Oct 1998 21:23:55 -0500 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <98103121243606.04159@village.instaview.com> Content-Transfer-Encoding: 8bit Hmm hate to see everyoen jumping ship...but ill stick around l love it.. Ziggy ---------------------------------------------------------------- People wake up !!! They are not taking our rights, we are giving them away!!! Lets get together and stop it NOW!!!! ---------------------------------------------------------------- Ziggy@village.instaview.com alewis@iquest.net FTP/WWW -> nurbie.dyn.ml.org ICQ:4447989 #photoshop/DalNet ---------------------------------------------------------------- From daemon Sat Oct 31 13:10:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA10494 for vsta-xplod; Sat, 31 Oct 1998 13:10:00 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA10485 for ; Sat, 31 Oct 1998 13:09:58 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA25816; Sat, 31 Oct 1998 16:12:53 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id QAA13501; Sat, 31 Oct 1998 16:12:53 -0800 (PST) Message-Id: <199811010012.QAA13501@vandys-pc.cisco.com> To: Ziggy Stardust cc: vsta@zendo.com Subject: Re: Baling? In-reply-to: Your message of "Sat, 31 Oct 1998 21:23:55 EST." <98103121243606.04159@village.instaview.com> Date: Sat, 31 Oct 1998 16:12:52 -0800 From: Andy Valencia [Ziggy Stardust writes:] >Hmm hate to see everyoen jumping ship...but ill stick around l love it.. Oh, it's not too bad. Usually after a quiet spell when there's some messages, you get a little burst of list cleaning. It's just that this time around not a single one of them used vsta-request@zendo.com, this wasting the time of the entire list. I've modified the incoming filters to try and catch the more obvious list modification requests. Thanks for the friendly note! Regards, Andy Valencia From daemon Fri Nov 6 04:37:16 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA24342 for vsta-xplod; Fri, 6 Nov 1998 04:37:16 GMT Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id EAA24323 for ; Fri, 6 Nov 1998 04:37:13 GMT Received: (qmail 29352 invoked from network); 6 Nov 1998 15:40:54 -0000 Received: from nathan.enteract.com (mjohnson@207.229.143.6) by thor.enteract.com with SMTP; 6 Nov 1998 15:40:54 -0000 Date: Fri, 6 Nov 1998 09:41:22 -0600 (CST) From: Mark Johnson To: vsta@zendo.com Subject: init can't open inittab Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm installing VSTa 1.6.1. I've untarred vsta.t into /vsta. When I try to boot from a GRUB floppy: root=(hd0,0) kernel=/vsta/boot/vsta module=/vsta/boot/cons module=/vsta/boot/namer module=/vsta/boot/wd d0:readp module=/vsta/boot/dos -n fs/root -d //disk/wd:wd0_dos0 -B 512 module=/vsta/boot/init boot I get: syslog: error: init: /vsta/etc/inittab: can't open inittab Boot process 9 dies Process 9 is of course init When I replace init with testsh: % ls .: no entry % mount fs/root /x % cd /x % ls -l [...] vsta: [...] type=f [...] It seems like the dos server thinks the vsta directory is a file. Does anyone have any ideas or hints of what to investigate? -- Mark Johnson mjohnson@enteract.com From daemon Fri Nov 6 04:46:02 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA24387 for vsta-xplod; Fri, 6 Nov 1998 04:46:02 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id EAA24381 for ; Fri, 6 Nov 1998 04:46:00 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA00286; Fri, 6 Nov 1998 07:49:12 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id HAA26608; Fri, 6 Nov 1998 07:49:11 -0800 (PST) Message-Id: <199811061549.HAA26608@vandys-pc.cisco.com> To: Mark Johnson cc: vsta@zendo.com Subject: Re: init can't open inittab In-reply-to: Your message of "Fri, 06 Nov 1998 09:41:22 CST." Date: Fri, 06 Nov 1998 07:49:11 -0800 From: Andy Valencia [Mark Johnson writes:] >% cd /x >% ls -l >[...] >vsta: [...] type=f [...] >It seems like the dos server thinks the vsta directory is a file. >Does anyone have any ideas or hints of what to investigate? Can you try "cd /x/vsta" and "ls"? I want to check for any funny in the "ls" as opposed to the actual filesystem. I can't think of any reason the DOS server would get confused. FAT-32 and compressed volumes won't even start, and it's hard to get confused once you're talking FAT-16. Do all the files in the "ls" match up with what you expect? Once I had a problem with a confusion between my first SCSI disk and my first IDE disk, when my IDE wasn't configured in the BIOS. Just a random thought. Andy From daemon Fri Nov 6 05:33:26 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26690 for vsta-xplod; Fri, 6 Nov 1998 05:33:26 GMT Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id FAA26671 for ; Fri, 6 Nov 1998 05:33:23 GMT Received: (qmail 8714 invoked from network); 6 Nov 1998 16:37:04 -0000 Received: from nathan.enteract.com (mjohnson@207.229.143.6) by thor.enteract.com with SMTP; 6 Nov 1998 16:37:04 -0000 Date: Fri, 6 Nov 1998 10:37:33 -0600 (CST) From: Mark Johnson To: vsta@zendo.com Subject: Re: init can't open inittab In-Reply-To: <199811061549.HAA26608@vandys-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Nov 1998, Andy Valencia wrote: > [Mark Johnson writes:] > > >% cd /x > >% ls -l > >[...] > >vsta: [...] type=f [...] > >It seems like the dos server thinks the vsta directory is a file. > >Does anyone have any ideas or hints of what to investigate? > > Can you try "cd /x/vsta" and "ls"? I want to check for any funny in the > "ls" as opposed to the actual filesystem. % cd /x/vsta New dir: /x/vsta % ls % Nothing (btw I did a cd /x/command.com ; ls - it started printing out command.com and dumped me into the debugger - imagine that :-) The other files appear like I would expext them directories are directories and files are files. > > I can't think of any reason the DOS server would get confused. FAT-32 and > compressed volumes won't even start, and it's hard to get confused once > you're talking FAT-16. > > Do all the files in the "ls" match up with what you expect? Once I had a > problem with a confusion between my first SCSI disk and my first IDE disk, > when my IDE wasn't configured in the BIOS. Just a random thought. The machine is a ZDS Z-NOTEFLEX with one 525 MD IDE HD. The DOS is from a format /s c: from a vanilla MS-DOS 5.0 boot disk. I deleted the old /vsta and reinstalled with the same results. I'll give this another try on another machine. Mark From daemon Fri Nov 6 13:26:36 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA27303 for vsta-xplod; Fri, 6 Nov 1998 13:26:36 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA27297 for ; Fri, 6 Nov 1998 13:26:33 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA06123; Fri, 6 Nov 1998 16:29:46 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id QAA27845; Fri, 6 Nov 1998 16:29:46 -0800 (PST) Message-Id: <199811070029.QAA27845@vandys-pc.cisco.com> To: Mark Johnson cc: vsta@zendo.com Subject: Re: init can't open inittab In-reply-to: Your message of "Fri, 06 Nov 1998 10:37:33 CST." Date: Fri, 06 Nov 1998 16:29:45 -0800 From: Andy Valencia [Mark Johnson writes:] >> >% cd /x >> >% ls -l >> >[...] >> >vsta: [...] type=f [...] >> >It seems like the dos server thinks the vsta directory is a file. >> >Does anyone have any ideas or hints of what to investigate? >> Can you try "cd /x/vsta" and "ls"? I want to check for any funny in the >> "ls" as opposed to the actual filesystem. >% cd /x/vsta >New dir: /x/vsta >% ls >% What's the "attrib" on "vsta" under DOS? It wouldn't happen to be read-only, would it? Or other weirdness--you might want to try and catch any tar extraction complains as they stream by. Andy From daemon Fri Nov 6 13:22:41 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA27287 for vsta-xplod; Fri, 6 Nov 1998 13:22:41 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA27281 for ; Fri, 6 Nov 1998 13:22:39 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA05652; Fri, 6 Nov 1998 16:25:52 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id QAA27771; Fri, 6 Nov 1998 16:25:52 -0800 (PST) Message-Id: <199811070025.QAA27771@vandys-pc.cisco.com> To: James Carter cc: vsta@zendo.com Subject: Re: union mounts In-reply-to: Your message of "Fri, 06 Nov 1998 23:51:19 GMT." Date: Fri, 06 Nov 1998 16:25:52 -0800 From: Andy Valencia [James Carter writes:] >i've not been able to find an answer in the available documentation ( i >admit i haven't looked at the source). >does vsta support plan9-like union mounts? Yes. See vsta/src/lib/open.c, the "struct mntent" data structure. From the shell, just "mount /" to put more than one into the /. >i find that almost as useful as per-process namespace. That's the claim I heard from Plan 9 in particular, but in practice I've never used it much at all. For instance, Plan 9's shell only looks at /bin, and you're expected to union things into it. But in practice, all shells (even the freeware "rc" clone) use a PATH concept. Still, it's there, and works (delta any bit rot). Andy Valencia From daemon Fri Nov 6 14:58:21 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA27471 for vsta-xplod; Fri, 6 Nov 1998 14:58:21 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id OAA27452 for ; Fri, 6 Nov 1998 14:58:18 GMT Received: (qmail 9673 invoked by uid 120); 7 Nov 1998 02:05:14 -0000 Date: Fri, 6 Nov 1998 18:05:14 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: union mounts Message-ID: <19981106180514.H6678@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199811070025.QAA27771@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <199811070025.QAA27771@vandys-pc.cisco.com>; from Andy Valencia on Fri, Nov 06, 1998 at 04:25:52PM -0800 On Fri, Nov 06, 1998 at 04:25:52PM -0800, Andy Valencia wrote: > >i find that almost as useful as per-process namespace. > > That's the claim I heard from Plan 9 in particular, but in practice I've > never used it much at all. For instance, Plan 9's shell only looks at /bin, > and you're expected to union things into it. But in practice, all shells > (even the freeware "rc" clone) use a PATH concept. Still, it's there, and > works (delta any bit rot). I find this an interesting concept considering that modern shells walk your 'path' and bring everything into an in-memory hash table anyhow. What's the big win of doing a union bin? In my own UNIX installations, I've moved in completely the opposite directions, all packages are encapsulated in their own directories. On superior shells (like zsh) I just manually add entries into the path hash table. I don't have a /usr/local/bin. This allows me to have lots of versions of the same things installed, and allows me to be more aware of command line naming conflicts. home:/usr/local/encap> ls -F INSTALLED apache_1.2.5.encap/ catdoc-0.33.encap/ communicator-v405.encap/ encapper-1.3.encap/ ezmlm.encap/ fvwm-2.0.46.encap/ fvwm95-2.0.43b.encap/ gdbm-1.7.3.encap/ ie-4.encap/ ie4_0.encap.old/ lynx-2.8.encap/ mswordview-0.0.14.encap/ mutt-0.90.2.encap/ mutt-0.92.1.encap/ mutt-0.92.1p.encap/ mutt-0.94.13.encap/ mutt.encap/ mysql-3.21.19b.encap/ ncftp-3.0b1.encap/ patch-2.5.encap/ perl5.004_04.encap/ rxvt-2.4.6.encap/ samba-1.9.18p7.encap/ tcp_wrappers-7.6.encap/ xbuffy3.3.encap/ xemacs-20.4/ xpm-3.4k.encap/ ytalk-3.2.encap/ zsh-3.1.2-zefram4.encap/ -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Fri Nov 6 15:43:54 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA27537 for vsta-xplod; Fri, 6 Nov 1998 15:43:54 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id PAA27518 for ; Fri, 6 Nov 1998 15:43:51 GMT Received: (qmail 9878 invoked by uid 120); 7 Nov 1998 02:50:47 -0000 Date: Fri, 6 Nov 1998 18:50:47 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: union mounts Message-ID: <19981106185047.J6678@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199811070025.QAA27771@vandys-pc.cisco.com> <19981106180514.H6678@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <19981106180514.H6678@home.chat.net>; from David Jeske on Fri, Nov 06, 1998 at 06:05:14PM -0800 On Fri, Nov 06, 1998 at 06:05:14PM -0800, David Jeske wrote: > In my own UNIX installations, I've moved in completely the opposite > directions, all packages are encapsulated in their own directories. On > superior shells (like zsh) I just manually add entries into the path > hash table. I don't have a /usr/local/bin. > > This allows me to have lots of versions of the same things installed, > and allows me to be more aware of command line naming conflicts. I forgot to mention the most significant thing about this whole scheme. To create environments I no longer have to list paths to packages, I just list the package identifier. Something like "netscape-4.03". So the environments work anywhere regardless of app installation location. But this is getting off topic, check out this URL if you want to know more: http://www.chat.net/~jeske/Projects/UnixTools/ Related to VSTa, the reason I like process local mounts is that it provides the ability to 'redirect' or 'sandbox'. However, ports and the namer or not remappable, so if applications depend on these directly, they are not remappable. In a sense, I feel more comfortable when accessing resources is 100% VM-able because only then can you guarantee nobody relies on an absolute resource. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Sat Nov 7 09:14:42 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA01065 for vsta-xplod; Sat, 7 Nov 1998 09:14:42 GMT Received: from mail.ucsd.edu (ucsd.ucsd.edu [132.239.1.1]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA01046 for ; Sat, 7 Nov 1998 09:14:39 GMT Received: from tanya (tanya.ucsd.edu [132.239.141.90]) by mail.ucsd.edu; id MAA17416 sendmail 8.8.8AS/UCSD8.3 via SMTP Sat, 7 Nov 1998 12:18:24 -0800 ( PST) for <@mail.ucsd.edu:vsta@zendo.com> Received: by tanya (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA04243; Sat, 7 Nov 1998 12:18:24 -0800 Message-ID: <19981107121824.C4117@Tanya.ucsd.edu> Date: Sat, 7 Nov 1998 12:18:24 -0800 From: Eric Dorman To: vsta@zendo.com Subject: Re: union mounts References: <199811070025.QAA27771@vandys-pc.cisco.com> <19981106180514.H6678@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: <19981106180514.H6678@home.chat.net>; from David Jeske on Fri, Nov 06, 1998 at 06:05:14PM -0800 On Fri, Nov 06, 1998 at 06:05:14PM -0800, David Jeske wrote: > On Fri, Nov 06, 1998 at 04:25:52PM -0800, Andy Valencia wrote: > > >i find that almost as useful as per-process namespace. > > That's the claim I heard from Plan 9 in particular, but in practice I've > > never used it much at all. For instance, Plan 9's shell only looks at /bin, > > and you're expected to union things into it. But in practice, all shells > > (even the freeware "rc" clone) use a PATH concept. Still, it's there, and > > works (delta any bit rot). > I find this an interesting concept considering that modern shells walk > your 'path' and bring everything into an in-memory hash table > anyhow. What's the big win of doing a union bin? Coz then you don't have to complicate the shell with PATH and caching nonsense. Plus one doesn't have to do screwy things with mounts if you have clients with different architectures. [xxx 'encapsulation'] > This allows me to have lots of versions of the same things installed, > and allows me to be more aware of command line naming conflicts. This is an advantage? Seems the road to madness, with the possibilities of different header, log or data file formats with misc. versions floating around. Plus it gets icky quickly if multiple architectures must be supported. Just 2/c, Eric Dorman edorman@ucsd.edu From daemon Sat Nov 7 06:12:25 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA00894 for vsta-xplod; Sat, 7 Nov 1998 06:12:25 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id GAA00875 for ; Sat, 7 Nov 1998 06:12:22 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id MAA00285 for ; Sat, 7 Nov 1998 12:15:36 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vsta@zendo.com Date: Sat, 7 Nov 1998 12:12:11 -0500 Subject: mkshlib mysteries Message-ID: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I've been trying to rebuild the shared libraries, and I can't seem to get mkshlib to work. At first, it would always Exit 11. Then, I get Already building library 'PhH' perm I do a quick scan of the source and find out that curlib is being used uninitialized, so a put a curlib = 0 in and now I get vsta$ mkshlib ld.db libc.db Library ld.a @ 0x60000000 /tmp/shl360: no entry perm This is under vstafs, so I'm guessing that the PhH problem has to do with the non-zeroed BSS coming from ld. Any ideas? From daemon Sat Nov 7 10:25:18 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA01186 for vsta-xplod; Sat, 7 Nov 1998 10:25:18 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA01167 for ; Sat, 7 Nov 1998 10:25:11 GMT Received: (qmail 12346 invoked by uid 120); 7 Nov 1998 21:32:08 -0000 Date: Sat, 7 Nov 1998 13:32:08 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: union mounts Message-ID: <19981107133208.K6678@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199811070025.QAA27771@vandys-pc.cisco.com> <19981106180514.H6678@home.chat.net> <19981107121824.C4117@Tanya.ucsd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <19981107121824.C4117@Tanya.ucsd.edu>; from Eric Dorman on Sat, Nov 07, 1998 at 12:18:24PM -0800 On Sat, Nov 07, 1998 at 12:18:24PM -0800, Eric Dorman wrote: > > I find this an interesting concept considering that modern shells walk > > your 'path' and bring everything into an in-memory hash table > > anyhow. What's the big win of doing a union bin? > > Coz then you don't have to complicate the shell with PATH and > caching nonsense. Plus one doesn't have to do screwy things with > mounts if you have clients with different architectures. 1) All modern shells (bash,tcsh,zsh) do this regardless of whether you use union mounts or not. I suppose the union mount lib could keep hash tables itself. 2) To me it's not so important whether you use union mounts or my scheme for adding the package to your environment. The important part is that you specify the package with a logical name (like netscape-4.03) not a physical name (like /usr/local/enca/netscape-4.03). In the union mout scheme, if you end up with some file doing something like "mount //dev/disk/01:usr/local/apps/netscape-4.03 /usr/local" then you've gone the wrong direction. _that_ kind of thing is what makes environment setup screwy for different architectures. For reference, the UnixTools system I setup automatically setup the correct binaries based on the platform you were on. The user would merely specify "logical" application names. 3) what do you do with union mounts when you have naming collisions? > [xxx 'encapsulation'] > > This allows me to have lots of versions of the same things installed, > > and allows me to be more aware of command line naming conflicts. > > This is an advantage? Seems the road to madness, with the possibilities > of different header, log or data file formats with misc. versions floating > around. Plus it gets icky quickly if multiple architectures must be > supported. The road to madness is forcing everyone to upgrade to a new version at the same time. I came up with the UnixTools structure while doing VHDL design at S3 (a PC graphics chip maker). Hardware design projects choose a tool version, and need that tool version to stay the same for the duration of the project. Another project (going on at the same time) may choose a different tool version. Changing tools mid-stream is _not_ possible. Keeping the network shares separate is also not possible, because people work on mulitple projects. In addition, you want to be able to pull out a design from the source control tool a year later and actually have it build. That means that old version of software need to persist at all times. While this certainly is a particular installation with particular needs, I find the structure make much more sense even for my own personal use. I don't like upgrading before I've tested the new version. If you have to delete the old version to install a new one, then you are putting yourself at risk of not being able to get back to where you were. What if the new version dosn't function correctly? What if you have some trouble re-installing the old one? Personally, I like to test the seaworthyness of my next ship before I sink the old one. Others clearly like to sail the ocean in a more risky manner. FWIW, UnixTools beautifully handles multiple architecutres: netscape-4.03.encap/sun-solaris/bin/* i386-linux/bin/* Because the environment setup is based on logical names, the UnixTools environment setup automatically chooses the correct binaries to put into your environment. It also does neat things like automatic notifications of environment changes (i.e. if a user is asking for the "current-tools" toolset, it'll tell them when that environment changes). -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Sun Nov 8 18:15:32 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA03727 for vsta-xplod; Sun, 8 Nov 1998 18:15:32 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA03721 for ; Sun, 8 Nov 1998 18:15:29 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA15547; Sun, 8 Nov 1998 21:18:48 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id VAA05624; Sun, 8 Nov 1998 21:18:48 -0800 (PST) Message-Id: <199811090518.VAA05624@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: mkshlib mysteries In-reply-to: Your message of "Sat, 07 Nov 1998 21:17:52 EST." Date: Sun, 08 Nov 1998 21:18:47 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >Ok, ok, I answered my own question. It turns out, most programs >won't even run correctly unless their BSS is preset to zero. So, >it is essential that zeroes are written when ld seeks past the end- >of-file. Here is rcsdiff -r1.24 -r1.13 rw.c for vstafs. Thanks, I'll go over this diff. >The major snags I've run into running vstafs as my main partition are: > >1. File names. All of the archives are taken from dos, which truncates >the names to 8.3 and disregards capitalization. So, expect to do a lot >of >renaming of files. Hmmm, I mostly tried to avoid such filenames in the first place. MGR will have a problem, but if you want to send me a list of others, I'll see what can be done. >2. Security/permissions. Again, something is ignored by dos (mostly). >The shared libraries in /vsta/lib must have read-access by everyone. >Also, init gets sys.sys, but not the "real root". So /vsta/etc/passwd >and >/vsta/etc/shadow must be sys.sys readable. Rcs has a problem that I >haven't figured out. Whenever I check-in a file, the corresponding >file in the RCS directory is not readable by anyone (not even root). It >can >be rm'd, but that's about it. I cannot even chmod it. Yes, having lived with the current security treatment of vstafs, I'm about ready to put my head together with anybody who wants to talk about some sort of generalized "umask" concept. >3. The problem involving writing after seeking past the end-of-file. > >Right now I'm trying to make a slight change to the C library in open() >so that if a file is being created in a path and the directories don't >already exist, open will create them as it walks the path. This >behavior >seems to be required by tar. Has anyone else encountered this problem? No, tar(1) has a clue how to handle this (see make_dirs()), as does "mkdir -p" (see how it uses "pflag"). open() should not do this, as you'll crash into POSIX and probably make various utilities in subtle ways. >XXContent-Type: application/octet-stream; name="RWDIFF" >XXContent-ID: >XXContent-Transfer-Encoding: base64 >... FYI, the mailing list clamps down on things which look like binary attachments. In this case, I'll extract this from the filtered input, and apply the diffs as appropriate. Sounds like you're having fun messing with this style of root filesystem! I've put some more time in on the "corrupted GNU as" bug. It comes down to a race condition between the sync of buffers on the close of the "as" utility, and the buffer operations of the next couple of files. I've been messing with some trip points, and haven't nailed it down further, except that I now know that a lot of things I *thought* worked OK, in fact *do* work OK. Regards, Andy Valencia From daemon Mon Nov 9 03:54:49 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id DAA04683 for vsta-xplod; Mon, 9 Nov 1998 03:54:49 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id DAA04664 for ; Mon, 9 Nov 1998 03:54:45 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id JAA16681; Mon, 9 Nov 1998 09:57:59 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Mon, 9 Nov 1998 09:40:19 -0500 Subject: Re: mkshlib mysteries Message-ID: References: <199811090518.VAA05624@vandys-pc.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) Speaking of open(), what is the status of symbolic links in VSTa? The file system seems to be required to give an ESYMLINK error if an attempt is made to open a symlink without the ACC_SYMLINK bit. DOS does this for files with the hidden flag set, but doesn't seem to have a way of creating the links. The GNU file utils don't seem to believe that symlinks can be created at all, and always copy the file instead. From daemon Mon Nov 9 16:30:45 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA06095 for vsta-xplod; Mon, 9 Nov 1998 16:30:45 GMT Received: from mail.telstra.com.au ([192.148.160.16]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA06076 for ; Mon, 9 Nov 1998 16:30:40 GMT Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id OAA06612 for ; Tue, 10 Nov 1998 14:33:58 +1100 (EST) Received: from mail-gw.fwall.telstra.com.au(192.148.147.16) via SMTP by mail.telstra.com.au, id smtpd006146; Tue Nov 10 14:32:46 1998 Received: (from uucp@localhost) by mail-gw.fwall.telstra.com.au (8.8.2/8.6.9) id OAA00770 for ; Tue, 10 Nov 1998 14:32:43 +1100 (EST) Received: from cdn-mail.dn.itg.telecom.com.au(144.135.109.134) via SMTP by mail-gw.fwall.telstra.com.au, id smtpd000482; Tue Nov 10 14:32:13 1998 Received: from troy.bms.itg.telecom.com.au (troy.bms.itg.telecom.com.au [172.242.65.204]) by cdn-mail.dn.itg.telecom.com.au (8.8.2/8.6.9) with ESMTP id OAA12582 for ; Tue, 10 Nov 1998 14:32:12 +1100 (EST) Received: (from marcb@localhost) by troy.bms.itg.telecom.com.au (8.8.5/8.6.9) id OAA27578; Tue, 10 Nov 1998 14:23:31 +1100 (EST) Date: Tue, 10 Nov 1998 14:23:31 +1100 (EST) From: "Marc A. Boschma" Message-Id: <199811100323.OAA27578@troy.bms.itg.telecom.com.au> To: Eric_Jacobs@fc.mcps.k12.md.us, vandys@cisco.com Subject: Re: Permissions Cc: vsta@zendo.com >>Also, in POSIX you can stat() a file you don't have read >>access to. In VSTa you cannot, because you would have to >>FS_OPEN it first. This causes utilities like gls and vls to >>bail out when there are private files that you don't own in >> a directory. In VSTa the only thing you know about a file >>you can't read is its name. >This mostly seems like a feature to me, although it causes wrinkles like the >one you noticed. Setting aside legacy behavior, why should somebody who >isn't supposed to read your file be permitted to know when and how much you >wrote it, and also when you read it? I'd even vote for them not being able to determine the file name. Directories might need a bit of thought, although I can't seen any issue off the top of my head... Marc Boschma From daemon Mon Nov 9 17:29:41 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA06209 for vsta-xplod; Mon, 9 Nov 1998 17:29:41 GMT Received: from tartarus (root@ppp1.annex3.carleton.ca [134.117.253.1]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA06190 for ; Mon, 9 Nov 1998 17:29:35 GMT From: bv056@freenet.carleton.ca Received: by tartarus id m0zabXr-000A5iC (Debian Smail-3.2 1996-Jul-4 #2); Tue, 3 Nov 1998 03:10:31 -0500 (EST) Message-Id: Subject: Re: Permissions In-Reply-To: <199811100323.OAA27578@troy.bms.itg.telecom.com.au> from "Marc A. Boschma" at "Nov 10, 98 02:23:31 pm" To: marcb@bms.itg.telstra.com.au (Marc A. Boschma) Date: Tue, 3 Nov 1998 03:10:31 -0500 (EST) Cc: vsta@zendo.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Marc A. Boschma > >This mostly seems like a feature to me, although it causes wrinkles like the > >one you noticed. Setting aside legacy behavior, why should somebody who > >isn't supposed to read your file be permitted to know when and how much you > >wrote it, and also when you read it? > > I'd even vote for them not being able to determine the file name. > Directories might need a bit of thought, although I can't seen any > issue off the top of my head... How about the fact that it would be redundant, that directory permissions already perform this function? How about the fact that it would be woefully inconsistent with the fact that filenames do not belong to a file but belong to the directory they are contained in? The identity of a file is in its stats and its contents, the filename is an identifier /separate/ from the file. A file remains the same whether it has one, two, many, or even /zero/ filenames; moving a file does not change it, neither does hard linking it. If anything, I don't agree with user permissions in the first place. Access rights should be embedded in the topology of the filesystem, which should in turn allow multiple containment (multiple parents for any directory) in order to properly embed arbitrary access rights. If you do this then you end up with a secure system that doesn't require each and every single file server to authenticate every user at every turn (with the unresolvable security issues /that/ raises). -- When we hear about a murderer, rarely do we want to understand what drove him to murder; more often we wish to kill him. It is difficult to understand that the vengefulness we feel toward a murderer, which drives us to champion execution, is identical to the wish for revenge the murderer feels for what he believes to be the horrendous injustices in his life. -- Dr. Herbert Strean and Lucy Freeman from "Our Wish to Kill". From daemon Tue Nov 10 04:14:09 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA07138 for vsta-xplod; Tue, 10 Nov 1998 04:14:09 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id EAA07132 for ; Tue, 10 Nov 1998 04:14:07 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA11492; Tue, 10 Nov 1998 07:17:30 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id HAA08384; Tue, 10 Nov 1998 07:17:29 -0800 (PST) Message-Id: <199811101517.HAA08384@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: mkshlib mysteries In-reply-to: Your message of "Mon, 09 Nov 1998 09:40:19 EST." Date: Tue, 10 Nov 1998 07:17:29 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >Speaking of open(), what is the status of symbolic links in VSTa? The >file system seems to be required to give an ESYMLINK error if an >attempt is made to open a symlink without the ACC_SYMLINK bit. DOS >does this for files with the hidden flag set, but doesn't seem to >have a way of creating the links. The GNU file utils don't seem to >believe that symlinks can be created at all, and always copy the file >instead. I put the ESYMLINK hooks in to see if the concept worked (it does). I had no pressing need for symlinks once I was sure I knew how to do them, so the rest of the emulation got pushed on the stack. BTW, the DOS thing was a hack; I was really planning on using them along with environment variable links under vstafs. The idea was that in the source directories "mach" would be a symlink to "@MACH", and I'd set MACH to, say, "mach.x86", which would be the source dir with the machine dependent source for that target. Andy From daemon Tue Nov 10 11:04:38 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA07958 for vsta-xplod; Tue, 10 Nov 1998 11:04:38 GMT Received: from mail.ucsd.edu (ucsd.ucsd.edu [132.239.1.1]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA07939 for ; Tue, 10 Nov 1998 11:04:34 GMT Received: from tanya (tanya.ucsd.edu [132.239.141.90]) by mail.ucsd.edu; id OAA09368 sendmail 8.8.8AS/UCSD8.3 via SMTP Tue, 10 Nov 1998 14:08:23 -0800 ( PST) for <@mail.ucsd.edu:vsta@zendo.com> Received: by tanya (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA13783; Tue, 10 Nov 1998 14:08:21 -0800 Message-ID: <19981110140820.C13258@Tanya.ucsd.edu> Date: Tue, 10 Nov 1998 14:08:21 -0800 From: Eric Dorman To: vsta@zendo.com Subject: Re: union mounts References: <199811070025.QAA27771@vandys-pc.cisco.com> <19981106180514.H6678@home.chat.net> <19981107121824.C4117@Tanya.ucsd.edu> <19981107133208.K6678@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: <19981107133208.K6678@home.chat.net>; from David Jeske on Sat, Nov 07, 1998 at 01:32:08PM -0800 On Sat, Nov 07, 1998 at 01:32:08PM -0800, David Jeske wrote: > On Sat, Nov 07, 1998 at 12:18:24PM -0800, Eric Dorman wrote: > > > I find this an interesting concept considering that modern shells walk > > > your 'path' and bring everything into an in-memory hash table > > > anyhow. What's the big win of doing a union bin? > > > > Coz then you don't have to complicate the shell with PATH and > > caching nonsense. Plus one doesn't have to do screwy things with > > mounts if you have clients with different architectures. > > 1) All modern shells (bash,tcsh,zsh) do this regardless of whether you > use union mounts or not. I suppose the union mount lib could keep hash > tables itself. Um, so? These shells need such stuff for traditional unices that have a plague of paths, particularly older systems that don't do path caching in the kernel (if any such still exist). Seems to me one would want to identify that a cache would solve a performance hit rather than adding it just because legacy systems do so or continue carrying around legacy baggage for the sake of continuity (an unfortunate affliction vsta suffers from). > 2) To me it's not so important whether you use union mounts or my > scheme for adding the package to your environment. The important part > is that you specify the package with a logical name (like [etc] Your solution works for end applications on unices (which is lousy for architectural dependencies anyway), but you still do not address the problems associated with different headers with the same name (where is this week? Which version is it? How does Joe User access it?), dependencies on static libraries or apps you may not have source for, and intermediate processing files or databases located outside the scope of the filesystem. Most solutions to these problems are intrusive on the users, complicated to administer or downright impossible to implement in an encapsulated way. > 3) what do you do with union mounts when you have naming collisions? A Plan9-esque MBEFORE/MAFTER option easily resolves collisions in a predictable fashion. If you presume a unix platform, we always use a clean slate when rebuilding an old version. This eliminates subtle dependencies and is a closer representation of the field hardware. > > [xxx 'encapsulation'] > > > This allows me to have lots of versions of the same things installed, > > > and allows me to be more aware of command line naming conflicts. > > This is an advantage? Seems the road to madness, with the possibilities > > of different header, log or data file formats with misc. versions floating > > around. Plus it gets icky quickly if multiple architectures must be > > supported. > The road to madness is forcing everyone to upgrade to a new version at > the same time. You presume we switch everyone at the same time. As far as unix goes, we prefer to exercise 'proactive administration'. New versions are staged outside user purview, then after major milestones dependent applications are brought into the new tree, regression tested, etc until we're happy, then dependencies/applications are switched around with a symlink; there is only the 'old tree' and the 'current tree'. This of course presumes a dependency change doesn't force changing a database structure or somesuch; when that happens we have to migrate data (bleh). The milestone process archives apps with all their dependencies simultaneously, so rebuilding older versions is trivial. I do not recall ever having to build an older version in production (after 'stamping' masters) but the formalism is there. Things with little dependency (ala' netscape-4.03 et al.) are easily pulled from backup if the install is bad; I don't recall ever having to do this, but again the formalism is there. At any rate things are always backed up so bad builds/installs are no big deal. [xxx] > Personally, I like to test the seaworthyness of my next ship before I > sink the old one. Others clearly like to sail the ocean in a more > risky manner. Unfair and ill-informed slight. > FWIW, UnixTools beautifully handles multiple architecutres: > netscape-4.03.encap/sun-solaris/bin/* > i386-linux/bin/* Now add 20 headers, 25 libraries, 12 apps in 3 languages, a pile of shell scripts, 3 daemon users + daemons and a 36Gb database all with a myriad of interdependencies, for 3 architectures. Thus not 'sliced-bread', surely. Users depend on apps, but apps and packages depend on a host of things unrelated to /bin not nearly so easily encapsulated as you suggest. Seems to me one would want to fully exploit the opportunities provided by interacting local namespaces and union directories before importing legacy concepts from architecturally (-backward?) -less-flexible systems. Focussing strictly on 'what does union dirs buy me' ignores that unions (and applications, for that matter) interoperate with the rest of the system in a coherent fashion. I'd prefer Plan9. [xx] > David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net Sincerely Yours, Eric Dorman edorman@ucsd.edu From daemon Tue Nov 10 12:06:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA08079 for vsta-xplod; Tue, 10 Nov 1998 12:06:00 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id MAA08060 for ; Tue, 10 Nov 1998 12:05:56 GMT Received: (qmail 23937 invoked by uid 120); 10 Nov 1998 23:12:59 -0000 Date: Tue, 10 Nov 1998 15:12:59 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: union mounts Message-ID: <19981110151259.U6678@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199811070025.QAA27771@vandys-pc.cisco.com> <19981106180514.H6678@home.chat.net> <19981107121824.C4117@Tanya.ucsd.edu> <19981107133208.K6678@home.chat.net> <19981110140820.C13258@Tanya.ucsd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <19981110140820.C13258@Tanya.ucsd.edu>; from Eric Dorman on Tue, Nov 10, 1998 at 02:08:21PM -0800 This discussion has started to get a bit off topic. However, seeing as it has to do with union mounts and 'doing a better UNIX than UNIX' it still seems somewhat relevant for VSTa. If anyone thinks otherwise, let me know and we can take it private. On Tue, Nov 10, 1998 at 02:08:21PM -0800, Eric Dorman wrote: > > 1) All modern shells (bash,tcsh,zsh) do this regardless of whether you > > use union mounts or not. I suppose the union mount lib could keep hash > > tables itself. > > Um, so? These shells need such stuff for traditional unices that > have a plague of paths, particularly older systems that don't do > path caching in the kernel (if any such still exist). I agree. I realized the weakness of my argument there after writing it. However, I still prefer the shell solution, more below... > Seems to me one would want to identify that a cache would solve a > performance hit rather than adding it just because legacy systems do so > or continue carrying around legacy baggage for the sake of continuity > (an unfortunate affliction vsta suffers from). Agreed. However, I don't like the idea that the architecture of the operating system's filesystem code is 'dissecting my packages' to create command line items. I think about command lines as the first avenue of component software. Now that systems are to a point where we have different types of IPC, and different ways to connect components together, command lines should be one manifestation of a more general component mechanism. As a result, I'd prefer if my packages simply published 'component functionality' and the shell dealt with command line issues. For example, I'd much prefer if we could externalize the ideas of command line options, and piping into the command line shell completly. This would leave merely the component API publishing to the package itself. As a more specific example. I'd prefer if, say, compilers would conform to a 'basic compiler API', which would allow you to control basic compiler functions. The shell could translate these functions into a standard set of command line arguments. Thus, a compile could be setup to use "cc --debuginfo --strict-ansi" and it would work with whatever compiler happened to be bound into the environment. However, I think this is once again getting outside of the scope of the discussion... I'll concede this point as not as important as my next one. > > 2) To me it's not so important whether you use union mounts or my > > scheme for adding the package to your environment. The important part > > is that you specify the package with a logical name (like > [etc] > > Your solution works for end applications on unices (which is lousy > for architectural dependencies anyway), but you still do not address the > problems associated with different headers with the same name (where is > this week? Which version is it? How does Joe User access it?), > dependencies on static libraries or apps you may not have source for, and > intermediate processing files or databases located outside the scope of > the filesystem. Most solutions to these problems are intrusive on the > users, complicated to administer or downright impossible to implement > in an encapsulated way. Actually, my system works really well (IMO) for the above issues. I allow the installation of multiple library/header packages. The packages are identified by logical names instead of physical ones, and the tool system can build you include and library paths automatically, no matter where stuff is installed. For example: PACKAGES=xpm-3.4k mysql-3.21.33 INC_PATHS=`ut.incs ${PACKAGES}` # which expands on my machine to: # -I/usr/local/encap/xpm-3.4k.encap/include \ # -I/home/jeske/local/encap/mysql-3.21.33.encap/include Of course this would be better if the idea of logical packages was pervasive, and I didn't have to shell out to some script to do it. However, this works much better than alternatives for me. > > 3) what do you do with union mounts when you have naming collisions? > > A Plan9-esque MBEFORE/MAFTER option easily resolves collisions in > a predictable fashion. That's not exactly what I was asking. If you have a collision, how do you make sure both versions of the same filename are accessable to the user somehow? > If you presume a unix platform, we always use a clean slate when > rebuilding an old version. This eliminates subtle dependencies > and is a closer representation of the field hardware. This is exactly the kind of unix behavior I don't like. I don't like the idea that UNIX-like systems are like 'castle building'. Start with a foundation (clean slate) and only by laying every custom brick on top can you get to the final destination. Union mounts 'feel' to me to be in the same spirit. I want to lower administartion costs (i.e. things normally associated with cost of ownership). In a sense, I want to 'prefab' as much as possible to interlock in logical instead of physical ways. That way, you can download something which depends on logical functionality or logical packages, instead of having to custom build every system from scratch. > > > [xxx 'encapsulation'] > > > > This allows me to have lots of versions of the same things installed, > > > > and allows me to be more aware of command line naming conflicts. > > > This is an advantage? Seems the road to madness, with the possibilities > > > of different header, log or data file formats with misc. versions floating > > > around. Plus it gets icky quickly if multiple architectures must be > > > supported. > > > The road to madness is forcing everyone to upgrade to a new version at > > the same time. > > You presume we switch everyone at the same time. My presumption was that there was some network shared (NFS/SMB) repository of applications, yes. Although in my opinion, forcing someone to upgrade without being able to keep his old stuff in tact is not usually acceptable. I work in Engineering, so if an IS/IT policy/procedure costs me time, then it's non-optimal. I have come up with the UnixTools system because I was tired of upgrades, old versions, and recreating ancient environments eating up my time. > As far as unix goes, we prefer to exercise 'proactive administration'. > New versions are staged outside user purview, then after major milestones > dependent applications are brought into the new tree, regression tested, > etc until we're happy, then dependencies/applications are switched around > with a symlink; there is only the 'old tree' and the 'current tree'. > > This of course presumes a dependency change doesn't force changing a > database structure or somesuch; when that happens we have to > migrate data (bleh). > > The milestone process archives apps with all their dependencies > simultaneously, so rebuilding older versions is trivial. I do not > recall ever having to build an older version in production (after > 'stamping' masters) but the formalism is there. > > Things with little dependency (ala' netscape-4.03 et al.) are > easily pulled from backup if the install is bad; I don't recall > ever having to do this, but again the formalism is there. At any > rate things are always backed up so bad builds/installs are no > big deal. To me, what you've described above is a 'dictate down' type of administration. The sysadmins/IS people test, configurure and finally push new versions down to users. That's fine, but it dosn't work very well (IMO) when you have people who need to build their own environments. If we had used the above system at my last job we would have had to hire an IS person for every three engineers. I use the UnixTools stuff to provide the ideas you express above to administration that _all_ users can perform. Every user is able to get the robust ability to recreate known environments, to recreate old environments, and to publish the details of environments to other users. > > Personally, I like to test the seaworthyness of my next ship before I > > sink the old one. Others clearly like to sail the ocean in a more > > risky manner. > > Unfair and ill-informed slight. Agreed. I think I understand the distinction between our two approaches now. Correct me if my above summary was incorrect. > > FWIW, UnixTools beautifully handles multiple architecutres: > > netscape-4.03.encap/sun-solaris/bin/* > > i386-linux/bin/* > > Now add 20 headers, 25 libraries, 12 apps in 3 languages, a pile of > shell scripts, 3 daemon users + daemons and a 36Gb database all with > a myriad of interdependencies, for 3 architectures. Thus not > 'sliced-bread', surely. That is exactly the kind of scenerio UnixTools was designed to handle. Personally, I'd prefer to revamp the OS to handle this kind of thing more natively, but given what UNIX offers, I've not seen a mechanism which handled this kind of dependency better than my UnixTools setup. Just remember that one of my prerequisites is that every user needs to have multiple configurations, different users need to have different configurations, and a user needs to be able to recreate an 'old' environment, all without the IS department getting involved or some complicated rebuild. A coworker of mine went on to another job and recreated my UnixTools system with a twist. Instead of building paths and the like, his tools would automatically build symlink trees. Each user could have multiple symlink trees, they would be automatically built and torn down, and standard paths would be pointed at the appropriate symlink environment. I find this less clean than my solution, but it acheved the goals as well. > Users depend on apps, but apps and packages depend on a host of things > unrelated to /bin not nearly so easily encapsulated as you suggest. I agree that the dependencies are not necessarily trivial to specify. However, in my experience, the ability to 'freeze dry' a logical list of packages goes a long way towards taking the 'custom setup' out of Unix installations. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Tue Nov 10 13:28:32 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA08179 for vsta-xplod; Tue, 10 Nov 1998 13:28:32 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id NAA08160 for ; Tue, 10 Nov 1998 13:28:28 GMT Received: (qmail 24386 invoked by uid 120); 11 Nov 1998 00:35:34 -0000 Date: Tue, 10 Nov 1998 16:35:33 -0800 From: David Jeske To: *** VSTa *** Subject: component dependencies (Was: union mounts) Message-ID: <19981110163533.V6678@home.chat.net> Mail-Followup-To: *** VSTa *** Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i I've split this out into a separate discussion, because I think it's getting away from the mechanism of union mounts and into the foundations behind component dependencies. > Seems to me one would want to fully exploit the opportunities > provided by interacting local namespaces and union directories > before importing legacy concepts from architecturally (-backward?) > -less-flexible systems. Focussing strictly on 'what does union dirs > buy me' ignores that unions (and applications, for that matter) > interoperate with the rest of the system in a coherent fashion. Agreed. However, I assure you that it is the interactions of local namespaces and union directories by themselves which I'm denouncing. I don't like the UNIX-inspired use of filename space. It allows add-hoc conventions to be built into a untyped space (the pathname space). It confuses logical and physical namespaces. It allows top-down dependencies to be encoded in conventions instead of explicit dependencies (I apologize if that was confusing, I'll explain more). It is the single largest reason (IMO) that today's system are each 'custom' built. From what I've heard so far, I still maintain that union mounts are another step in that direction, and that's not a direction I want to go. I want to be able to separate configuration data from application data. Or perhaps more generally, mutable application data from non-mutable application data. I would like to move this configuration data and external dependency data external to the applications themselves so it can be managed in a uniform manner. I don't want applications storing information about the physical world in their own custom configuration mechanism. Union mounts approach a solution to this problem, relative to the traditional UNIX model. In a union mount system, one could be sure to make all applications hard-code all 'logical paths'. These paths would exist in the local pathname space, and the union mount system would be the external configuration mechanism by which external physical entities are bound to local logical requirements. However, there is at least one major problem with this. Logical path requirements of an application are not published. This is the only important point of this email: ** The only way to figure out what paths in the local space an ** application may access is to run the application and watch. This is true of both traditional UNIX and union-mount Plan9 style systems. I propose that it's a better solution to explicitly publish all static dependencies of an appliction. If an application requires a version of TCL, I would prefer it publish this explicitly to the OS so the configuration system can be aware of it and bind to that requirement explicitly. In analogy form: 1) The UNIX fixed-pathname space makes every system a construction site of raw materials. First a foundation is formed, and then a building is built on top. However, very little is sent to the site pre-fabricated. Instead, raw materials and plans are delivered. Every building is a little bit different, and each layer is dependent on the last. 2) The Plan9 method allows you to create many buildings. Each building is smaller and more specialized than the UNIX building. However, each building is still construted from raw materials, and each layer must be custom fitted on top of the last. 3) The method I'm proposing is to pre-fabricate parts and ship them to the construction site. To assemble the building, all the 'glue' pieces must be constructed on site. The glue pieces could be measured, documented and reused in connections between those prefab parts in another building. Opensource UNIX is the prime example for my UNIX description, but commercial unicies and applications exhibit this kind of behavior as well with their custom configuration files and often hardcoded install locations. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Tue Nov 10 21:40:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA09254 for vsta-xplod; Tue, 10 Nov 1998 21:40:00 GMT Received: from ns1.casema.net (root@ns1.casema.net [195.96.96.33]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id VAA09235 for ; Tue, 10 Nov 1998 21:39:56 GMT Received: from system (7dyn161.delft.casema.net [195.96.122.161]) by ns1.casema.net (8.9.1/CASEMA-SMTP2) with SMTP id JAA08407 for ; Wed, 11 Nov 1998 09:43:43 +0100 Posted-Date: Wed, 11 Nov 1998 09:43:43 +0100 Message-Id: <199811110843.JAA08407@ns1.casema.net> From: "chefren" To: vsta@zendo.com Date: Wed, 11 Nov 1998 09:43:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: union mounts Priority: normal In-reply-to: <19981110151259.U6678@home.chat.net> References: <19981110140820.C13258@Tanya.ucsd.edu>; from Eric Dorman on Tue, Nov 10, 1998 at 02:08:21PM -0800 X-mailer: Pegasus Mail for Win32 (v3.01b) On 10 Nov 98, at 15:12, David Jeske wrote: > This discussion has started to get a bit off topic. However, seeing as > it has to do with union mounts and 'doing a better UNIX than UNIX' it > still seems somewhat relevant for VSTa. If anyone thinks otherwise, > let me know and we can take it private. Please go on! Or CC me about this if you do wish to take it private. Thanks to all, for your insights on this and other things, +++chefren From daemon Wed Nov 11 04:33:19 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA10051 for vsta-xplod; Wed, 11 Nov 1998 04:33:19 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id EAA10032 for ; Wed, 11 Nov 1998 04:33:15 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id KAA19326; Wed, 11 Nov 1998 10:36:24 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: bv056@freenet.carleton.ca Cc: marcb@bms.itg.telstra.com.au, vsta@zendo.com Date: Wed, 11 Nov 1998 10:32:06 -0500 Subject: Re: Permissions Message-ID: References: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) >How about the fact that it would be redundant, that directory permissions >already perform this function? How about the fact that it would be woefully >inconsistent with the fact that filenames do not belong to a file but belong >to the directory they are contained in? The identity of a file is in its >stats and its contents, the filename is an identifier /separate/ from the >file. A file remains the same whether it has one, two, many, or even /zero/ >filenames; moving a file does not change it, neither does hard linking it. I agree that it would be redundant, given the fact that the directory already has permissions assigned to it by itself. However, the concept of "directory" in VSTa is slightly different than in other OS's. Usually, the filesystem directory item corresponds to an array somewhere on the disk, each entry having a name, length, access permissions, and file allocation information. In VSTa a directory is an arbritrary collection of objects, not necessarily a collection _owned_ by anyone. Consider a server that handles TCP/IP connections. It may publish a directory view of the currently open connections. For example, a file named 12.34.56.78:23(99), could identify a telnet connection using local port 99. Who owns the directory containing these files? It would be inappropriate to allow any old user to monitor the network activity of the entire system by listing this directory. It would make sense though, for them to be able to list their own connections, as well as read, write, and stat them. You could argue in that case, that each user's connections should be kept in a per-user subdirectory of that server's directory structure. IMO, that would add unnecessary complexity. It would be a lot easier if we adopt the simple rule that users can't see what they can't read. >If anything, I don't agree with user permissions in the first place. Access >rights should be embedded in the topology of the filesystem, which should >in turn allow multiple containment (multiple parents for any directory) >in order to properly embed arbitrary access rights. If you do this then >you end up with a secure system that doesn't require each and every single >file server to authenticate every user at every turn (with the unresolvable >security issues /that/ raises). In VSTa, that problem is solved by the kernel passing a trusted structure to every server on MSG_CONNECT. Granted, it is up to the server to properly interpret that structure, but it keeps things simple on the kernel and more importantly, decentralized. There's is nothing in VSTa which contradicts hard linking, it just isn't implemented the way things are set up. I think in order to do that correctly, you'd have to divide the stat query response into two parts: a per-entry section (name, and permissions if you want), and a per-file section (size, revisions, time & date, etc.) In which section the permissions are kept can be up to the file system, just as it's clear to the client where that information is being kept. Eric From daemon Wed Nov 11 10:43:19 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA10645 for vsta-xplod; Wed, 11 Nov 1998 10:43:19 GMT Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA10626 for ; Wed, 11 Nov 1998 10:43:16 GMT Received: (qmail 10549 invoked from network); 11 Nov 1998 21:47:12 -0000 Received: from nathan.enteract.com (mjohnson@207.229.143.6) by thor.enteract.com with SMTP; 11 Nov 1998 21:47:12 -0000 Date: Wed, 11 Nov 1998 15:47:44 -0600 (CST) From: Mark Johnson To: vsta@zendo.com Subject: Re: init can't open inittab In-Reply-To: <199811070029.QAA27845@vandys-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I loaded VSTa 1.6.1 to a desktop without a hitch. I then reformatted the laptop that I was having problems with and reinstalled 1.6.1 and now everything works, well except that /tmp shows up twice in ls and I can't cd to /tmp. I'm chalking this up to flaky hardware. -- Mark Johnson mjohnson@enteract.com From daemon Wed Nov 11 10:46:54 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA10674 for vsta-xplod; Wed, 11 Nov 1998 10:46:54 GMT Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA10655 for ; Wed, 11 Nov 1998 10:46:50 GMT Received: (qmail 10819 invoked from network); 11 Nov 1998 21:50:47 -0000 Received: from nathan.enteract.com (mjohnson@207.229.143.6) by thor.enteract.com with SMTP; 11 Nov 1998 21:50:47 -0000 Date: Wed, 11 Nov 1998 15:51:19 -0600 (CST) From: Mark Johnson To: vsta@zendo.com Subject: VSTa Port for SPARC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've seen mention of people porting VSTa to SPARC. Are people actively working on it? -- Mark Johnson mjohnson@enteract.com From daemon Wed Nov 11 12:33:33 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA10941 for vsta-xplod; Wed, 11 Nov 1998 12:33:33 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA10935 for ; Wed, 11 Nov 1998 12:33:30 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA18466; Wed, 11 Nov 1998 15:36:56 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id PAA11356; Wed, 11 Nov 1998 15:36:56 -0800 (PST) Message-Id: <199811112336.PAA11356@vandys-pc.cisco.com> To: Mark Johnson cc: vsta@zendo.com Subject: Re: VSTa Port for SPARC In-reply-to: Your message of "Wed, 11 Nov 1998 15:51:19 CST." Date: Wed, 11 Nov 1998 15:36:55 -0800 From: Andy Valencia [Mark Johnson writes:] >I've seen mention of people porting VSTa to SPARC. Are people actively >working on it? Nope, I think there was a very small amount of work long ago, and it was dropped. The 68k port got fully operational, and I got a MIPS port far enough along that you could run programs, but there were some latent cache coloring bugs left. Andy From daemon Thu Nov 12 06:45:07 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA13190 for vsta-xplod; Thu, 12 Nov 1998 06:45:07 GMT Received: from sims-ha.videotron.net (faure.videotron.net [205.151.222.100]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA13171 for ; Thu, 12 Nov 1998 06:45:04 GMT From: dufrp@oricom.ca Received: from 207.96.204.127 (ts3-127.oricom.ca) by sims-ha.videotron.net (Sun Internet Mail Server sims.3.5.1998.07.14.10.43) with SMTP id <0F2B005SWLHET1@sims-ha.videotron.net> for vsta@zendo.com; Thu, 12 Nov 1998 12:48:53 -0500 (EST) Date: Thu, 12 Nov 1998 12:48:53 -0500 (EST) Date-warning: Date header was inserted by sims-ha.videotron.net Subject: Worth to download text.tz? To: vsta@zendo.com Message-id: <0F2B005T0LHFT1@sims-ha.videotron.net> MIME-version: 1.0 X-Mailer: MailSender for Oberon (ejz) Content-type: TEXT/PLAIN; CHARSET=US-ASCII What is inside text.tz, I'd like to know if I should download it. By the way I have been able to install VSTa. Is there man pages somewhere, because there are many commands I still don't know how to use? From daemon Thu Nov 12 10:02:42 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA13561 for vsta-xplod; Thu, 12 Nov 1998 10:02:42 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA13555 for ; Thu, 12 Nov 1998 10:02:40 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA27246; Thu, 12 Nov 1998 13:06:09 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id NAA13037; Thu, 12 Nov 1998 13:06:08 -0800 (PST) Message-Id: <199811122106.NAA13037@vandys-pc.cisco.com> To: dufrp@oricom.ca cc: vsta@zendo.com Subject: Re: Worth to download text.tz? In-reply-to: Your message of "Thu, 12 Nov 1998 12:48:53 EST." <0F2B005T0LHFT1@sims-ha.videotron.net> Date: Thu, 12 Nov 1998 13:06:08 -0800 From: Andy Valencia [dufrp@oricom.ca writes:] >What is inside text.tz, I'd like to know if I should download it. It's the GNU set of text utilities. The binaries should already be available, so unless you want to build something from source, you can skip it. >By the way I have been able to install VSTa. >Is there man pages somewhere, because there are many commands I still don't kn >ow how to use? To this point, it's kind of assumed that you'll either know the commands, or be able to look at the man pages elsewhere. A groff port wouldn't be hard, except that it's written in C++, and being a C++ ludite, I never messed with trying to port that part of GNU C. Andy From daemon Wed Nov 18 06:22:50 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA29599 for vsta-xplod; Wed, 18 Nov 1998 06:22:50 GMT Received: from atlas.nuview.com (atlas.nuview.com [38.247.155.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA29577 for ; Wed, 18 Nov 1998 06:22:38 GMT Received: from ALTAIR by atlas.nuview.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id RXWC08T2; Wed, 18 Nov 1998 11:34:46 -0600 From: Eddie McCreary MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13907.800.743000.328001@ALTAIR> Date: Wed, 18 Nov 1998 11:25:52 -0600 (Central Standard Time) To: vsta@zendo.com Subject: TERM not defined? X-Mailer: VM 6.62 under 21.0 "Poitou" XEmacs Lucid I've just installed the latest release after not playing with Vsta for a while, and I can't seem to get it working quite right. I'm having the same problem described in: http://www.zendo.com/vsta/mail/11/0001.html in that TERM doesn't seem to be defined, therefore emacs won't work fullscreen. I've tried manually setting TERM in different ways, but nothing seems to work. I've browsed the mail list archives, but no answer was ever posted that I can find. thanks for any suggestions. eddie -- Some books are to be tasted, others to be swallowed, and some few to be chewed and digested. Francis Bacon Eddie McCreary mailto:forge@neosoft.com http://www.neosoft.com/~forge From daemon Sun Nov 22 13:54:53 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA12783 for vsta-xplod; Sun, 22 Nov 1998 13:54:53 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA12777 for ; Sun, 22 Nov 1998 13:54:51 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA08573; Sun, 22 Nov 1998 16:58:49 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id QAA06762; Sun, 22 Nov 1998 16:58:48 -0800 (PST) Message-Id: <199811230058.QAA06762@vandys-pc.cisco.com> To: Eddie McCreary cc: vsta@zendo.com Subject: Re: TERM not defined? In-reply-to: Your message of "Wed, 18 Nov 1998 11:25:52 CST." <13907.800.743000.328001@ALTAIR> Date: Sun, 22 Nov 1998 16:58:48 -0800 From: Andy Valencia [Eddie McCreary writes:] >I've just installed the latest release after not playing with Vsta for >a while, and I can't seem to get it working quite right. I'm having >the same problem described in: > >http://www.zendo.com/vsta/mail/11/0001.html > >in that TERM doesn't seem to be defined, therefore emacs won't work >fullscreen. I've tried manually setting TERM in different ways, but >nothing seems to work. I've browsed the mail list archives, but no >answer was ever posted that I can find. Are the files in /env present? You can do "echo `cat /env/TERM`" to see'em (they don't have trailing newlines, so a simple "cat /env/TERM"'s output gets overwritten by the following shell prompt). If not, does "echo -n nansi > /env/TERM" change the behavior? For now, if you've put anything mentioning TERM into your profile or other login files, take it back out. It's best to get the system-wide default working first, and then mess with per-user, and then per-session variants. Andy From daemon Mon Nov 23 17:56:13 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA16421 for vsta-xplod; Mon, 23 Nov 1998 17:56:13 GMT Received: from smtp-01.neosoft.com (smtp-01.neosoft.com [206.109.1.19]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id RAA16402 for ; Mon, 23 Nov 1998 17:56:10 GMT Received: (qmail 10304 invoked by uid 101); 24 Nov 1998 05:00:40 -0000 Received: from mailbox.neosoft.com (206.109.1.16) by smtp-01.neosoft.com with SMTP; 24 Nov 1998 05:00:40 -0000 Received: from heorot.home.org (root@digital-07-218.hou.neosoft.com [206.109.31.218]) by mailbox.neosoft.com (8.8.8/1.0.1) with SMTP id XAA06756; Mon, 23 Nov 1998 23:00:38 -0600 (CST) Received: from heorot.home.org by heorot.home.org with smtp (Smail3.1.29.1 #3) id m0ziAiv-000octC; Mon, 23 Nov 98 23:09 CST From: Eddie McCreary Date: Mon, 23 Nov 1998 23:09:13 -0600 (CST) To: Andy Valencia Cc: vsta@zendo.com Subject: Re: TERM not defined? In-Reply-To: <199811230058.QAA06762@vandys-pc.cisco.com> References: <13907.800.743000.328001@ALTAIR> <199811230058.QAA06762@vandys-pc.cisco.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13914.16035.46576.642529@heorot.home.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII I found it, I had unzipped the tar files with WinZip which translate the \n line breaks into \r\n. I still had a few problems with not being able to create files under /vsta, so I tried the tar.exe from zendo, but had the same problem. So, I booted into DOS, scanned the disk for errors, ran defrag, and then extracted the whole shebang with tar.exe again. Now everything seems to be working fine! Thanks to everyone who emailed suggestions. eddie -- Some books are to be tasted, others to be swallowed, and some few to be chewed and digested. Francis Bacon Eddie McCreary mailto:forge@neosoft.com http://www.neosoft.com/~forge From daemon Mon Nov 23 16:19:17 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA16166 for vsta-xplod; Mon, 23 Nov 1998 16:19:17 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA16147 for ; Mon, 23 Nov 1998 16:19:08 GMT Received: from endymion (modem_g [199.93.212.249]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id WAA28625 for ; Mon, 23 Nov 1998 22:21:08 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: Hmm. GRUB doesn't seem to work... Date: Mon, 23 Nov 1998 22:18:24 -0500 Message-ID: <000001be1759$18926c90$f9d45dc7@endymion.eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 I've got a machine I'm trying to put GRUB onto so I can boot VSTa. Currently, the machine has got: 2GB NTFS 70MB Linux Swap 1.7GB Linux EXTFS 257MB VSTa and I use NT Loader to boot into LILO, then into Linux (painful, but it works). What I've been trying to do is replace the NT Loader and LILO steps with GRUB, which would also allow me to boot into VSTa. I can make a floppy with GRUB on it, boot it, and from there, boot into VSTa, NT, and Linux. However, when I put GRUB onto the hard disk using the following: install=(fd0)+1 d (hd0) (hd0,2)/boot/grub/stage2 0x8000 p or any number of variants of it, I get nothing. It looks like it's not even getting to stage1, because I hacked it to beep the speaker when the system boots, which works on the floppy, but not on the hard disk. Any ideas anyone? An alternative (less attractive) is to use LILO. I tried using Dave's VSTaBIT to build a bootable image, but that doesn't seem to work with 1.6.1? From daemon Mon Nov 23 20:40:51 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id UAA16852 for vsta-xplod; Mon, 23 Nov 1998 20:40:51 GMT Received: from ariel.kotelna.sk (mato@d140.diana.paradise.net.nz [203.96.158.140]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id UAA16833 for ; Mon, 23 Nov 1998 20:40:46 GMT Received: (from mato@localhost) by ariel.kotelna.sk (8.9.1a/8.9.1/PARANOID) id UAA00341; Tue, 24 Nov 1998 20:44:43 +1300 Message-ID: <19981124204443.A333@ariel.kotelna.sk> Date: Tue, 24 Nov 1998 20:44:43 +1300 From: Martin Lucina To: Gavin Thomas Nicol Cc: vsta@zendo.com Subject: Re: Hmm. GRUB doesn't seem to work... References: <000001be1759$18926c90$f9d45dc7@endymion.eps.inso.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <000001be1759$18926c90$f9d45dc7@endymion.eps.inso.com>; from Gavin Thomas Nicol on Mon, Nov 23, 1998 at 10:18:24PM -0500 On Mon, Nov 23, 1998 at 10:18:24PM -0500, Gavin Thomas Nicol wrote: > > install=(fd0)+1 d (hd0) (hd0,2)/boot/grub/stage2 0x8000 p > > or any number of variants of it, I get nothing. It looks like > it's not even getting to stage1, because I hacked it to beep the You need to put a clean stage1 file somewhere and install from that. Do something like install=(hd0,2)/boot/stage1 d (hd0) ... make sure the file that you use is from the bin directory, not from your floppy boot sector as GRUB removes some code from the boot sector when it installs a stage1 to it. > An alternative (less attractive) is to use LILO. I tried using > Dave's VSTaBIT to build a bootable image, but that doesn't seem to > work with 1.6.1? Nope, 1.6.1 is multboot-only as far as I'm aware (Andy?). Martin From daemon Tue Nov 24 19:09:15 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA18470 for vsta-xplod; Tue, 24 Nov 1998 09:35:40 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA18451 for ; Tue, 24 Nov 1998 09:35:33 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id PAA21313; Tue, 24 Nov 1998 15:36:54 -0500 (EST) From: "Gavin Thomas Nicol" To: "Martin Lucina" Cc: Subject: RE: Hmm. GRUB doesn't seem to work... Date: Tue, 24 Nov 1998 15:40:18 -0500 Message-ID: <000101be17ea$a5a56a60$577670c6@endymion.eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <19981124204443.A333@ariel.kotelna.sk> > > install=(fd0)+1 d (hd0) (hd0,2)/boot/grub/stage2 0x8000 p > > > > or any number of variants of it, I get nothing. It looks like > > it's not even getting to stage1, because I hacked it to beep the > > You need to put a clean stage1 file somewhere and install from that. Do > something like > > install=(hd0,2)/boot/stage1 d (hd0) ... > > make sure the file that you use is from the bin directory, not from your > floppy boot sector as GRUB removes some code from the boot sector when it > installs a stage1 to it. I tried this too, but got the same result. The weird thing is that I tried the first line in a poxy old laptop I have (486 DX2, 8MB memory, 250MB disk), and it worked fine! Hmmm... From daemon Sun Nov 29 19:07:56 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA13722 for vsta-xplod; Sun, 29 Nov 1998 19:07:56 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id TAA13697 for ; Sun, 29 Nov 1998 19:04:06 GMT Message-Id: <199811291904.TAA13697@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: vsta@zendo.com Subject: Distributed VSTa Date: Sun, 29 Nov 1998 19:04:06 +0000 From: Andy Valencia Over this weekend I had a laptop without a vstafs partition (so I couldn't hunt that race condition) so I instead hacked on networking and proxyd. The result was this evening I was able to mount a filesystem: mount fs/root:tmp@205.187.71.66 /dist from a stock shell (i.e., no special mods to the mounting code--the hooks are beneath this in path_open()), and then "cd /dist" and "ls". All the underlying microkernel messages for dup'ing access from the mount table, process forks, stat's, and the actual readdir() stuff were transparently carried across the network, and I was able to access the filesystem and files correctly. The destination filesystem was also, of course, stock code. I'm not sure this is the best syntax. Normally it would be: mount fs/root:tmp /dist which would ask the namer for the server registered as serving fs/root (i.e., the root filesystem), and then access the "tmp" subdirectory of that filesystem. Thus, /tmp from the root filesystem would be seen as /dist. By adding the "@" suffix, this same request occurs, but out on the named remote system. You end up with an open port as before, but now your port actually goes to the TCP/IP stack, across a TCP connection to the remote, and into an instance of "proxyd" (from src/srv/ka9q/cmd/proxyd.c) which does the I/O on your behalf. So anything in VSTa which runs using kernel IPC (i.e., most things) can now be accessed remotely. Hmmm, I think I'll union mount a remote /proc, and then I can get process lists and kill processes from my local shell with the normal shell commands. ;-> Andy From daemon Mon Nov 30 04:22:28 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA14653 for vsta-xplod; Mon, 30 Nov 1998 04:22:28 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id EAA14634 for ; Mon, 30 Nov 1998 04:22:23 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id KAA12119 for ; Mon, 30 Nov 1998 10:48:52 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: More on GRUB woes Date: Mon, 30 Nov 1998 10:52:07 -0500 Message-ID: <000b01be1c79$61d45b00$577670c6@endymion.eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-reply-to: <199811291904.TAA13697@bodhi.zendo.com> Importance: Normal Unlike Andy, I had a non-productive weekend. I walked through the GRUB code, instrumenting it like it was in 0.4, and finally found that on my machine, the following is where is dies. /* divw (%si), %dx:%ax */ /* divide by number of sectors */ .byte 0xf7, 0x34 I haven't got much further than that. Any ideas? From daemon Mon Nov 30 06:17:13 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA15113 for vsta-xplod; Mon, 30 Nov 1998 06:17:13 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id GAA15093; Mon, 30 Nov 1998 06:17:09 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id MAA26385; Mon, 30 Nov 1998 12:45:41 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@zendo.com Cc: vsta@zendo.com Date: Mon, 30 Nov 1998 12:20:08 -0500 Subject: Re: Distributed VSTa Message-ID: References: <199811291904.TAA13697@bodhi.zendo.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) >Over this weekend I had a laptop without a vstafs partition (so I couldn't >hunt that race condition) so I instead hacked on networking and proxyd. >The result was this evening I was able to mount a filesystem: > > mount fs/root:tmp@205.187.71.66 /dist Sounds great! I really haven't gotten into much networking with VSTa, but that's really cool. >I'm not sure this is the best syntax. Normally it would be: > > mount fs/root:tmp /dist > >which would ask the namer for the server registered as serving fs/root >(i.e., the root filesystem), and then access the "tmp" subdirectory of >that filesystem. Thus, /tmp from the root filesystem would be seen as >/dist. Perhaps it would be appropriate to break out another abstraction layer and use something like: mount fs/root:tmp@//net/tcpip/205.187.71.66 /dist Then those of us without ethernet can still play with it by doing mount fs/root:tmp@//tty/rs232 /dist In fact, it would be possible to run it off of a local pipe in this manner, for testing and debugging. >By adding the "@" suffix, this same request occurs, but out on the >named remote system. You end up with an open port as before, but now your >port actually goes to the TCP/IP stack, across a TCP connection to the >remote, and into an instance of "proxyd" (from src/srv/ka9q/cmd/proxyd.c) >which does the I/O on your behalf. I'm still confused about how the ka9q suite works. I didn't have an ethernet card to play with, but when I launched it I got a command-line interface. Is there a separate set of TCP/IP servers, or how does it work? >So anything in VSTa which runs using kernel IPC (i.e., most things) can >now be accessed remotely. Hmmm, I think I'll union mount a remote /proc, >and then I can get process lists and kill processes from my local shell >with the normal shell commands. ;-> Hey, you could mount a virtual console on the other machine, and then run a local login on that console! I'll bet that would really confuse the other user. Or how about mounting their pipes and putting funny messages as they page through with less. Heheh, this could be fun. From daemon Mon Nov 30 06:43:15 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA15158 for vsta-xplod; Mon, 30 Nov 1998 06:43:15 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA15152 for ; Mon, 30 Nov 1998 06:43:12 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA08667; Mon, 30 Nov 1998 10:11:44 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id KAA22258; Mon, 30 Nov 1998 10:11:44 -0800 (PST) Message-Id: <199811301811.KAA22258@vandys-pc.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Distributed VSTa In-reply-to: Your message of "Mon, 30 Nov 1998 12:20:08 EST." Date: Mon, 30 Nov 1998 10:11:44 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >Perhaps it would be appropriate to break out another abstraction layer >and use something like: > mount fs/root:tmp@//net/tcpip/205.187.71.66 /dist >Then those of us without ethernet can still play with it by doing > mount fs/root:tmp@//tty/rs232 /dist Really, you should still use KA9Q, and SLIP over the serial line. The problem with raw access like this is that you manually have to ensure that nobody multiplexes. In a fork/exec environment this may end up being harder than you think. >In fact, it would be possible to run it off of a local pipe in this >manner, for testing and debugging. You can already do this. KA9Q is happy to have an IP address without any network interfaces, and then you can open TCP/IP connections to your local servers. I do this to test networking all the time. >I'm still confused about how the ka9q suite works. I didn't have an >ethernet >card to play with, but when I launched it I got a command-line >interface. >Is there a separate set of TCP/IP servers, or how does it work? TCP/IP is not related to any particular network interface. You can have a TCP/IP stack with a local IP address, and no networking interfaces. >Hey, you could mount a virtual console on the other machine, and then >run a local login on that console! I'll bet that would really confuse >the other user. Yes, that should work. You'd have to make sure there wasn't already a local login trying to serve that console screen, but otherwise this should be fine. >Or how about mounting their pipes and putting funny messages as >they page through with less. I think this would usually end up just acting like a slow pipe() implementation. Except that you could kill off your local pipe server and pipes would still work. More interesting would be to mount a single /env from multiple PC's; then all the systems would exist in a common hierarchical environment namespace. Andy From daemon Mon Nov 30 08:53:52 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA15510 for vsta-xplod; Mon, 30 Nov 1998 08:53:52 GMT Received: from kotol.kotelna.sk (mato@kotol.kotelna.sk [158.195.19.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA15491 for ; Mon, 30 Nov 1998 08:53:43 GMT Received: (from mato@localhost) by kotol.kotelna.sk (8.8.5/8.8.5) id VAA31402 for vsta@zendo.com; Mon, 30 Nov 1998 21:22:34 +0100 Message-ID: <19981130212233.A31372@kotelna.sk> Date: Mon, 30 Nov 1998 21:22:33 +0100 From: Martin Lucina To: vsta@zendo.com Subject: Re: Distributed VSTa References: <199811291904.TAA13697@bodhi.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811291904.TAA13697@bodhi.zendo.com>; from Andy Valencia on Sun, Nov 29, 1998 at 07:04:06PM +0000 Andy Valencia (vandys@zendo.com) wrote : > > mount fs/root:tmp /dist > > which would ask the namer for the server registered as serving fs/root > (i.e., the root filesystem), and then access the "tmp" subdirectory of > that filesystem. Thus, /tmp from the root filesystem would be seen as > /dist. > > By adding the "@" suffix, this same request occurs, but out on the Cool. One thing that bothered me when you introduced the // syntax for talking to the namer is that I would really like to see //203.96.5.14/tmp/ work, somewhat like DomainOS or QNX. Maybe `mount' isn't the right name for what we're doing, but we could use simply mount //203.96.5.14/tmp /dist or mount //203.96.5.14/fs/root:tmp /dist Unfortunately I don't have a DomainOS box around, but maybe it would be worthwhile to have a look because I'm sure that you could do the same thing we're doing with mount now AND at the same time transparently access files wihout mounting anything using the //host/path syntax. Comments, anyone? Martin From daemon Mon Nov 30 10:20:20 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA15705 for vsta-xplod; Mon, 30 Nov 1998 10:20:20 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA15686 for ; Mon, 30 Nov 1998 10:20:12 GMT Received: (qmail 27218 invoked by uid 120); 30 Nov 1998 21:52:20 -0000 Date: Mon, 30 Nov 1998 13:52:19 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: Distributed VSTa Message-ID: <19981130135219.H5324@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199811291904.TAA13697@bodhi.zendo.com> <19981130212233.A31372@kotelna.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <19981130212233.A31372@kotelna.sk>; from Martin Lucina on Mon, Nov 30, 1998 at 09:22:33PM +0100 This is going to strike deeper into some OS philosophy than just the naming of proxied objects, but I think it's important stuff. (IMO) Much of UNIX's management problems come from the inability to easily 'vm' (i.e. virtual machine, i.e. fake, remap, etc) the runtime environment. VSTa's process local pathname space (in the spirit of plan9) improves this, but the namer is not VMable, so the more VSTa relys on it, the more it falls into the same problems UNIX did. On Mon, Nov 30, 1998 at 09:22:33PM +0100, Martin Lucina wrote: > > By adding the "@" suffix, this same request occurs, but out on the > > Cool. One thing that bothered me when you introduced the // > syntax for talking to the namer is that I would really like to see > //203.96.5.14/tmp/ work, somewhat like DomainOS or QNX. Maybe > `mount' isn't the right name for what we're doing, but we could use > simply Curious, I really dislike that approach. When you allow the pathname space to become an add-hoc repository for information, you increase the potential for hard-coded dependencies to end up buried everwhere in the system. I'd prefer to force the namespace to exist in it's purely symbolic form in the namer and mount code, and any magic of mounting proxied objects into the local namespace to happen outside of the mount path syntax. For example, instead of your examples below: > mount //203.96.5.14/tmp /dist > > or > > mount //203.96.5.14/fs/root:tmp /dist I'd prefer it if there were a command to tell the proxy server to map "//fs/root@204.96.5.14" to the local "//remote/fs/root" and then have any use of the mount command refer to that proxied object by it's local symbolic name "//remote/fs/root". This assures that if you want to use scripts or environments which are dependent on that network proxied object work elsewhere, you merely need to provide "//remote/*" symbolically, not literally. If there were to be a "//" syntax, I'd prefer to see it as a product of a custom namer, so that was really just another symbolic part of the namespace which this particular namer knew to map to IP addresses, but which in another setup could be remapped to something else. ===== However, I don't think this increased focus on the namespace syntax is a good direction. I assert that bindings between the system services (in unix, files) and applications need to be (re)mappable. UNIX didn't do a very good job of this, chroot() is seldom used and dosn't work the way one would like. Plan9 fixed this problem by having applications still focus on the UNIX-like pathname space, but by allowing process local mounting into this pathname space. It's key that Plan9 programs still get the mouse from "/dev/mouse". If VSTa programs start doing things like getting the mouse from "//mouse", then we've gone back to the non-remappable unix model again, and I think that's a step in the wrong direction. If VSTa is to pull devices and services out of the 'pathname space' proper (i.e. don't have devices be files in the pathname space like Plan9 and UNIX), then IMO we should come up with a mechanism to allow the namer mappings to be per-process. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Mon Nov 30 11:17:11 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA15968 for vsta-xplod; Mon, 30 Nov 1998 11:17:11 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA15962 for ; Mon, 30 Nov 1998 11:17:09 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA16916; Mon, 30 Nov 1998 14:45:42 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id OAA23231; Mon, 30 Nov 1998 14:45:42 -0800 (PST) Message-Id: <199811302245.OAA23231@vandys-pc.cisco.com> To: David Jeske Cc: vsta@zendo.com Subject: Re: Distributed VSTa In-reply-to: Your message of "Mon, 30 Nov 1998 13:52:19 PST." <19981130135219.H5324@home.chat.net> Date: Mon, 30 Nov 1998 14:45:42 -0800 From: Andy Valencia [David Jeske writes:] >I'd prefer it if there were a command to tell the proxy server to map >"//fs/root@204.96.5.14" to the local "//remote/fs/root" and then have >any use of the mount command refer to that proxied object by it's >local symbolic name "//remote/fs/root". This assures that if you want >to use scripts or environments which are dependent on that network >proxied object work elsewhere, you merely need to provide "//remote/*" >symbolically, not literally. I feel like I'm quibbling semantics, but... Isn't this the same as saying that you use "mount" to to bind the remote object to its local name, and then all applications use the local name. Why is it inherently superior to impose the level of indirection *before* the mount command? >If VSTa is to pull devices and services out of the 'pathname space' >proper (i.e. don't have devices be files in the pathname space like >Plan9 and UNIX), then IMO we should come up with a mechanism to allow >the namer mappings to be per-process. Ah, I see your point now. If we use /dev/mouse (be it a local device driver found via namer, or a remote mounted via the net) then you have a point of indirection, and thus could virtualize it (ala 8.5 windows). If we use //dev/mouse, you don't, and can't (as it were). The use of // is not too prevalent in SW--we could back away from this technique. Its use mostly stems from resources which are used for one single purpose, ever--it is both a conceptual and run-time burden to demand that they always be a part of your pathname space, and yet requiring that they be mounted before use created a--usually--unneeded extra step in starting things like filesystems on top of disk drives. OTOH, per-user overrides for namer node values wouldn't be too terribly difficult to implement. We could likely steal some tricks from /env, which also implements a somewhat different nature of per-user data values. We could agree to press forward, and implement such a beast when a fully self-virtualizing windowing system, or a related need, finally became pressing. Andy From daemon Mon Nov 30 11:46:30 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA16107 for vsta-xplod; Mon, 30 Nov 1998 11:46:30 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id LAA16088 for ; Mon, 30 Nov 1998 11:46:25 GMT Received: (qmail 27767 invoked by uid 120); 30 Nov 1998 23:18:39 -0000 Date: Mon, 30 Nov 1998 15:18:39 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: Distributed VSTa Message-ID: <19981130151839.J5324@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981130135219.H5324@home.chat.net> <199811302245.OAA23231@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <199811302245.OAA23231@vandys-pc.cisco.com>; from Andy Valencia on Mon, Nov 30, 1998 at 02:45:42PM -0800 On Mon, Nov 30, 1998 at 02:45:42PM -0800, Andy Valencia wrote: > I feel like I'm quibbling semantics, but... Agreed, and I hate to feel that way, but I think it's a bit more than that and I hope someone thinks there is some useful information in here. This email finishes my point. > >If VSTa is to pull devices and services out of the 'pathname space' > >proper (i.e. don't have devices be files in the pathname space like > >Plan9 and UNIX), then IMO we should come up with a mechanism to allow > >the namer mappings to be per-process. > > Ah, I see your point now. If we use /dev/mouse (be it a local device driver > found via namer, or a remote mounted via the net) then you have a point of > indirection, and thus could virtualize it (ala 8.5 windows). If we use > //dev/mouse, you don't, and can't (as it were). Exactly... > The use of // is not too prevalent in SW--we could back away from > this technique. Its use mostly stems from resources which are used for one > single purpose, ever--it is both a conceptual and run-time burden to demand > that they always be a part of your pathname space, and yet requiring that > they be mounted before use created a--usually--unneeded extra step in > starting things like filesystems on top of disk drives. Exactly. The "//:" syntax making it's way into the standard lib, and the recent discussion of incorporating some node/ip naming syntax both put more emphasis on the namer as a vendor of system resources. If namer is going to be a vendor of system resources, then (IMO) it needs to be virtualizable (i.e. have a level of indirection). > OTOH, per-user overrides for namer node values wouldn't be too terribly > difficult to implement. We could likely steal some tricks from /env, which > also implements a somewhat different nature of per-user data values. We > could agree to press forward, and implement such a beast when a fully > self-virtualizing windowing system, or a related need, finally became > pressing. Certainly, but I think the question is 'do you want to?' In other words, is VSTa (1) following Plan9/UNIX in putting system services within the pathname space or (2) using the namer as a repository for system services, from which the local pathspace (storage space) is built. Moving back to the 'proxy node naming' discussion: If (1) then the qnx-esq node naming can be handled by mounting a 'node redirector' into the pathname space. For example, union mount the proxy resolver into "/" and allow "/@204.94.139.85/fs/root" to map to the right place. If (2) then the namer can provide the funcitonality, or you can mount the functionality into the namer-namespace, but the namer needs to be per-process. In either case, I might consider it bad practice for someone to write software which hard-coded node names or IP addresses into paths, but either strategy allows me to redirect them. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Mon Nov 30 21:48:47 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA17512 for vsta-xplod; Mon, 30 Nov 1998 21:48:47 GMT Received: from yoda.fdt.net (foo@yoda.fdt.net [209.212.128.32]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id VAA17493 for ; Mon, 30 Nov 1998 21:48:44 GMT Received: (from foo@localhost) by yoda.fdt.net id EAA29850; Tue, 1 Dec 1998 04:17:33 -0500 Date: Tue, 1 Dec 1998 04:17:33 -0500 From: wish you were here Message-Id: <199812010917.EAA29850@yoda.fdt.net> To: gtn@eps.inso.com CC: vsta@zendo.com In-reply-to: <000501be1cf2$792e8db0$f8d45dc7@endymion.eps.inso.com> (gtn@eps.inso.com) Subject: RE: Distributed VSTa After being much inspired by seeing work being done in the direction that interests me most, I am compelled to post. After thought, I have devised a solution for the remote naming procedure that looks like it'll solve a lot more too! Many suggestions for remote naming have been suggested, most of which involve adding a second syntax to bind or making many ip-specific assumptions that are IM (highly religious) HO "wrong", in the same way that the way unix comes up with ethernet names like "le0" is wrong: It should be in the filesystem like anythign else! I don't really like any syntax that makes hard-and-fast assumptions about protocols or server names. An system should provide a resource naming syntax that is consistent, comprehensive, and minimalist. The ability to serve up combinations not involving say NFS-over-IPandDNS-over-ETHER hardwired in is a great win. Ideally, a mount is a transparent translation between a source and a destination. we'll call this new mount "bind"... it's like plan9 in syntax, but modular like hurd translators mount etherd:/dev/dectulip/0 /net/ipstack/my-ethernet-addr ..... (put all the network devices in /net/ipstack) mount ipd:/net/ipstack /net/ip (create an IP stack) mount nfsd:/net/ip/udp/nfs/mynfs-server-ip /here/is/mystuff One simple (compared to kernel), userland daemon gives us: mount smbd:/net/ip/tcp/smb/mysamba-server-ip /here/is/morestuff Plus, we gain: mount pppd:/dev/rs232/0 /net/ipstack/my-ppp-addr Or even: (instant IP tunnelling) mount pppd:/net/ip/tcp/ip-tun-port/ip-tun-host /net/ipstack/foo-addr mount pppd:/net/ip/tcp-ssl/ip-t-p/ip-t-h /net/ipstack/cryptotunnel And even: (whee! snag someone else's IP stack for no memory use!) mount etherd:/dev/ether0 /net/simplestack/0 mount simpled:/net/simplestack /net/simple mount simplemount:/net/simple/simplemount/hostname /net/ip which i think is... really neato! Flaws: Requires knowing of IP addr before making connection, which is bad for PPP. Can be solved trivially Requires a mount for every address using this syntax, otherwise more within-daemon code would be needed to do things like mount httpreadd:/net/ip/tcp-http/ /net/web would work. Can be solved not-so-trivially comments? ksh From daemon Mon Nov 30 23:53:21 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id XAA17712 for vsta-xplod; Mon, 30 Nov 1998 23:53:21 GMT Received: from tartarus (root@ppp40.annex9.carleton.ca [134.117.248.40]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id XAA17693 for ; Mon, 30 Nov 1998 23:53:11 GMT From: bv056@freenet.carleton.ca Received: by tartarus id m0zkZn7-000A5gC (Debian Smail-3.2 1996-Jul-4 #2); Mon, 30 Nov 1998 15:19:29 -0500 (EST) Message-Id: Subject: on the question of namespace locality To: vsta@zendo.com Date: Mon, 30 Nov 1998 15:19:29 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In Plan 9, two different concepts are confused under the name "locality". One, the concept of locality, and two, the concept of disconnectedness. In Plan 9, you don't merely have local namespaces, you have completely disconnected namespaces. In your everyday filesystem, a file is local to the directory that contains it but it is not disconnected from files in every other directory. So Plan 9 doesn't just have local namespaces, it has *disconnected* namespaces; which according to reports is a Bad Idea. The decision to go the disconnected route is actually an ugly kludge to patch up a problem the designers refused to solve elegantly. The problem is that users need local access to global resources. The simple solution is to just hard link files you want access to, and that actually works out pretty well. And if the resource is represented by a directory then the problem is resolved by making directories hard linkable! Now, if we've determined that disconnectedness is a Bad Idea then mounts are unacceptable. Within a single filesystem, hard links make mounts unnecessary and ugly. Between two separate filesystems, you need to be able to create a hard link analogue; I call them portals. Portals are not static entities like files or directories (even if synthesized at run-time, files are comparatively static entities) but rather nodes associated with an fid in a remote filesystem. If an fid walks through a portal then the fid associated with the other end of the portal is cloned and the #fid of the clone is associated with the fid stuck at the entrance of the portal. From then on, any message sent to the first fid is just bounced right back to the second fid. And portals, unlike mounts, can be made bidirectional quite trivially. No mount daemons! No added syntax! No disconnectedness! -- Another poll revealed that "faith in God is the most important part of Americans' lives." Forty percent "said they valued their relationship with God above all else"; 29% chose "good health" and 21% a "happy marriage." Satisfying work was chosen by 5%, respect of people in the community by 2%. That this world might offer basic features of a human existence is hardly to be contemplated. These are the kinds of results one might find in a shattered peasant society. -- Noam Chomsky in "The Third World at Home" From daemon Mon Nov 30 18:49:20 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA17081 for vsta-xplod; Mon, 30 Nov 1998 18:49:20 GMT Received: from tribble.eps.inso.com (mudd.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA17060 for ; Mon, 30 Nov 1998 18:49:15 GMT Received: from endymion (modem_g [199.93.212.249]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id BAA06104 for ; Tue, 1 Dec 1998 01:15:45 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: Distributed VSTa Date: Tue, 1 Dec 1998 01:18:55 -0500 Message-ID: <000501be1cf2$792e8db0$f8d45dc7@endymion.eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal > Perhaps it would be appropriate to break out another abstraction layer > and use something like: > > mount fs/root:tmp@//net/tcpip/205.187.71.66 /dist > > Then those of us without ethernet can still play with it by doing > > mount fs/root:tmp@//tty/rs232 /dist > Seems to me that something akin to a URL syntax might be better: mount tcpip:/205.187.71.66/fs/root /dist mount file://fs/root /dist The default would then be something like mount /205.187.71.66/fs/root /dist or perhaps like Windows et al: mount ///fs/root /dist where a leading double slash indicates TCPIP, a single slash a local file, and a name followed by a colon a named protocol. From daemon Mon Nov 30 22:09:41 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA17601 for vsta-xplod; Mon, 30 Nov 1998 22:09:41 GMT Received: from ariel.kotelna.sk (d97.turbo.paradise.net.nz [203.96.159.97]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA17579 for ; Mon, 30 Nov 1998 22:09:35 GMT Resent-From: mato@ariel.kotelna.sk Received: (from mato@localhost) by ariel.kotelna.sk (8.9.1a/8.9.1/PARANOID) id WAA00232 for vsta@zendo.com; Tue, 1 Dec 1998 22:01:29 +1300 Resent-Message-Id: <199812010901.WAA00232@ariel.kotelna.sk> Message-ID: <19981201215727.A173@ariel.kotelna.sk> Date: Tue, 1 Dec 1998 21:57:27 +1300 From: Martin Lucina To: David Jeske Subject: Re: Distributed VSTa References: <199811291904.TAA13697@bodhi.zendo.com> <19981130212233.A31372@kotelna.sk> <19981130135219.H5324@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <19981130135219.H5324@home.chat.net>; from David Jeske on Mon, Nov 30, 1998 at 01:52:19PM -0800 Resent-Date: Tue, 1 Dec 1998 22:01:29 +1300 Resent-To: vsta@zendo.com On Mon, Nov 30, 1998 at 01:52:19PM -0800, David Jeske wrote: > Curious, I really dislike that approach. When you allow the pathname > space to become an add-hoc repository for information, you increase > the potential for hard-coded dependencies to end up buried everwhere > in the system. I'd prefer to force the namespace to exist in it's > purely symbolic form in the namer and mount code, and any magic of > mounting proxied objects into the local namespace to happen outside of > the mount path syntax. Well I guess I should be more explicit. I was proposing backing off from the use of // to refer to namer space (which, as you say, invites hard-coded dependencies) and using /// to refer to a networked object on node . However as you said, this is not easily virtualisable, but on the other hand could be provided by a namer union mapped into /. My reasoning behind this syntax is from a "user" point of view. When working with DomainOS I found it just plain handy to be able to type cat //kate/etc/passwd and so on. I think that using the // syntax is a very straightforward way of accessing networked nodes. However it also imposes problems like how the existence of such nodes gets registered with your system and so on. (For DomainOS, you had to create an entry in '//' for every node you wanted to be accessible). One point I'm not sure I understand, just how the current pathname syntax works. If I wanted to access the subdirectory tmp of fs/root, can I do this now by opening //fs/root:tmp or must I explicity use mount? > I'd prefer it if there were a command to tell the proxy server to map > "//fs/root@204.96.5.14" to the local "//remote/fs/root" and then have > any use of the mount command refer to that proxied object by it's > local symbolic name "//remote/fs/root". This assures that if you want That's basically what we've got now, unless I'm confusing '//' to mean namer space vs. pathname space. I'm not sure I understand this distinction. > If there were to be a "//" syntax, I'd prefer to see it as a > product of a custom namer, so that was really just another > symbolic part of the namespace which this particular namer knew to map > to IP addresses, but which in another setup could be remapped to > something else. Yes. Maybe to avoid problems (I'd like to use // as well as //) you could establish a convention to map this namer to /n so we get /n/204.36.4.15/foo/bar /n/kate/foo/bar I'd like to see this consistent with the method to access namer space. > However, I don't think this increased focus on the namespace syntax is > a good direction. I assert that bindings between the system services > (in unix, files) and applications need to be (re)mappable. So you want a completely 'flat' namespace? In that case, do we want to keep //fs/root:tmp or just use //fs/root/tmp instead? In which case you could do 'neat' stuff like creating a "virtual" root and doing ln -s //fs/vfs/devel/vsta /vsta. Ideas? Comments? Martin From daemon Mon Nov 30 22:09:34 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA17578 for vsta-xplod; Mon, 30 Nov 1998 22:09:34 GMT Received: from ariel.kotelna.sk (d97.turbo.paradise.net.nz [203.96.159.97]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA17558 for ; Mon, 30 Nov 1998 22:09:28 GMT Resent-From: mato@ariel.kotelna.sk Received: (from mato@localhost) by ariel.kotelna.sk (8.9.1a/8.9.1/PARANOID) id WAA00234 for vsta@zendo.com; Tue, 1 Dec 1998 22:01:36 +1300 Resent-Message-Id: <199812010901.WAA00234@ariel.kotelna.sk> Message-ID: <19981201220006.B173@ariel.kotelna.sk> Date: Tue, 1 Dec 1998 22:00:06 +1300 From: Martin Lucina To: Andy Valencia Subject: Re: Distributed VSTa References: <19981130135219.H5324@home.chat.net> <199811302245.OAA23231@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199811302245.OAA23231@vandys-pc.cisco.com>; from Andy Valencia on Mon, Nov 30, 1998 at 02:45:42PM -0800 Resent-Date: Tue, 1 Dec 1998 22:01:35 +1300 Resent-To: vsta@zendo.com On Mon, Nov 30, 1998 at 02:45:42PM -0800, Andy Valencia wrote: > OTOH, per-user overrides for namer node values wouldn't be too terribly > difficult to implement. We could likely steal some tricks from /env, which > also implements a somewhat different nature of per-user data values. We > could agree to press forward, and implement such a beast when a fully > self-virtualizing windowing system, or a related need, finally became > pressing. On a similar note, I'd like to see a way to "globalise" a service. Ie the ability to get processes to rehash cached ports in case a part of the path space goes away (a server dies) and comes back (server is restarted). Martin From daemon Tue Dec 1 18:30:58 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA20174 for vsta-xplod; Tue, 1 Dec 1998 18:30:58 GMT Received: from bunny.gerf.org ([209.16.192.33]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA20154; Tue, 1 Dec 1998 18:30:54 GMT Received: (from docwhat@localhost) by bunny.gerf.org (8.8.7/8.8.7) id AAA22310; Wed, 2 Dec 1998 00:00:03 -0600 Message-ID: <19981202000003.A21860@gerf.org> Date: Wed, 2 Dec 1998 00:00:03 -0600 From: The Doctor What To: Andy Valencia , vsta@zendo.com Subject: Tandem Expand (Was: Re: Distributed VSTa) References: <199811291904.TAA13697@bodhi.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199811291904.TAA13697@bodhi.zendo.com>; from Andy Valencia on Sun, Nov 29, 1998 at 07:04:06PM +0000 I don't know how familiar you all are with Tandem Computers. They are interesting beasts. I work as a System Analyst actually at Tandem (now a division of Compaq, but that's another story). A couple of things of interest in the tandem environment: First, there the fact that disks are named processes. So are tapes and TCPIP stacks. (Note: Tandem has a structured files system of this form: \.$..). This has the interesting side effect that you could (in theory) write virtual disk processes. There is an example of a virtual tape process floating around. True, the system is monolithic in design, but little bits of modularity like this are really interesting. The second thing I wanted to mention (and this is the really interesting bit) is Tandem expand. Exampnd is **very** cool, IMO. Basically, you can "SYSTEM" (aka 'cd') over to another system. In fact you can access other node's files with normal commands! Example to copy a file: FUP DUP \PRUNE.$SYSTEM.SYS33.TACL, \TESS.$SYSTEM.TEMPOR.TACL (equivilent to 'cp \prune.$system.sys33.tacl \tess.$system.tempor.tacl', where TACL is the file name, sys33 and tempor are subvols, and $system is a volume (or disk). \prune and \tess are different nodes). Even better, I can "SYSTEM (aka 'cd') to another system and *run a command on that system*! This (for some reason) seems like a very VSTa like ability, don't you agree? I have a qustion. Should we have some sort of VSTa name service? I mean, a lot of the problems involved in using purely symbolic names for things is getting a consistant and expectable result every time. Oh well, this was just wierd thoughts..... Ciao! -- Death is a once in a lifetime experience. The Doctor What: Guru to the Gods http://www.gerf.org/~docwhat/ docwhat@gerf.org (finger docwhat@gerf.org for PGP key) From daemon Wed Dec 2 03:12:24 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id DAA21055 for vsta-xplod; Wed, 2 Dec 1998 03:12:24 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id DAA21035; Wed, 2 Dec 1998 03:12:20 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id JAA20500; Wed, 2 Dec 1998 09:38:11 -0500 (EST) From: "Gavin Thomas Nicol" To: "The Doctor What" , "Andy Valencia" , Subject: RE: Tandem Expand (Was: Re: Distributed VSTa) Date: Wed, 2 Dec 1998 09:41:29 -0500 Message-ID: <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <19981202000003.A21860@gerf.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 > I have a qustion. Should we have some sort of VSTa name service? I mean, > a lot of the problems involved in using purely symbolic names for things > is getting a consistant and expectable result every time. Well, I was just installing Office 2000 yesterday, and what David Jeske said hit me in spades as I watched the install process. We all know the problems caused by windows install programs that install things all over the system because they need to live in "special" places in order for things to work well (just try installing things in non-default places and watch what breaks). Worse, uninstall doesn't always clear everything that was installed off the machine, so you often get to a point where your disk is half full of crud that you don't need, but are not sure that you can delete. I think this is a clear example of why we need per-process maps and mount overlays... with these, the programs, at starup, would simply make the namespace looks like they need it to be, but have the actual *installation* of the program be purely local. Uninstall would be a snap. FWIW. I've started back working on MADO. Two of the neat things that Photon has that I'd like to get are the distribution and duplication capabilities. These could be handled using something like proxyd and teed (daemon equivalent of "tee" under unix), but I've not decidced that's the best way yet. From daemon Wed Dec 2 07:26:18 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA21592 for vsta-xplod; Wed, 2 Dec 1998 07:26:18 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id HAA21573 for ; Wed, 2 Dec 1998 07:26:14 GMT Received: (qmail 7993 invoked by uid 120); 2 Dec 1998 18:58:35 -0000 Date: Wed, 2 Dec 1998 10:58:34 -0800 From: David Jeske To: vsta@zendo.com Subject: App installation and encapsulation (Was: Tandem Expand) Message-ID: <19981202105834.N28651@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981202000003.A21860@gerf.org> <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com>; from Gavin Thomas Nicol on Wed, Dec 02, 1998 at 09:41:29AM -0500 This email has turned into yet another 'os philosophy' discussion, more than a discussion about VSTa specifics. However, so far it seems that people here are interested in this sort of thing. On Wed, Dec 02, 1998 at 09:41:29AM -0500, Gavin Thomas Nicol wrote: > > I have a qustion. Should we have some sort of VSTa name service? I mean, > > a lot of the problems involved in using purely symbolic names for things > > is getting a consistant and expectable result every time. > > Well, I was just installing Office 2000 yesterday, and what David > Jeske said hit me in spades as I watched the install process. I'm glad you agree. > We all know the problems caused by windows install programs that > install things all over the system because they need to live in > "special" places in order for things to work well (just try > installing things in non-default places and watch what > breaks). Worse, uninstall doesn't always clear everything that was > installed off the machine, so you often get to a point where your > disk is half full of crud that you don't need, but are not sure that > you can delete. Yes, but I think you should ask "why are their special places?". IMO, the problem is that current single heirarchy filesystems are a blank untyped slate within which applications create their own add-hoc storage conventions. > I think this is a clear example of why we need per-process maps and > mount overlays... with these, the programs, at starup, would simply > make the namespace looks like they need it to be, but have the > actual *installation* of the program be purely local. Uninstall > would be a snap. I believe we need to think long and hard about this. How is the application going to create the per-process maps? If the application is just accessing absolute names in the namer, and mounting them into it's pathspace, we have not improved anything. The idea of putting devices and files into a heirarchy is (IMO) mostly a convinence to human users. There are much more powerful storage mechanisms which applications could use just as easily to store data (i.e. databases, or even flat resource stores with unique names). However, these storage mechanisms don't translate as well into something a human user can 'browse'. A better solution (IMO) is to recognize that the heirarchy (and mount tables) need to exist for the human interactive mode, and perhaps for little scripts the operator writes, but that the resources themselves should exist in a different shape. For example, we might let an application get an opaque handle to the 'root' of it's files but not connect that to other files via some add-hoc heirarchy. If a human user wants to muck with the internal files of an application, let him mount it into his add-hoc pathname space to browse it. For example, I assert that it's a better solution for an app to do something like: int node_id = open_my_instance_resource(PRIMARY_DATA); int my_icon = open_resource(node_id,"myicon.tiff"); int my_data = open_resource(node_id,"somedata/my_data.dat"); Than to do something like: mount_my_instance(PRIMARY_DATA,"/appdata") int my_icon = open("/appdata/myicon.tiff"); int my_data = open("/appdata/somedata/my_data.dat"); However... either is a much better solution than 99% of operating systems are doing today, where app resources are installed into add-hoc locations at install time. ==== I'm going to go into more detail about the suggestion above that I don't like (i.e. mounting an apps primary data into some fixed location) both because it's the less radical one, and because it'll highlight some of the problems to be solved. We can improve app installation with this mode, but the single heirachy filesystem gets in the way. For example, we could make an add-hoc convention for use of the raw FS. This would have applications installed into instance IDs instead of some developer dictated install location: /@apps/0/app_export # a text file describing the app info, name, etc /myicon.tiff # app icon /somedata/my_data.dat # app data /my_app # app binary /@apps/1/app_export /bin-i386/netscape # i386 binary /classes.zip # default java classes file /icons/netscape.ico # netscape icon /icons/html.ico # html file icon /icons/tplain.ico # text/plain icon /icons/jpeg.ico # jpeg file icon /users/jeske/@apps/0/... # private app for user jeske The app_export would contain information like: # app_export for netscape APP_ICON = netscape.ico APP_BINARY{i386} = bin-i386/netscape APP_FILETYPES = { { type = "text/html", icon = "icons/html.ico", actions = { "open", "edit" } }, { type = "text/plain", icon = "icons/tplain.ico", actions = { "open" } }, { type = "img/jpeg", icon = "icons/jpeg.ico", actions = { "open" } } } Then when an app (or a command line tool) was launched, we would mount it's datafiles into a standard location (like /__appdata), and it could access them all from there. The problem here is that the "@apps" stuff is just add-hoc convention stuffed into an untyped heirarchy. (that is, if someone just created a directory called "@apps", it would be indistinguishable from our apps directory above) In addition, if we are storing data in the above manner into the raw-filesystem, then we have to write code to special case things like the private user app repository, or a group app-repository. Of course we can use something like union mounts to push this into a process local pathnamespace, but any decision about which mounts to make are again, just add-hoc. The world is a much nicer place if we have a multi-heirarchy, where we can express the physical storage location as one heirarchy, the ownership as another, and the identity information as another, and all of them can be rigidly typed items: physical location ownership identity class instance fs/root:home/jeske/my_app users.jeske app/my_app 00 fs/root:home/jeske/netscape users.jeske app/netscape4.05 01 fs/root:apps/gcc users app/gcc2.7.0 02 net/share:apps/gimp users app/gimp 03 That way, when we want to do something like "build the list of installed applications, we merely list the "identify class" = "app/*". I think I've gone on long enough about this, thoughts? -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Wed Dec 2 11:16:44 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA22078 for vsta-xplod; Wed, 2 Dec 1998 11:16:44 GMT Received: from bunny.gerf.org ([209.16.192.33]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA22058; Wed, 2 Dec 1998 11:16:36 GMT Received: (from docwhat@localhost) by bunny.gerf.org (8.8.7/8.8.7) id QAA00223; Wed, 2 Dec 1998 16:45:46 -0600 Message-ID: <19981202164546.B32647@gerf.org> Date: Wed, 2 Dec 1998 16:45:46 -0600 From: The Doctor What To: Gavin Thomas Nicol , Andy Valencia , vsta@zendo.com Subject: Self-Contained Installs ( Re: Tandem Expand ) References: <19981202000003.A21860@gerf.org> <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com>; from Gavin Thomas Nicol on Wed, Dec 02, 1998 at 09:41:29AM -0500 On Wed, Dec 02, 1998 at 09:41:29AM -0500, Gavin Thomas Nicol wrote: > > I have a qustion. Should we have some sort of VSTa name service? I mean, > > a lot of the problems involved in using purely symbolic names for things > > is getting a consistant and expectable result every time. > > Well, I was just installing Office 2000 yesterday, and what David Jeske said > hit me in spades as I watched the install process. > > We all know the problems caused by windows install programs that install > things all over the system because they need to live in "special" places > in order for things to work well (just try installing things in > non-default places and watch what breaks). Worse, uninstall doesn't > always clear everything that was installed off the machine, so you often > get to a point where your disk is half full of crud that you don't need, > but are not sure that you can delete. > I think this is a clear example of why we need per-process maps and > mount overlays... with these, the programs, at starup, would simply make > the namespace looks like they need it to be, but have the actual > *installation* of the program be purely local. Uninstall would be a > snap. It sounds like you want an installation of a pacakge to entirely self contained. Example: You install VSTaOffice2001 on Node FishStick. Then you move VO2001 from /usr/local/ to /usr (it still works). Then you move it Node CodFillette (it still works). I like the NeXTStep encapsulation of software, but I'm not sure it's perfect. It seems that managing quasi-system resources (like libraries) via this scheme is difficult, but I would *love* for it to work. Maybe something like: If a file is a "quasi-system" resource, it is either in a specific location (i.e. /usr/lib) or has a special attribute set, which would cause the VFS to follow and maintain a separate table of these resources. That way we wouldn't need something like ld.so to manage this junk. I'm not sure that I'd like something similar for programs tho. I mean, it might make for a messy system, where I would be able to run 16 different copies of netscape for example. If we could have a per user method to manage different versions.... (hint, hint, Jeske) Anyway, I love the idea of modular self-contained applications and resources. **If** we have tools and an easy scheme to manage them. Ciao! -- I'm not afraid of dying, I just don't want to be there when it happens. -- Woody Allen The Doctor What: http://www.gerf.org/~docwhat/ docwhat@gerf.org (finger docwhat@gerf.org for PGP key) From daemon Wed Dec 2 13:19:41 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA22341 for vsta-xplod; Wed, 2 Dec 1998 13:19:41 GMT Received: from bunny.gerf.org ([209.16.192.33]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA22322 for ; Wed, 2 Dec 1998 13:19:31 GMT Received: (from docwhat@localhost) by bunny.gerf.org (8.8.7/8.8.7) id SAA01413; Wed, 2 Dec 1998 18:48:42 -0600 Message-ID: <19981202184842.A565@gerf.org> Date: Wed, 2 Dec 1998 18:48:42 -0600 From: The Doctor What To: vsta@zendo.com Subject: Re: App installation and encapsulation (Was: Tandem Expand) References: <19981202000003.A21860@gerf.org> <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com> <19981202105834.N28651@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19981202105834.N28651@home.chat.net>; from David Jeske on Wed, Dec 02, 1998 at 10:58:34AM -0800 On Wed, Dec 02, 1998 at 10:58:34AM -0800, David Jeske wrote: > This email has turned into yet another 'os philosophy' discussion, > more than a discussion about VSTa specifics. However, so far it seems > that people here are interested in this sort of thing. Well...while it's true that the actual microkernel implimentation doesn't require (much) of this kind of discusion, implimenting the Operation System as a whole will benifit from a well thought out central concept. VSTa (for most of us, both theory and practical VSTa-subscribers) is a chance to do things better than UNIX. Andy's first working versions showed that VSTa could be *much* more than "Yet Another Unix". Why not take this concept and run with it? Anyway, on to the main show... > For example, I assert that it's a better solution for an app to do > something like: > > int node_id = open_my_instance_resource(PRIMARY_DATA); > int my_icon = open_resource(node_id,"myicon.tiff"); > int my_data = open_resource(node_id,"somedata/my_data.dat"); > > Than to do something like: > > mount_my_instance(PRIMARY_DATA,"/appdata") > int my_icon = open("/appdata/myicon.tiff"); > int my_data = open("/appdata/somedata/my_data.dat"); I have a question then, does the first example imply that "my_instance_resource" is some sort of registry? I'm not keen on that unless this registry is very dynamic, strongly typed, network transparent and has various data integrety verification methods. > However... either is a much better solution than 99% of operating > systems are doing today, where app resources are installed into add-hoc > locations at install time. So I have a question: To what level do we want a user to be able to browse all the structures? Should there be something like a mount point (aliased server, namer location, whatever) that can give you access to all the functions, from the shell (i.e. from the VFS)? VSTa$ /lib/printf ( "%s", "Narf?" ) > The problem here is that the "@apps" stuff is just add-hoc convention > stuffed into an untyped heirarchy. (that is, if someone just created a > directory called "@apps", it would be indistinguishable from our apps > directory above) In addition, if we are storing data in the above > manner into the raw-filesystem, then we have to write code to special > case things like the private user app repository, or a group > app-repository. Of course we can use something like union mounts to > push this into a process local pathnamespace, but any decision about > which mounts to make are again, just add-hoc. > > The world is a much nicer place if we have a multi-heirarchy, where we > can express the physical storage location as one heirarchy, the > ownership as another, and the identity information as another, and all > of them can be rigidly typed items: > > physical location ownership identity class instance > > fs/root:home/jeske/my_app users.jeske app/my_app 00 > fs/root:home/jeske/netscape users.jeske app/netscape4.05 01 > fs/root:apps/gcc users app/gcc2.7.0 02 > net/share:apps/gimp users app/gimp 03 > > That way, when we want to do something like "build the list of > installed applications, we merely list the "identify class" = "app/*". > > I think I've gone on long enough about this, thoughts? Frankly, I love it. Having a strongly typed FS/resources would be a beautiful thing (IMO). In addition, to owner, there should be an ACL too. This would make life really nice. Imagine taking a scsi disk from one scsi controller and putting on it another (i.e. change it's physical location) and have the whole thing just move cleanly (after all, its identity "storage/Chris' scsi root" would be unchange!). I think process space should be broken in this way too, after all, everything in a microkernel is a userspace process. That'd allow something like Tandem's Expand. Oooh.... I like. I must be my C++ programming roots saying "Whoohoo! Strong Typing!" Ciao! -- "Always do right. This will gratify some people and astonish the rest."" -- Mark Twain The Doctor What: http://www.gerf.org/~docwhat/ docwhat@gerf.org (finger docwhat@gerf.org for PGP key) From daemon Wed Dec 2 17:49:04 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA22975 for vsta-xplod; Wed, 2 Dec 1998 17:49:04 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA22956 for ; Wed, 2 Dec 1998 17:49:01 GMT Received: from endymion (modem_f [199.93.212.248]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id AAA15002 for ; Thu, 3 Dec 1998 00:15:35 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: App installation and encapsulation (Was: Tandem Expand) Date: Thu, 3 Dec 1998 00:18:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <19981202105834.N28651@home.chat.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 > The world is a much nicer place if we have a multi-heirarchy, where we > can express the physical storage location as one heirarchy, the > ownership as another, and the identity information as another, and all > of them can be rigidly typed items: > > physical location ownership identity class instance > > fs/root:home/jeske/my_app users.jeske app/my_app 00 > fs/root:home/jeske/netscape users.jeske app/netscape4.05 01 > fs/root:apps/gcc users app/gcc2.7.0 02 > net/share:apps/gimp users app/gimp 03 > > That way, when we want to do something like "build the list of > installed applications, we merely list the "identify class" = "app/*". > > I think I've gone on long enough about this, thoughts? I've cut out a lot of what you said, mostly because I agree with it. It's kind of interesting, because the company I work for is very Unix-like in it's resource management for applications. I've been trying for a few years now to encapsulate all resources into a single file... but this has been an uphill battle. That said, I think you have to divide the problem into parts: what the application sees, and what the user sees. I very much like the idea of packaging an application, and it's resources, into a single file. As such, a user should see nothing more than a single file in their view of the system. From an application perspective, it is often necessary to have some naming mechanism for handling resources. For example, in a Japanese locale, asking for gettext(FOO) (or somesuch call for a resource) has to be mapped to *some* way of differentiating Japanese resources from Germans ones from French ones. Ultimately, the system will have to map to some unique identifier, which is equivalent to a name. At that level having the application look for /app_resources/ja/ui/menu is as good as a GUID. I think the point that you were making is that *this* namespace, and that of the filesystem that the user sees, need to be independent of one another. With a model like this, how are things like system libraries handled though? From daemon Wed Dec 2 21:34:28 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA23210 for vsta-xplod; Wed, 2 Dec 1998 21:34:28 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id VAA23191 for ; Wed, 2 Dec 1998 21:34:24 GMT Received: (qmail 12302 invoked by uid 120); 3 Dec 1998 09:06:44 -0000 Date: Thu, 3 Dec 1998 01:06:44 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: App installation and encapsulation (Was: Tandem Expand) Message-ID: <19981203010644.O28651@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981202105834.N28651@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: ; from Gavin Thomas Nicol on Thu, Dec 03, 1998 at 12:18:52AM -0500 On Thu, Dec 03, 1998 at 12:18:52AM -0500, Gavin Thomas Nicol wrote: > I've cut out a lot of what you said, mostly because I agree with it. It's > kind of interesting, because the company I work for is very Unix-like > in it's resource management for applications. I've been trying for a few > years now to encapsulate all resources into a single file... but this has > been an uphill battle. I don't know how literal you are when you say "encapsulate all resources into a single file". I definetly agree that there needs to be some concept of atomicity for the resources for an entity. However, I think that it can be done just as easily with "more than one file" as it can be done with "just one file". The important part isn't necessarily the line we draw in the sand about which code manages the 'multiple resources', but instead the important part is that there is a way to have an atomic collection of resources. > That said, I think you have to divide the problem into parts: what the > application sees, and what the user sees. I very much like the idea > of packaging an application, and it's resources, into a single file. > As such, a user should see nothing more than a single file in their > view of the system. Agreed. Check out this description of NeXT's app wrapper system for an example of how this can be done relatively easily within the UNIX filesystem model. Of course you can make it more robust if you go further.. http://www.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html > From an application perspective, it is often necessary to have some > naming mechanism for handling resources. For example, in a Japanese > locale, asking for gettext(FOO) (or somesuch call for a resource) > has to be mapped to *some* way of differentiating Japanese resources > from Germans ones from French ones. Ultimately, the system will have > to map to some unique identifier, which is equivalent to a name. At > that level having the application look for > > /app_resources/ja/ui/menu > > is as good as a GUID. I don't think that I agree with you here. The nicest property of using a flat-namespace like GUIDs is that the GUID dosn't convey any information except identity. As a result, any orginization you want to lay on top has to be 'on top', and thus any number of orginizations can be layed on top without interfering with eachother. Wheras in your path example above, you've already preconcieved the importance of the different pieces of information construed in the heirarchy. Furthermore, because the pieces of information in the heirarchy are 'add-hoc', there is no way to correctly extend them for later use. What happens to the hard coded sprintf(path,"/app_resources/%s/ui/menu",my_language) when you decide you also want to have separate resources for different UI 'themes'? (i.e. win95 vs MacOS). First off, you have to go back and change all the path construction to have a new field. Secondly, you have to decide whether you want to do "/app_resources/ja/mac/ui/menu" or "/app_resources/mac/ja/ui/menu". I think these kinds of binding issues are better handled if the binding information is moved outside of the resource request itself. For example, if your app was merely asking for "ui/menu" or some GUID identifier, then an external 'binding' can occur to decide between whatever different supporting contexts there are. In my expanded example, we have 4: lang style japan - mac japan - windows us - mac us - windows but we might just as easily add other languages as we might add yet another dimension, for different "skill levels" of users: lang style skill japan - mac - expert japan - mac - novice By encoding this information as a flat set of typed properties which apply to their associated contexts, we can easily recognize what possible contexts can be bound and choose between them. If we encode some pre-ordained heirarchy, we would have instantly limited outselves from further expansion, and we would have buried information about the different dimensions in the 'convention' of the heirarchy building. (i.e. /app_resources/japan/mac/expert/ui/menu conveys no information about what "japan" means, nor does it allow for expansion) In the model I propose, there are three things which are combined to figure out how do bind a resource: 1) the identity of the requester 2) the identify of the requested resource 3) the 'binding paramaters' (i.e. in the above case, "lang=japan" and "skill=expert" would be binding paramaters) > I think the point that you were making is that *this* namespace, and that > of the filesystem that the user sees, need to be independent of one another. While it is certainly true that I think these two namespaces shoud be independent, I still want to move away from encoding useful and important information in non-typed spaces like a pathname space. > With a model like this, how are things like system libraries handled > though? System libraries are handled in the same spirit as application resources. That is, binding between an application and a particular shared lib should not be based on 'what's installed in lib', it should be based on the three criteria above. For example, if I'm "cp" (identity of requester) and I'm asking for "libc-4.0" (identify of requested resource) and there are no special binding paramaters, then the system will bound to the libc-4.0 compliant lib which is available. If I'm, "netscape" (identity of requester) and I'm asking for "libc-4.0" (identity of requested resource) and there is a binding paramater which says that we're not allowed to use "libc-4.1", then it won't be bound to libc-4.1, and instead it'll be bound to any other compliant libc-4.0 provider. I'm going to warn you now that if this discussion continues, you'll find that I prefer the 'default' binding behavior to be to only bind the exact instance of the resource requested (because it's the only one you _know_ works), and that binding to 'newer and allegedly compatible versions' would require additional binding information. However, I thought my example above would be simpler. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Wed Dec 2 21:51:30 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA23247 for vsta-xplod; Wed, 2 Dec 1998 21:51:30 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id VAA23228 for ; Wed, 2 Dec 1998 21:51:27 GMT Received: (qmail 12355 invoked by uid 120); 3 Dec 1998 09:23:50 -0000 Date: Thu, 3 Dec 1998 01:23:50 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: App installation and encapsulation (Was: Tandem Expand) Message-ID: <19981203012350.P28651@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981202000003.A21860@gerf.org> <000f01be1e01$d8d37590$577670c6@endymion.eps.inso.com> <19981202105834.N28651@home.chat.net> <19981202184842.A565@gerf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <19981202184842.A565@gerf.org>; from The Doctor What on Wed, Dec 02, 1998 at 06:48:42PM -0600 On Wed, Dec 02, 1998 at 06:48:42PM -0600, The Doctor What wrote: > > For example, I assert that it's a better solution for an app to do > > something like: > > > > int node_id = open_my_instance_resource(PRIMARY_DATA); > > int my_icon = open_resource(node_id,"myicon.tiff"); > > int my_data = open_resource(node_id,"somedata/my_data.dat"); > > > > Than to do something like: > > > > mount_my_instance(PRIMARY_DATA,"/appdata") > > int my_icon = open("/appdata/myicon.tiff"); > > int my_data = open("/appdata/somedata/my_data.dat"); > > I have a question then, does the first example imply that > "my_instance_resource" is some sort of registry? I'm not keen on that > unless this registry is very dynamic, strongly typed, network transparent > and has various data integrety verification methods. The implementation sitting on the other side of the API is irrelevant. The important part is that the application isn't responsible for composing the path, because if it is, then it just encodes more information which only has meaning by 'convention'. I assume by registry you are making reference to something similar to the windows registry. My biggest problem with the windows registry is that items in the registry have no connection with their 'owners' on disk. Such that you can lose registry information, or lose file information, and there is no way to know that you lost one and not the other. I think we are both thinking along the same lines about where this kind of information needs to be stored. > > However... either is a much better solution than 99% of operating > > systems are doing today, where app resources are installed into add-hoc > > locations at install time. > > So I have a question: To what level do we want a user to be able to > browse all the structures? Should there be something like a mount point > (aliased server, namer location, whatever) that can give you access to all > the functions, from the shell (i.e. from the VFS)? > VSTa$ /lib/printf ( "%s", "Narf?" ) It's interesting that you bring this up. Most of my thoughts have been to go away from the non-typed path space and instead rely on stronger typed structures. Picture this stark difference between binding done with shlibs, and binding done with file resources on UNIX. With an shlib call, the app explains which version of the shlib it expects the call to come from. Even if you don't have the exact instance he wanted, you know what he was expecting and can provide a work-alike. When a file resource (say /etc/fstab), you don't know which version of /etc/fstab the app was expecting to see. If somewhere in between when the app was compiled and now we changed the layout of /etc/fstab, one would think it wouldn't be too hard to just emulate the old layout for the old apps. Except that with open("/etc/fstab"), no information is conveyed about which "/etc/fstab" version the application expected to see. So to answer your question, binding libs (or anything) into the pathname space, is fine if you have some reason you want to do so, as long as when you write some perl script or something you have the system preserve information about exactly what instances/version you were expecting to be bound into the pathname space so that later it can be recreated without cracking open the head of the person who wrote the script. > Frankly, I love it. Having a strongly typed FS/resources would be a > beautiful thing (IMO). In addition, to owner, there should be an ACL too. > This would make life really nice. I prefer to just let you store arbitrary 'dimensions' of information on top of resources. I think it's important to establish a system of ownership, unique naming, and translation between these extended attributes, but to dictate them ahead of time just walls us into more static solutions. > Imagine taking a scsi disk from one scsi controller and putting on it > another (i.e. change it's physical location) and have the whole thing just > move cleanly (after all, its identity "storage/Chris' scsi root" would be > unchange!). Exactly.. or better yet... imagine installing a 1gb disk and having the system just say "you have 1gb more space" instead of requiring you to deal with manually installing items in different physical locations. Of course information about what physical location(s) something is stored in should be available, but it isn't necessarily what I want to center around all the time. > I think process space should be broken in this way too, after all, > everything in a microkernel is a userspace process. That'd allow > something like Tandem's Expand. I don't understand what you mean here... can you elaborate? > Oooh.... I like. I must be my C++ programming roots saying "Whoohoo! > Strong Typing!" I'm just as much a dynamic typer at heart. However, I recognize that some items inherently are static and some items are inherently dynamic, regardless of whether you treat them as such. Much of my desire to treat static requirements as static typed items is that I don't like the idea that every open("/etc/footab") function in a program is a point of failure. I'd prefer to be able to static check all the static requirements of a program beforehand to assure it can run. That way, the program only has to do complex error checking and handling for those things which it ADMITS are dynamic cases. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Thu Dec 3 00:01:26 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA23425 for vsta-xplod; Thu, 3 Dec 1998 00:01:26 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id AAA23406 for ; Thu, 3 Dec 1998 00:01:23 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id GAA19726 for ; Thu, 3 Dec 1998 06:27:59 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: App installation and encapsulation (Was: Tandem Expand) Date: Thu, 3 Dec 1998 06:31:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-Reply-To: <19981203010644.O28651@home.chat.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal > In the model I propose, there are three things which are combined to > figure out how do bind a resource: > > 1) the identity of the requester > 2) the identify of the requested resource > 3) the 'binding paramaters' (i.e. in the above case, > "lang=japan" and "skill=expert" > would be binding paramaters) Ok.This is a bit different to what I was talking about. What you are proposing here is more or less that resource resolution be a function, rather than being statically resolved. I agree. However, in the above function, you *still* have to bind to something, and have a way for naming that something, and again, I contend that /app_resources/ja/ui/menu is as good as a GUID. (I've got to run now, more later). From daemon Thu Dec 3 06:27:49 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA24103 for vsta-xplod; Thu, 3 Dec 1998 06:27:49 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id GAA24084 for ; Thu, 3 Dec 1998 06:27:27 GMT Received: (qmail 14381 invoked by uid 120); 3 Dec 1998 17:59:52 -0000 Date: Thu, 3 Dec 1998 09:59:52 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: App installation and encapsulation (Was: Tandem Expand) Message-ID: <19981203095951.S28651@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981203010644.O28651@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: ; from Gavin Thomas Nicol on Thu, Dec 03, 1998 at 06:31:07AM -0500 On Thu, Dec 03, 1998 at 06:31:07AM -0500, Gavin Thomas Nicol wrote: > Ok.This is a bit different to what I was talking about. What you are > proposing here is more or less that resource resolution be a function, > rather than being statically resolved. I agree. Correct. > However, in the above function, you *still* have to bind to something, > and have a way for naming that something, and again, I contend that > > /app_resources/ja/ui/menu > > is as good as a GUID. If you want a standard heirarchy to store your applications private information, that's fine. I don't think we should dictate this for all apps, because some apps will want RDBMS storage, or simple record storage, or BSP, or some other storage type. However, I still contend that we're better off naming the "app resource instance" by using a collection of fields in a flat table, and using something analagous to a GUID for uniqueness properties. For example, in this case we'd be storing a flat collection of heirarchial "mini-spaces", one per app. So instead of letting the app arbitrarily place itself inside the physical namespace: /usr/local/netscape/ja/ui/menu We place it's "mini-space" inside the flat logical namespace: Instance ID Category ID Name Ver Mini-Space Name/type I-1 C-1 Netscape 4.03 MS-1/HEIRARCHY I-2 C-1 Netscape 4.05 MS-2/HEIRARCHY I-3 C-2 Yellow Pages v1.0 MS-3/DB And it's local resources can be stored within the mini-space with a standard heirarchy if the author so choose like: Mini-space contents: MS-1/HEIRARCHY ja/ui/menu en/ui/menu Mini-space contents: MS-2/HEIRARCHY ja/ui/menu en/ui/menu Or if it suited the author's purpose better purpose better: Mini-space contents: MS-3/DB table "listing" columns = name, address, phone -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Fri Dec 4 12:39:51 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA28037 for vsta-xplod; Fri, 4 Dec 1998 12:39:51 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA28018 for ; Fri, 4 Dec 1998 12:39:43 GMT Received: from endymion (modem_d [199.93.212.246]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id TAA12987 for ; Fri, 4 Dec 1998 19:06:22 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: App installation and encapsulation (Was: Tandem Expand) Date: Fri, 4 Dec 1998 19:08:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <19981203095951.S28651@home.chat.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 > > However, in the above function, you *still* have to bind to something, > > and have a way for naming that something, and again, I contend that > > > > /app_resources/ja/ui/menu > > > > is as good as a GUID. > > If you want a standard heirarchy to store your applications private > information, that's fine. I don't think we should dictate this for all > apps, because some apps will want RDBMS storage, or simple record > storage, or BSP, or some other storage type. I was not arguing for a standard heirarchy, I was just saying that the namespace is entirely internal to the app. So /app_resources/ja/ui/menu could be just as useful as menu ja 0001 HAFFF556880-0000 for example. From a resource discovery and management perspective, I think most programmers will find heirarchies much more natural. Again, this is really local to the application *unless* you want some way of exposing this to the outside world. If you want to, in a common way, expose the inner structure to the outside world, you *must* have some convention, be it by naming, or by providing programmatic hooks. From daemon Fri Dec 4 15:07:12 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA28270 for vsta-xplod; Fri, 4 Dec 1998 15:07:12 GMT Received: from home.chat.net ([204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id PAA28251 for ; Fri, 4 Dec 1998 15:07:08 GMT Received: (qmail 23920 invoked by uid 120); 5 Dec 1998 02:39:36 -0000 Date: Fri, 4 Dec 1998 18:39:35 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: App installation and encapsulation (Was: Tandem Expand) Message-ID: <19981204183935.J28651@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <19981203095951.S28651@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: ; from Gavin Thomas Nicol on Fri, Dec 04, 1998 at 07:08:15PM -0500 On Fri, Dec 04, 1998 at 07:08:15PM -0500, Gavin Thomas Nicol wrote: > I was not arguing for a standard heirarchy, I was just saying that the > namespace is entirely internal to the app. So > > /app_resources/ja/ui/menu > > could be just as useful as > > menu ja 0001 HAFFF556880-0000 > > > for example. From a resource discovery and management perspective, I think > most programmers will find heirarchies much more natural. Again, this is > really local to the application *unless* you want some way of exposing this > to the outside world. > > If you want to, in a common way, expose the inner structure to the outside > world, you *must* have some convention, be it by naming, or by providing > programmatic hooks. I don't mean to sound like a broken record, but I think any time you expose information by 'convention' you are asking for trouble. I would prefer if _in all cases_ the way you export and import information was statically verifyable for static dependencies. This means that if your program requires a particular datafile, that this datafile dependence be published as an import and statically verifyable. If you encode the location of this datafile inside a convention within a string within the app, then there is no declaration to the outside world of this dependence. So, I'm not saying that using a heirarchy is necessarily a bad idea, what I'm saying is that burying the above heirarchy inside a string which is not declared as an important dependence is bad. Now, I also admit that we are not always going to be able to statically declare every dependence, So.... ======= I think that the above concept of using heirarchy by convention to have an app locate it's files would be fine as long as we could statically determine (i.e. by looking at the import table and NOT running the app) WHICH version of the 'heirarchy conventions' the app is using. For example, you're saying above that it's going to open "/app_resources/..." to get at it's files, presumably then it's going to open some other path to get at some other information, like perhaps system configuration data in "/etc" or something like that. I believe it's important to encode into the app information about which version of these conventions the app is expecting. The reason I think this is important can be demonstrated if you look at Plan9 and VSTa-ish mounting. If I write a program in Plan9 which uses "/dev/mouse" to talk to the mouse, it dosn't tell the world that it depends on /dev/mouse being mounted correctly, you just have to know that ahead of time. If we later come up with a cooler "/dev/moo" to replace /dev/mouse, and you run an app, you never know which one needs to be mounted, so you end up with both mounted for everything. If you need to change the protocol or format of /dev/mouse, there is no way for the system itself to determine which apps are expecting the old version of /dev/mouse or the new version. As an example, if a plan9 or VSTa program published (passively, in some form of import table) the following information, we could easily build the private pathname space for that app in a uniform way, so the developer could use the "heirarchy by convention" because we established the source version dependencies: HAFFF556880-0000 (my_app_data) -> /app_resources AB56AF7281A-BC31 (mouse v1.0) -> /dev/mouse 0110378AB01-C810 (fstan v1.2) -> /etc/fstab Now the app can use the heirarchial string paths if it wants, but the local path is built based on requirements that the app publishes. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Thu Dec 10 16:13:50 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA17036 for vsta-xplod; Thu, 10 Dec 1998 16:13:50 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA17030 for ; Thu, 10 Dec 1998 16:13:48 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA03332 for ; Thu, 10 Dec 1998 19:42:51 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id TAA20948 for ; Thu, 10 Dec 1998 19:42:50 -0800 (PST) Message-Id: <199812110342.TAA20948@vandys-pc.cisco.com> To: vsta@zendo.com Subject: vstafs bug Date: Thu, 10 Dec 1998 19:42:50 -0800 From: Andy Valencia Ok, I found several smaller bugs while hunting down the "corrupt asssembler" problem, but the real fix is to change the call in src/srv/vstafs/main.c: init_buf(__fd_port(blkdev), CORESEC); to init_buf(clone(__fd_port(blkdev)), CORESEC); The actual change in the next release has more error checking, but that's the basic fix, and should fix the basic problem. Ironically, DOS already did this technique. I can't even remember doing this, but it's certainly present! Now there's just SCSI CAM with > 16 meg configs to get running, then I can freeze for the next version. Andy From daemon Wed Dec 16 16:16:04 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA05424 for vsta-xplod; Wed, 16 Dec 1998 16:16:04 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA05418 for ; Wed, 16 Dec 1998 16:15:56 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA24596 for ; Wed, 16 Dec 1998 19:45:16 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id TAA11106 for ; Wed, 16 Dec 1998 19:45:16 -0800 (PST) Message-Id: <199812170345.TAA11106@vandys-pc.cisco.com> To: vsta@zendo.com Subject: 1.6.2 available for early testing Date: Wed, 16 Dec 1998 19:45:15 -0800 From: Andy Valencia Hello, I've placed v1.6.2 of VSTa into: ftp://ftp.zendo.com/vsta/vsta_162 for anyone who'd like to give it a trial spin. "current" will continue to point to 1.6.1 until I get some confirmations that 1.6.2 looks OK. Here's the 1.6.2 list from vsta/doc/features.txt: Add rcsdo/changed, my tools for working with RCS trees. Fix docs on rawrite'ing, also more spots missed in the great filesystem server command line change fiasco. Update sample boot/menu.lst to reflect file server command line syntax. On usage() errors, have DOS and vstafs put out a message to syslog as well as stderr (which, DOS being a boot server, isn't active). Fixed memory leak in ethernet driver Added memory leak instrumentation to libc malloc.c Added standard filesystem switch support to all filesystems KA9Q and proxyd now work for open/close/read/write/stat. So distributed kernel messaging is now working. Mount remote filesystems. Even /proc! Kill remote processes! Wheee! Implement support for ISA bus limitation "bounce buffers". Use bounce buffers in our two ISA DMA drivers--SCSI and floppy disk. Fix a nasty race condition in vstafs. There's also a new port of the Python programming language, version 1.5.1. It's a very nice little interpreted language, and I find it much easier to code in than raw shell with sed/awk/grep. Enjoy! Andy Valencia From daemon Thu Dec 17 05:38:03 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA06689 for vsta-xplod; Thu, 17 Dec 1998 05:38:03 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA06670 for ; Thu, 17 Dec 1998 05:37:55 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id MAA16199 for ; Thu, 17 Dec 1998 12:05:04 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: 1.6.2 available for early testing Date: Thu, 17 Dec 1998 12:02:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <199812170345.TAA11106@vandys-pc.cisco.com> Hmm. I still haven't got my grub woes solved. Is there another multiboot compatible boot loader out there? From daemon Thu Dec 17 06:58:52 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA06809 for vsta-xplod; Thu, 17 Dec 1998 06:58:52 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA06803 for ; Thu, 17 Dec 1998 06:58:50 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA19701; Thu, 17 Dec 1998 10:28:11 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id KAA14853; Thu, 17 Dec 1998 10:28:10 -0800 (PST) Message-Id: <199812171828.KAA14853@vandys-pc.cisco.com> To: "Gavin Thomas Nicol" cc: vsta@zendo.com Subject: Re: 1.6.2 available for early testing In-reply-to: Your message of "Thu, 17 Dec 1998 12:02:11 EST." Date: Thu, 17 Dec 1998 10:28:10 -0800 From: Andy Valencia ["Gavin Thomas Nicol" writes:] >Hmm. I still haven't got my grub woes solved. Is there another >multiboot compatible boot loader out there? Nope, I think HURD uses GRUB too. Did you ever find out what kind of values your BIOS was returning for the disk geometry? If you can recompile GRUB (which I think I remember that you could), perhaps you should just patch in the right values to see if GRUB can press on from there. Early on I had thought about adapting the old DOS-based VSTa boot loader to do multiboot loading. But GRUB worked too well, and at this point I'm not sure I could even dig up my Borland C disks and manuals. Andy From daemon Thu Dec 17 07:08:19 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA06893 for vsta-xplod; Thu, 17 Dec 1998 07:08:19 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA06874 for ; Thu, 17 Dec 1998 07:08:15 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id NAA19511; Thu, 17 Dec 1998 13:35:20 -0500 (EST) From: "Gavin Thomas Nicol" To: "Andy Valencia" Cc: Subject: RE: 1.6.2 available for early testing Date: Thu, 17 Dec 1998 13:32:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <199812171828.KAA14853@vandys-pc.cisco.com> > >Hmm. I still haven't got my grub woes solved. Is there another > >multiboot compatible boot loader out there? > > Nope, I think HURD uses GRUB too. Did you ever find out what > kind of values your BIOS was returning for the disk geometry? > If you can recompile GRUB(which I think I remember that you could), > perhaps you should just patch in > the right values to see if GRUB can press on from there. > > Early on I had thought about adapting the old DOS-based VSTa boot > loader to do multiboot loading. But GRUB worked too well, and at > this point I'm not sure I could even dig up my Borland C disks and > manuals. The main reason I've not heavily modified GRUB is that it uses gas. I was thinking of rewriting it in NASM or something like that. Beside that, I've been really busy. I might do something over the weekend. From daemon Wed Dec 23 05:06:00 1998 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA23277 for vsta-xplod; Wed, 23 Dec 1998 05:06:00 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA23258 for ; Wed, 23 Dec 1998 05:05:56 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA02818 for ; Wed, 23 Dec 1998 11:33:17 -0500 (EST) From: "Gavin Thomas Nicol" To: "Vsta@Zendo. Com" Subject: FW: The OSKit 0.96 is released Date: Wed, 23 Dec 1998 11:36:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal -----Original Message----- From: Jay Lepreau [mailto:lepreau@cs.utah.edu] Sent: Wednesday, December 23, 1998 9:02 AM To: oskit-notify@fast.cs.utah.edu Subject: The OSKit 0.96 is released Go to http://www.cs.utah.edu/projects/flux/oskit/ and follow your nose for all the goodies. Briefly: it's up to 30 component libraries now, comes with 45 example mini-kernels, a 500 page (help!) document with few blank pages anymore (although still lots of gaps in it), can be configured with full multithreading and Posix threads, has prototype CPU inheritance scheduling in it (5 policies including 2 real time), has a hierarchical network link-sharing component, has a "simple virtual memory" component including pageout. Has most Linux and BSD filesystems, several networking libs, the full FreeBSD C library (which means most of Posix), lots of device drivers (perhaps 60), profiling support, and some minimal video and window manager support. A currently inelegant but useful component lets you run many kernels on Unix in user-mode, which is great for debugging. Most components now use the COM object model, which is a first in internal OS design. Just about every component is optional, and unlike any other OS, is designed to fit into *other* operating systems and environments if desired. Of course the OSKit's got problems, too, don't we all. There are a ton of things that it needs. One nice thing in that regard is that it's easy to incrementally add to the OSKit. Let's do it! Re licensing, the OSKit comes with full source, and is GPL'ed; "open source" is now the "in" term apparently. If a business or someone has trouble with the GPL, the University is willing to talk about other options. As a special holiday bonus-- for such patience on your part-- this release supports a version, which we provide, of the Kaffe OpenVM (Java to you) from Transvirtual. Thus you can link them together and you've got Kaffe on the bare HW, or with a configuration change, you can run the same "Java OS" on top of Unix. Our Kaffe changes will go into the next beta release. Thanks to Tim Wilkinson and his company for giving Kaffe to the world. We are grateful to the long line of free software projects from whom we drew code, including Mach, Linux, FreeBSD, NetBSD, and XFree86. The GNU build tools were, as always, invaluable. DARPA's support has been great. Finally, I want to thank and acknowledge the fine team at Utah that has accomplished so much, and with whom I have the honor to work. Check out the CREDITS file for their names. ------ Notes: Surprising stuff: five hours after he pulled down the release, Matthew Flatt, a grad student at Rice who had never before seen the OSKit got a "Scheme computer" running. You can see his mail in the oskit-users mail archives off the Web address above. This message goes to all of you who sent mail to the oskit-notifyme address, asking to be notified when a release was made. Mailing lists: we have added all of you to the general list "oskit-users@cs.utah.edu". If you prefer only to be on the oskit-announce list (a superset of oskit-users for major announcements only), send mail to "oskit-users-request@cs.utah.edu" asking to be moved. Don't send to the oskit-notify address in the above mail header: it will disappear shortly. We and oskit-users would appreciate knowing of whatever use you make of the OSKit. Be sure to send feedback, especially improvements or suggestions for them, to the docs or code. Thanks... Jay Lepreau University of Utah lepreau@cs.utah.edu From daemon Tue Jan 5 05:51:35 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26677 for vsta-xplod; Tue, 5 Jan 1999 05:51:35 GMT Received: (from root@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26657; Tue, 5 Jan 1999 05:51:32 GMT Date: Mon, 4 Jan 1999 17:33:40 GMT From: Brian Witt Message-Id: <199901041733.RAA25874@phoenix.atticus.com> To: vsta@zendo.com Subject: Re: App installation and encapsulation In-Reply-To: <19981204183935.J28651@home.chat.net> .From: David Jeske > I think that the above concept of using heirarchy by convention to > have an app locate it's files would be fine as long as we could > statically determine (i.e. by looking at the import table and NOT > running the app) WHICH version of the 'heirarchy conventions' the app > is using. VAX/VMS uses version numbers..... COM uses unique IDs, the ID value changes when the interface changes. Anyone know of COM implementation in source code form out there? > As an example, if a plan9 or VSTa program published (passively, in > some form of import table) the following information, we could easily > build the private pathname space for that app in a uniform way, so the > developer could use the "heirarchy by convention" because we > established the source version dependencies: > > HAFFF556880-0000 (my_app_data) -> /app_resources > AB56AF7281A-BC31 (mouse v1.0) -> /dev/mouse > 0110378AB01-C810 (fstan v1.2) -> /etc/fstab > > Now the app can use the heirarchial string paths if it wants, but the > local path is built based on requirements that the app publishes. I really like this conversation. This topic reminds me of COBOL in college. Within the program, you gave symbolic names to your files. Basically globals which were opened for you by the OS (VM/CMS 360) _just_before_ your program ran. You could run the program in any directory, and data files could be located/named anything (at most 8 chars for VM/CMS). Thus the "printer" file was selected when your program ran. Kinda like I/O redirection at the descriptor level. --- "Laws seldom stop politicians." --- brian witt From daemon Tue Jan 5 06:58:27 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA26960 for vsta-xplod; Tue, 5 Jan 1999 06:58:27 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA26941 for ; Tue, 5 Jan 1999 06:58:24 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id NAA09747 for ; Tue, 5 Jan 1999 13:26:15 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: App installation and encapsulation Date: Tue, 5 Jan 1999 13:28:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: <199901041733.RAA25874@phoenix.atticus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 > VAX/VMS uses version numbers..... COM uses unique IDs, the ID value > changes when the interface changes. Anyone know of COM implementation > in source code form out there? OSKIT has some COM implementation in it. From daemon Wed Jan 27 09:37:27 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA00214 for vsta-xplod; Wed, 27 Jan 1999 09:37:27 GMT Received: from gong.uv.es (timbal.ci.uv.es [147.156.200.4]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA00194 for ; Wed, 27 Jan 1999 09:37:13 GMT Received: from magre (ayport27.ci.uv.es [147.156.142.156]) by gong.uv.es (8.9.0/8.9.0) with SMTP id WAA19915 for ; Wed, 27 Jan 1999 22:08:38 +0100 (MET) Message-ID: <005e01be4a39$a51bb3c0$9a8e9c93@magre> From: "Francisco Pastor Gomis" To: Subject: C++ compiler Date: Wed, 27 Jan 1999 22:07:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 I am interested in use the C++ compiler in VSTA, but it's seem that it is not in the distribution. Some body know if the GNU C++ compiler (or other) is ported to VSTA, or if is easy to build it compiling the source of the compiler and the library. Thanks Francisco Pastor Gomis. email: Francisco.Pastor@uv.es Dpto. de Informatica y Electronica. Universidad de Valencia C/ Dr. Moliner, 50. 46100-BURJASOT (Valencia). SPAIN Tlf(ph): +34-963.160.412. Fax: +34-963.160.418 From daemon Wed Jan 27 14:01:57 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA00997 for vsta-xplod; Wed, 27 Jan 1999 14:01:57 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA00991 for ; Wed, 27 Jan 1999 14:01:55 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA16615; Wed, 27 Jan 1999 17:33:14 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.9.1/8.9.1) with ESMTP id RAA03209; Wed, 27 Jan 1999 17:33:13 -0800 (PST) (envelope-from vandys@vandys-pc.cisco.com) Message-Id: <199901280133.RAA03209@vandys-pc.cisco.com> To: "Francisco Pastor Gomis" cc: vsta@zendo.com Subject: Re: C++ compiler In-reply-to: Your message of "Wed, 27 Jan 1999 22:07:11 +0100." <005e01be4a39$a51bb3c0$9a8e9c93@magre> Date: Wed, 27 Jan 1999 17:33:13 -0800 From: Andy Valencia ["Francisco Pastor Gomis" writes:] >I am interested in use the C++ compiler in VSTA, but it's seem that it is >not in the distribution. Right, I never worked on it, and I don't think anybody else has, either. >Some body know if the GNU C++ compiler (or other) is ported to VSTA, or if >is easy to build it compiling the source of the compiler and the library. Since I don't use the GNU or Cygnus C library, there might be some hassles marrying the C++ library routines. Note that I'm not planning on ever "C++-izing" the VSTa header files themselves. Regards, Andy From daemon Mon Feb 1 15:41:43 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA18824 for vsta-xplod; Mon, 1 Feb 1999 15:41:43 GMT Received: (from root@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA18799; Mon, 1 Feb 1999 15:41:31 GMT Message-ID: <19990131234453.40659@welcomehome.org> Date: Sun, 31 Jan 1999 23:44:53 -0700 From: Rob Savoye To: vsta@zendo.com Subject: Re: C++ compiler References: <005e01be4a39$a51bb3c0$9a8e9c93@magre> <199901280133.RAA03209@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199901280133.RAA03209@vandys-pc.cisco.com>; from Andy Valencia on Wed, Jan 27, 1999 at 05:33:13PM -0800 On Wed, Jan 27, 1999 at 05:33:13PM -0800, Andy Valencia wrote: > ["Francisco Pastor Gomis" writes:] > > >I am interested in use the C++ compiler in VSTA, but it's seem that it is > >not in the distribution. > > Right, I never worked on it, and I don't think anybody else has, either. Basically the main thing you need to add support to the linker script, which should be the default for the vsta configuration. (I'd have to check). But typically this requires adding the lines: __CTOR_LIST__ = .; LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) __CTOR_END__ = .; __DTOR_LIST__ = .; LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) __DTOR_END__ = .; to the .text section. > Since I don't use the GNU or Cygnus C library, there might be some hassles > marrying the C++ library routines. Note that I'm not planning on ever > "C++-izing" the VSTa header files themselves. Both libg++ and libstdc++ only require a standard C library, and the routines read(), write(), fstat(), getpid(), isatty(), lseek(), open(), kill(), stat(), and sbrk(). And most of these can be stubs. - rob - From daemon Thu Feb 4 12:05:22 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA25590 for vsta-xplod; Thu, 4 Feb 1999 12:05:22 GMT Received: from phoenix.atticus.com (bwitt@phoenix.atticus.com [140.174.126.10]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA25571 for ; Thu, 4 Feb 1999 12:05:13 GMT Received: (from bwitt@localhost) by phoenix.atticus.com (8.8.8/8.6.12) id PAA29819; Thu, 4 Feb 1999 15:36:11 GMT Date: Thu, 4 Feb 1999 15:36:11 GMT From: Brian Witt Message-Id: <199902041536.PAA29819@phoenix.atticus.com> To: gtn@eps.inso.com, vsta@zendo.com Subject: RE: App installation and encapsulation In-Reply-To: > OSKIT has some COM implementation in it. thanks... It have been a while since I was last checking email here. I have downlaoded and checked it out. I'm already on the OSkit mailing list, but there was no mention of it. thanks, brian From daemon Wed Mar 17 13:24:22 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA23008 for vsta-xplod; Wed, 17 Mar 1999 13:24:22 GMT Received: from workbench-01.ucsc.edu (rayr@workbench-01.UCSC.EDU [128.114.163.113]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA22989 for ; Wed, 17 Mar 1999 13:24:16 GMT Received: from localhost (rayr@localhost) by workbench-01.ucsc.edu (8.8.7/8.8.7) with ESMTP id RAA30155 for ; Wed, 17 Mar 1999 17:53:33 -0800 Date: Wed, 17 Mar 1999 17:53:32 -0800 (PST) From: Raymund Ramos Reply-To: rayr@cats.ucsc.edu To: vsta@zendo.com Subject: Python installation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to install python on a 486 but I get this: pwd is /vsta/src/bin/python vsta$ make install [regular make stuff, and python compiles fine but...] ./install-sh: exec fmt make: Error code 1 perm vsta$ also, when I run python from the same directory, I get a bunch of file not found errors and goes through looking for environment variables which it can't find also. Do I need bash or something? Help. From daemon Thu Mar 18 05:09:31 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA24175 for vsta-xplod; Thu, 18 Mar 1999 05:09:31 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA24169 for ; Thu, 18 Mar 1999 05:09:27 GMT Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.37.31]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA05055; Thu, 18 Mar 1999 09:01:02 -0800 (PST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.9.1/8.9.1) with ESMTP id JAA24124; Thu, 18 Mar 1999 09:01:02 -0800 (PST) (envelope-from vandys@vandys-pc.cisco.com) Message-Id: <199903181701.JAA24124@vandys-pc.cisco.com> To: rayr@cats.ucsc.edu cc: vsta@zendo.com Subject: Re: Python installation In-reply-to: Your message of "Wed, 17 Mar 1999 17:53:32 PST." Date: Thu, 18 Mar 1999 09:01:02 -0800 From: Andy Valencia [Raymund Ramos writes:] >vsta$ make install >[regular make stuff, and python compiles fine but...] >./install-sh: exec fmt >make: Error code 1 >perm >vsta$ Hmmm, all I recollect is the python library directory needs to be copied over to its canonical place. >also, when I run python from the same directory, >I get a bunch of file not found errors and >goes through looking for environment variables >which it can't find also. Yes, python whines a bit if it can't find its library directory. It comes up OK in the end, right? >Do I need bash or something? No, nothing like that. I think just "mkdir /vsta/lib/python15" and then "cp lib/*.py /vsta/lib/python15", executed from the python source dir, should do the trick. But I thought I stuffed the python libraries into the python distribution directly? If it isn't the library directory, then offhand I can't recall anything else special I did with the python port. Does the pre-built binary work correctly for you? That'll give a clue as to whether it's a compilation environment thing or a run-time one. Andy From daemon Wed Mar 24 19:26:36 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA06093 for vsta-xplod; Wed, 24 Mar 1999 19:26:36 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id TAA06074 for ; Wed, 24 Mar 1999 19:26:31 GMT Received: (qmail 17298 invoked by uid 120); 25 Mar 1999 03:29:35 -0000 Date: Wed, 24 Mar 1999 19:29:35 -0800 From: David Jeske To: vsta@zendo.com Subject: New Mailing list archive setup Message-ID: <19990324192935.J11177@home.chat.net> Mail-Followup-To: vsta@zendo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i Activity has been a very slow aroud here. Everyone must be busy. For those interseted in such things, Jonathan Shapiro's EROS was released a few months back.. http://www.cis.upenn.edu/~eros/ Quite a long time ago, our web mailing list archive disappeared. I've setup a new one at: http://www.egroups.com/list/vsta Andy, if you can put "listsaver-of-vsta@egroups.com" on the mailing list as a subscriber, it'll continue to archive new posts. I think right now it's setup to send subscription requests to "vsta-request@zendo.com".. if you happen to end up getting more subscriptions than you want from this, I'll see if I can turn it off. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Wed Mar 31 12:33:05 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA18046 for vsta-xplod; Wed, 31 Mar 1999 12:33:05 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id MAA18027 for ; Wed, 31 Mar 1999 12:32:56 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id PAA14283; Wed, 31 Mar 1999 15:32:13 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: jeske@chat.net Cc: vsta@zendo.com Date: Wed, 31 Mar 1999 14:29:03 -0500 Subject: Re: New Mailing list archive setup Message-ID: References: <19990324192935.J11177@home.chat.net> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) Reading that link about EROS brings up a good question. What is VSTa's security model? It seems to not be the usual ACL but does not offer pure capabilities, at least not in the KeyKOS sense. The kernel does provide a way to securely manage a set of access rights for each process, and processes can create new restricted ("forged") capabilities. But the system relies on a global user ID table (/vsta/etc/ids), which is interpretable by any process. In a pure capabilities system, the capability handle would be opaque. Also, access rights are stored in the directory entries just like POSIX. Because the capabilties represent user ID's and not actual objects, it seems like VSTA is more an ACL system. It's doubly confusing I think because there are really two "systems" involved here: One is the actual set of system calls: processes, threads, messages, etc. The other is the emulation of functions like open() and so on which would be system calls in other OS's, but are really library functions that run inside the process. A pure capability-based system wouldn't need to have an open() function because that operation doesn't exist: a process either already has a capability or it can't have it. So a capability is this sense corresponds more to a connection handle in VSTa. In fact, what VSTa servers do in processing a FS_OPEN message is simply giving the client a reference to something which they have rights to. What's acceptable in the following transaction is completely up to the client and server involved; the server only uses the VSTa capabilities mechanism to ensure that the client really should have that handle. So the VSTa security system doesn't actually attempt to secure data objects, as in traditional ACL, but instead connections between client and server, which is more like a capability system. Of course, as part of this system, many servers use access control lists. Consider what would happen if we never used the FS_OPEN message (and hence avoiding ACL), and instead had a way of passing the actual connection handles around. The only way a process could get an open connection handle would be from another process which had it (or a superset of it). We would never need to ensure that somebody has rightful access via access lists because there's no way they could pull a handle out of thin air. They must have gotten it from somebody who did have access. The trick would be having a way to store these handles persistently. Taken directly, that would mean that the run-time state of the all of the servers would have to be saved also, along with the connections, and that way all of the handles would be known to valid and secure. Now I think I see why capabilties and persistence go together in an OS. Also, the ability to embed a reference to a connection in a file (a "portal" as someone I think on this list called them) would be really nifty. That way we could avoid a lot of the nonsense regarding naming and placement of files (a lively discussion we had about that on this list, I remember.) From daemon Wed Mar 31 23:29:48 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id XAA18882 for vsta-xplod; Wed, 31 Mar 1999 23:29:48 GMT Received: from tartarus (root@[134.117.248.70]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id XAA18863 for ; Wed, 31 Mar 1999 23:29:41 GMT From: bv056@freenet.carleton.ca Received: by tartarus id m10Rvr7-000A5gC (Debian Smail-3.2 1996-Jul-4 #2); Tue, 30 Mar 1999 05:34:49 -0500 (EST) Message-Id: Subject: Re: New Mailing list archive setup In-Reply-To: from Eric Jacobs at "Mar 31, 99 02:29:03 pm" To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) Date: Tue, 30 Mar 1999 05:34:49 -0500 (EST) Cc: vsta@zendo.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Eric Jacobs > The trick would be having a way to store these handles persistently. > Taken directly, that would mean that the run-time state of the all of > the servers would have to be saved also, along with the connections, > and that way all of the handles would be known to valid and secure. Now > I think I see why capabilties and persistence go together in an OS. > > Also, the ability to embed a reference to a connection in a file (a > "portal" as someone I think on this list called them) would be really > nifty. That way we could avoid a lot of the nonsense regarding naming > and placement of files (a lively discussion we had about that on this > list, I remember.) Yup. Except that Prometheus is object-oriented so Portals are genuine classes (I'm even thinking of allowing new classes to be defined at /runtime/). Like all Links in Prometheus, Portals are bidirectional. Actually, portals are implemented as matched pairs of Links, one in each OS component, where the 'outer' link in each pair is class Portal and the 'inner' is class HardLink. Each Portal contains instructions to the HardLink in the other component; which it uses to redirect any message it receives. So in each component, you only have a single Portal and HardLink pair but users who send messages to a Portal see them emerge from the other Portal in the other OS component. It also means that each Component is responsible for implementing security (the Hard- Links keep track of permissions) on any message it receives even though the semantics dictates that the Portals themselves are supposed to implement security; to the user, it sure looks like that's going on! You know, until now I never quite understood what capabilities-based security was (except the rather dumb idea of passing encrypted tokens). Of course, I couldn't even imagine what an object-oriented OS was until I realized that's what I'd designed. :-) -- No individual gets up and says, I'm going to take this because I want it. He'd say, I'm going to take it because it really belongs to me and it would be better for everyone if I had it. It's true of children fighting over toys. And it's true of governments going to war. Nobody is ever involved in an aggressive war; it's always a defensive war--on both sides. -- Noam Chomsky, interview with Tor Wennerberg on morality From daemon Thu Apr 1 00:33:45 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA18990 for vsta-xplod; Thu, 1 Apr 1999 00:33:45 GMT Received: from tartarus (root@ppp70.annex9.carleton.ca [134.117.248.70]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id AAA18971 for ; Thu, 1 Apr 1999 00:33:40 GMT From: bv056@freenet.carleton.ca Received: by tartarus id m10Rwr6-000A5gC (Debian Smail-3.2 1996-Jul-4 #2); Tue, 30 Mar 1999 06:38:52 -0500 (EST) Message-Id: Subject: Re: New Mailing list archive setup In-Reply-To: from Eric Jacobs at "Mar 31, 99 02:29:03 pm" To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) Date: Tue, 30 Mar 1999 06:38:52 -0500 (EST) Cc: vsta@zendo.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Eric Jacobs > A pure capability-based system wouldn't need to have an open() function > because that operation doesn't exist: a process either already has a That's arguable. Prometheus doesn't have open() but I was quite surprised when I found that out. I started by extending the Plan 9 model and open() wasn't eliminated until I switched the foundation of my model from an imperative style to an object-oriented style. > connection handles around. The only way a process could get an open > connection handle would be from another process which had it (or a > superset of it). We would never need to ensure that somebody has > rightful access via access lists because there's no way they could pull > a handle out of thin air. They must have gotten it from somebody who > did have access. You can't have a pure capabilities-based system unless you have multiple- containment. And you can't have multiple-containment unless you have bidirectional links between data objects; if you try to do without it, Very Bad Things happen. -- "Clandestinism is not the usage of a handful of rogues, it is a formalized practice of an entire class in which a thousand hands spontaneously join. Conspiracy is the normal continuation of normal politics by normal means." -- Oglesby From daemon Mon Apr 19 11:52:46 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA18653 for vsta-xplod; Mon, 19 Apr 1999 11:52:46 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id LAA18640; Mon, 19 Apr 1999 11:52:35 GMT Message-Id: <199904191152.LAA18640@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: josh Cc: vsta@zendo.com Subject: Re: VSTa In-reply-to: Your message of "Tue, 06 Apr 1999 22:34:37 -0400." <99040622400700.10138@ph33r> Date: Mon, 19 Apr 1999 11:52:35 +0000 From: Andy Valencia [josh writes:] >Hello. I was looking through Altavista the other day for a Plan9 variant that >was free, and I stumbled across VSTa, but from the looks of your web page, it >looks rather dead. Is there any work going on still? If there is, I might be >willing to keep your web page up to date. It seems like a very worthy project, >mainly because I think Linux has grown too big and lost that sense of >community. I would also be interested in doing a Perl port if there is 3c509 >ethernet driver, as my only box left is a 386sx33 with such an adaptor. VSTa has pretty much coasted to a halt. In a couple of years I'll probably be able to retire (economy willing), and then I'll probably pick up VSTa and take it to the next level. Very likely this will de-emphasize the UNIX source port nature and emphasize more a next generation platform approach. For instance, www.squeak.org is a very powerful Smalltalk implementation which might make a nice starting point for all upper level functions. Imagine where the VSTa kernel runs the disks, ticks the clock, and so forth, and then Squeak powers all the upper level protocols--windowing, mail, UI, graphics, browser, web server, and so forth. Or perhaps there's a better approach. But in any case, I really doubt at this stage of the industry that there's much to be gained by trying to look enough like Linux that you can try and port Linux's applications onto Yet Another Free OS. Linux has that front covered, so my interest is in moving out into more speculative areas. For the time being I would welcome help in maintaining the web pages. One benefit of tending our little campfire is that there are a number of educational institutions which use VSTa in OS courses now and then. Regards, Andy Valencia From daemon Tue Apr 20 00:28:18 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA19459 for vsta-xplod; Tue, 20 Apr 1999 00:28:18 GMT Received: from vanessa.paradise.net.nz (vanessa.paradise.net.nz [203.96.152.15]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id AAA19440 for ; Tue, 20 Apr 1999 00:28:13 GMT Received: from ariel.paradise.net.nz (ariel.paradise.net.nz [203.96.155.69]) by vanessa.paradise.net.nz (8.9.3/8.9.3) with ESMTP id UAA23035 for ; Tue, 20 Apr 1999 20:32:23 +1200 Received: (qmail 6880 invoked by uid 1000); 20 Apr 1999 08:23:17 -0000 Date: Tue, 20 Apr 1999 20:23:17 +1200 From: Martin Lucina To: Andy Valencia Cc: josh , vsta@zendo.com Subject: Re: VSTa Message-ID: <19990420202317.K294@ariel.kotelna.sk> Mail-Followup-To: Andy Valencia , josh , vsta@zendo.com References: <99040622400700.10138@ph33r> <199904191152.LAA18640@bodhi.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199904191152.LAA18640@bodhi.zendo.com>; from Andy Valencia on Mon, Apr 19, 1999 at 11:52:35AM +0000 On Mon, Apr 19, 1999 at 11:52:35AM +0000, Andy Valencia wrote: > approach. For instance, www.squeak.org is a very powerful Smalltalk > implementation which might make a nice starting point for all upper level > functions. Imagine where the VSTa kernel runs the disks, ticks the clock, > and so forth, and then Squeak powers all the upper level > protocols--windowing, mail, UI, graphics, browser, web server, and so > forth. Sounds interesting. Maybe it's time I leart a new language. The only possible danger with the above approach I can see is too tight a binding on the implementation language (in this case Smalltalk) which would lead to a loss of flexibility? You want to be able to reasonably easily support mainstream languages like C/C++? > Or perhaps there's a better approach. But in any case, I really doubt at > this stage of the industry that there's much to be gained by trying to > look enough like Linux that you can try and port Linux's applications onto > Yet Another Free OS. Linux has that front covered, so my interest is in > moving out into more speculative areas. I never thought that VSTa should go in the direction of making it look like Linux. Granted, POSIX would be good but not essential. The goals I had in mind were to provide a light-weight OS that would scale down better than Linux. This has been achieved to a large degree (notably missing hardware drivers). I know I keep talking about doing some work on Linux driver support and then never get around to it, but I was discussing this with some friends last week and one suggestion made was that I could maybe wrangle a honors project out of it, something along the lines of "code reuse". So I'll see how that goes. I still have a year or so to go before I start thinking about that and things can change in a year. Andy, what do you think? > For the time being I would welcome help in maintaining the web pages. One > benefit of tending our little campfire is that there are a number of > educational institutions which use VSTa in OS courses now and then. That is certainly a worthwhile project, there has been a lot of great work done on VSTa and it would be nice to be able to point people to the web page and say "this is what's been done, it's all there". Just my 2c... mato -- Martin Lucina http://www.kotelna.sk/mato/ Wellington, New Zealand I've always been mad I know I've been mad like the most of us are Pretty hard to explain why you're a madman even if you're not mad From daemon Tue Apr 20 09:05:35 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA20001 for vsta-xplod; Tue, 20 Apr 1999 09:05:35 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA19995 for ; Tue, 20 Apr 1999 09:05:27 GMT Received: from vandys-pc.vandys.cisco.com ([171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA21709; Tue, 20 Apr 1999 10:09:07 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00439; Tue, 20 Apr 1999 09:21:58 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199904201621.JAA00439@vandys-pc.vandys.cisco.com> To: Martin Lucina cc: josh , vsta@zendo.com Subject: Re: VSTa In-reply-to: Your message of "Tue, 20 Apr 1999 20:23:17 +1200." <19990420202317.K294@ariel.kotelna.sk> Date: Tue, 20 Apr 1999 09:20:43 -0700 From: Andy Valencia [Martin Lucina writes:] >> For instance, www.squeak.org is a very powerful Smalltalk >> implementation which might make a nice starting point for all upper level >> functions. Imagine where the VSTa kernel runs the disks, ticks the clock, >> and so forth, and then Squeak powers all the upper level >> protocols--windowing, mail, UI, graphics, browser, web server, and so >> forth. >Sounds interesting. Maybe it's time I leart a new language. The only possible >danger with the above approach I can see is too tight a binding on the >implementation language (in this case Smalltalk) which would lead to a loss of >flexibility? You want to be able to reasonably easily support mainstream >languages like C/C++? I'd assume the underlying system would remain present. But that level would certainly be deemphasized. >I know I keep talking about doing some work on Linux driver support and then >never get around to it, but I was discussing this with some friends last week >and one suggestion made was that I could maybe wrangle a honors project out of >it, something along the lines of "code reuse". So I'll see how that goes. I >still have a year or so to go before I start thinking about that and things >can change in a year. Andy, what do you think? Updated drivers would be a Good Thing. ISA will be going away shortly, and VSTa's PCI story is just a hair short of non-existent. Andy From daemon Wed Apr 21 09:14:28 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA21815 for vsta-xplod; Wed, 21 Apr 1999 09:14:28 GMT Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA21796 for ; Wed, 21 Apr 1999 09:14:23 GMT Received: from endymion (modem_f [199.93.212.248]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id NAA25990; Wed, 21 Apr 1999 13:14:41 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'josh'" Cc: Subject: RE: VSTa Date: Tue, 20 Apr 1999 18:14:42 -0400 Message-ID: <000501be8c1a$78b886f0$f8d45dc7@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <199904191152.LAA18640@bodhi.zendo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 > VSTa has pretty much coasted to a halt. Sadly, this is true... but not from lack of interest I think. > approach. For instance, www.squeak.org is a very powerful Smalltalk > implementation which might make a nice starting point for all Well, as much as I like Smalltalk, it's still too far "out there". VSTa could get a lot of benefit from exploring some of the more interesting things in QNX et al. I think. From daemon Wed Apr 21 09:51:23 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA21871 for vsta-xplod; Wed, 21 Apr 1999 09:51:23 GMT Received: from home.chat.net (genesis.jeske.meer.net [204.94.139.85]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id JAA21852 for ; Wed, 21 Apr 1999 09:51:20 GMT Received: (qmail 13824 invoked by uid 120); 21 Apr 1999 17:58:28 -0000 Date: Wed, 21 Apr 1999 10:58:28 -0700 From: David Jeske To: vsta@zendo.com Subject: Re: VSTa Message-ID: <19990421105828.N439@home.chat.net> Mail-Followup-To: vsta@zendo.com References: <199904191152.LAA18640@bodhi.zendo.com> <000501be8c1a$78b886f0$f8d45dc7@eps.inso.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i In-Reply-To: <000501be8c1a$78b886f0$f8d45dc7@eps.inso.com>; from Gavin Thomas Nicol on Tue, Apr 20, 1999 at 06:14:42PM -0400 On Tue, Apr 20, 1999 at 06:14:42PM -0400, Gavin Thomas Nicol wrote: > > approach. For instance, www.squeak.org is a very powerful Smalltalk > > implementation which might make a nice starting point for all > > Well, as much as I like Smalltalk, it's still too far "out there". > VSTa could get a lot of benefit from exploring some of the more > interesting things in QNX et al. I think. Really? Hmm.. I think I much more agree with Andy. While I don't know if I would use smalltalk, I think today's expanding problems with software and operating systems do not rely around which kernel orginization can get 4k/s faster I/O. Increasingly, desktop and embedded applications are built with commodity software systems sitting on top of whatever kernel is convinent. What interesting things in QNX were you referring to? -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Wed Apr 21 11:41:46 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA21975 for vsta-xplod; Wed, 21 Apr 1999 11:41:46 GMT Received: from uruk.org ([209.180.166.90]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA21956 for ; Wed, 21 Apr 1999 11:41:34 GMT Received: from localhost ([127.0.0.1] helo=uruk.org) by uruk.org with esmtp (Exim 2.05 #1) id 10a2p4-0004zb-00; Wed, 21 Apr 1999 12:38:14 -0700 To: vsta@zendo.com cc: David Jeske Subject: Re: VSTa In-reply-to: Your message of "Wed, 21 Apr 1999 10:58:28 PDT." <19990421105828.N439@home.chat.net> Date: Wed, 21 Apr 1999 12:38:14 -0700 From: Erich Boleyn Message-Id: David Jeske wrote: > On Tue, Apr 20, 1999 at 06:14:42PM -0400, Gavin Thomas Nicol wrote: > > > approach. For instance, www.squeak.org is a very powerful Smalltalk > > > implementation which might make a nice starting point for all > > > > Well, as much as I like Smalltalk, it's still too far "out there". > > VSTa could get a lot of benefit from exploring some of the more > > interesting things in QNX et al. I think. > > Really? Hmm.. I think I much more agree with Andy. While I don't know > if I would use smalltalk, I think today's expanding problems with > software and operating systems do not rely around which kernel > orginization can get 4k/s faster I/O. Increasingly, desktop and > embedded applications are built with commodity software systems > sitting on top of whatever kernel is convinent. Agreed. OS kernels (or even user-level environments) are mostly considered interchangeable these days. Compatibility (i.e. does it work in the first place, can you maintain it, does it interoperate with what you have, etc.) is more important in most markets than even, say, a 2X performance difference. The only thing that will make a new kernel/user-level environment take off is new fundamental capabilities people want PLUS sufficient compatibility to what's already there to be useful in the non-critical areas. Even that may not be enough if sufficient time passes to entrench the expected approximate kernel interfaces. In that case all "standard" apps will be written to about the same API. BTW, I think Linux is taking off at least partly because it is so much like the UNIXen that many are already familiar with and has lots of software that people use (not desktop, but development/ engineering apps/code). If it was a truly new OS with what it offers, it wouldn't have a chance. > What interesting things in QNX were you referring to? As a pot-shot, I'd say QNX does offer some interesting things, but most of them that I know of (core is small & efficient, works on embeddable systems easily, and can support network proxy for some OS services) are insufficiently interesting given the lack of compatibility with other user frameworks. -- Erich Stefan Boleyn \_ Mad but Happy Scientist \__ http://www.uruk.org/ Motto: "I'll live forever or die trying" --------------------------- From daemon Wed Apr 21 18:42:58 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA22517 for vsta-xplod; Wed, 21 Apr 1999 18:42:58 GMT Received: from satan.jimco-fwt.com (orion.jimco-fwt.com [207.136.36.232]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA22498 for ; Wed, 21 Apr 1999 18:42:54 GMT Received: (from major@localhost) by satan.jimco-fwt.com (8.9.3/8.9.3) id VAA21515 for vsta@zendo.com; Wed, 21 Apr 1999 21:46:48 -0500 Date: Wed, 21 Apr 1999 21:46:47 -0500 From: "Major'Trips'" To: vsta@zendo.com Subject: Re: VSTa Message-ID: <19990421214647.A14102@jimco-fwt.com> References: <199904191152.LAA18640@bodhi.zendo.com> <000501be8c1a$78b886f0$f8d45dc7@eps.inso.com> <19990421105828.N439@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990421105828.N439@home.chat.net>; from David Jeske on Wed, Apr 21, 1999 at 10:58:28AM -0700 On Wed, Apr 21, 1999 at 10:58:28AM -0700, David Jeske wrote: > On Tue, Apr 20, 1999 at 06:14:42PM -0400, Gavin Thomas Nicol wrote: > > > approach. For instance, www.squeak.org is a very powerful Smalltalk > > > implementation which might make a nice starting point for all > > > > Well, as much as I like Smalltalk, it's still too far "out there". > > VSTa could get a lot of benefit from exploring some of the more > > interesting things in QNX et al. I think. > > Really? Hmm.. I think I much more agree with Andy. While I don't know > if I would use smalltalk, I think today's expanding problems with > software and operating systems do not rely around which kernel > orginization can get 4k/s faster I/O. Increasingly, desktop and > embedded applications are built with commodity software systems > sitting on top of whatever kernel is convinent. > > What interesting things in QNX were you referring to? > > -- > David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net I believe that trying to redirect towards an embeded only enviroment would be fairly .. well .. suicide. The embeded market is beeing pushed towards more and more open standards, TCP, SNMP, POSIX, ect..ect by the end customer who wishes to intigrate systems that needed embded RTOS enviroments w/ their current interanet. As well, the other huge winner is the number of platforms you can run on and the hardware you can support. The end customer, even in the embeded market, prefers vast amounts of flexability. That's likley why Linux has worked it's way into the embeded market as well. -- "Reality is what you can get away with!" ++Robert Anton Wilson Major'Trips' E-Mail : shadow@cyberwizards.com || major@jimco-fwt.com From daemon Thu Apr 22 07:26:12 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA23279 for vsta-xplod; Thu, 22 Apr 1999 07:26:12 GMT Received: from satan.jimco-fwt.com (orion.jimco-fwt.com [207.136.36.232]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA23260 for ; Thu, 22 Apr 1999 07:26:07 GMT Received: (from major@localhost) by satan.jimco-fwt.com (8.9.3/8.9.3) id IAA23837 for vsta@zendo.com; Thu, 22 Apr 1999 08:00:33 -0500 Date: Thu, 22 Apr 1999 08:00:32 -0500 From: "Major'Trips'" To: vsta@zendo.com Subject: Re: VSTa Message-ID: <19990422080032.B14102@jimco-fwt.com> References: <19990421105828.N439@home.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Erich Boleyn on Wed, Apr 21, 1999 at 12:38:14PM -0700 Well, one of the important things I would keep in mind is that a) unix started off as an enviroment for Ken Thompson and crew to continue their development on the "Space Travel" game. A good deal of the ideas and concepts behind Unix where adopted to give the Unix developers an enviroment that did not force them to do things any certain way. Be it a specific language, a specific set of API's they must use, none of that. C was developed parrallel with Unix and it to went under the same considerations. That and the fact that the entire development team where ex-Multics developers made for an enviroment where the developer could choose from nearly any language they wanted to, and any library routines. And if they didn't have something they wanted or didn't like an already existing version they where allowed write it for themselves. Constraining a developer enviroment to any one language sounds to me like certain suicide. Don't forget .. "unix" is nothing more then a license any more. The original "unix" wasn't allow to be "sold" due to a decree AT&T had signed with the goverment "restricting" them from selling any product not directly related to carrier wave or telegraph communication. They where also not allowed to do business that was not directly related to telephone or telegraph communication. So Unix was originally distributed at no cost, with only a small fee apon distribution itself. Before 1978 Unix became so dominant because it was in all essence "free". Though AT&T still controled source rights to the entire OS. Later AT&T went on to get that decree thrown out and suddenly allowed to charge insane license rights for unix. It was thanx to items such as Minix and BSD that the universities still used a unix enviroment at all. Soo .. while I would say "yes" it was thanx to the fact that Linux is a POSIX compliant OS that "assisted" with an easy transition to using it from higher priced OS's that contain strict restrictions for ussage. I would also note that Linux and Unix share a common method for market entry. Free Source. The only significant differances between them at the time was that AT&T's Unix was not copyleft. On Wed, Apr 21, 1999 at 12:38:14PM -0700, Erich Boleyn wrote: > > David Jeske wrote: > > > On Tue, Apr 20, 1999 at 06:14:42PM -0400, Gavin Thomas Nicol wrote: > > > > approach. For instance, www.squeak.org is a very powerful Smalltalk > > > > implementation which might make a nice starting point for all > > > > > > Well, as much as I like Smalltalk, it's still too far "out there". > > > VSTa could get a lot of benefit from exploring some of the more > > > interesting things in QNX et al. I think. > > > > Really? Hmm.. I think I much more agree with Andy. While I don't know > > if I would use smalltalk, I think today's expanding problems with > > software and operating systems do not rely around which kernel > > orginization can get 4k/s faster I/O. Increasingly, desktop and > > embedded applications are built with commodity software systems > > sitting on top of whatever kernel is convinent. > > Agreed. OS kernels (or even user-level environments) are mostly > considered interchangeable these days. Compatibility (i.e. does > it work in the first place, can you maintain it, does it interoperate > with what you have, etc.) is more important in most markets than even, > say, a 2X performance difference. > > The only thing that will make a new kernel/user-level environment > take off is new fundamental capabilities people want PLUS sufficient > compatibility to what's already there to be useful in the non-critical > areas. Even that may not be enough if sufficient time passes to > entrench the expected approximate kernel interfaces. In that case > all "standard" apps will be written to about the same API. > > BTW, I think Linux is taking off at least partly because it is so > much like the UNIXen that many are already familiar with and has > lots of software that people use (not desktop, but development/ > engineering apps/code). If it was a truly new OS with what it > offers, it wouldn't have a chance. > > > What interesting things in QNX were you referring to? > > As a pot-shot, I'd say QNX does offer some interesting things, > but most of them that I know of (core is small & efficient, works > on embeddable systems easily, and can support network proxy for > some OS services) are insufficiently interesting given the lack > of compatibility with other user frameworks. > > -- > Erich Stefan Boleyn \_ > Mad but Happy Scientist \__ http://www.uruk.org/ > Motto: "I'll live forever or die trying" --------------------------- -- "Reality is what you can get away with!" ++Robert Anton Wilson Major'Trips' E-Mail : shadow@cyberwizards.com || major@jimco-fwt.com From daemon Mon Apr 26 09:49:43 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA01318 for vsta-xplod; Mon, 26 Apr 1999 09:49:43 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA01312 for ; Mon, 26 Apr 1999 09:49:40 GMT Received: from vandys-pc.vandys.cisco.com ([171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA16677; Mon, 26 Apr 1999 10:53:41 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00955; Mon, 26 Apr 1999 10:53:38 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199904261753.KAA00955@vandys-pc.vandys.cisco.com> To: Jeremy Fitzhardinge cc: vsta@zendo.com Subject: Re: VSTa under VMware? In-reply-to: Your message of "Sat, 24 Apr 1999 14:45:29 PDT." Date: Mon, 26 Apr 1999 10:53:38 -0700 From: Andy Valencia [Jeremy Fitzhardinge writes:] >One of the reasons I haven't done anything with VSTa is the lack of a >sacrifical machine to play with it on. With the appearance of VMware, it look >s like this problem can be solved rather more easily than I'd thought. >Has anyone tried VSTa under VMware? I looked into doing it the other day, but >haven't actually tried it yet. I've been watching Bochs for a while. Either it or VMware (which I've just taken a peek at) would be quite nice for hosting an experimental OS on a host machine. VSTa doesn't use anything fancy in x86 support, so I'd be surprised if there was much hassle in running it. Andy From daemon Wed Apr 28 08:27:35 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA04133 for vsta-xplod; Wed, 28 Apr 1999 08:27:35 GMT Received: from shelbyville.oai.com (mirian@qa3.oai.com [204.57.59.144]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA04114 for ; Wed, 28 Apr 1999 08:27:29 GMT Received: (from mirian@localhost) by shelbyville.oai.com (8.8.7/8.8.4) id MAA17979; Wed, 28 Apr 1999 12:31:18 -0400 From: Mirian Crzig Lennox To: vsta@zendo.com Subject: interesting discovery Original-Sender: lennox@alcita.com Organization: Alcita Technologies, Inc. Date: 28 Apr 1999 12:31:17 -0400 In-Reply-To: Martin Lucina's message of "Tue, 20 Apr 1999 20:23:17 +1200" Message-ID: Lines: 16 I made an interesting discovery today... I happened to be reading through the Lions book on 6th edition UNIX (which is happily now available for purchase at fine computer bookstores everywhere), and came across the assertion, in the introduction, that 10,000 lines represents the upper bound for a body of to be understood and maintained by one person. If you do a wc -l on /vsta/src/os/kern/* you'll see that VSTa is just about that much (10590 to be exact, on my system). The entire /vsta/src/os/ tree tops out at just over 20,000. I think that's pretty cool. -- Mirian Crzig Lennox Systems Anarchist "Don't follow leaders... watch the parking meters." --Bob Dylan From daemon Wed Apr 28 08:40:02 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA04154 for vsta-xplod; Wed, 28 Apr 1999 08:40:02 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA04148 for ; Wed, 28 Apr 1999 08:40:00 GMT Received: from vandys-pc.vandys.cisco.com ([171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA20303; Wed, 28 Apr 1999 09:44:08 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00408; Wed, 28 Apr 1999 09:44:05 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199904281644.JAA00408@vandys-pc.vandys.cisco.com> To: Mirian Crzig Lennox cc: vsta@zendo.com Subject: Re: interesting discovery In-reply-to: Your message of "28 Apr 1999 12:31:17 EDT." Date: Wed, 28 Apr 1999 09:43:10 -0700 From: Andy Valencia [Mirian Crzig Lennox writes:] >I made an interesting discovery today... I happened to be reading >through the Lions book on 6th edition UNIX (which is happily now >available for purchase at fine computer bookstores everywhere), and >came across the assertion, in the introduction, that 10,000 lines >represents the upper bound for a body of to be understood and >maintained by one person. > >If you do a wc -l on /vsta/src/os/kern/* you'll see that VSTa is just >about that much (10590 to be exact, on my system). The entire >/vsta/src/os/ tree tops out at just over 20,000. Of course, you have to contrast what v6 got in 10,000 lines (scheduler, memory management, processes, pipes, filesystem, drivers) versus VSTa (scheduler, memory management, processes). But VSTa permits preemption of the kernel, threads, inter-process IPC (rather than pipes), and also supports true VM (rather than swapping). So I guess I did OK! Andy From daemon Fri Apr 30 20:48:22 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id UAA07830 for vsta-xplod; Fri, 30 Apr 1999 20:48:22 GMT Received: from mail2.fw-sj.sony.com (mail2.fw-sj.sony.com [198.93.2.18]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id UAA07811 for ; Fri, 30 Apr 1999 20:48:18 GMT Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail2.fw-sj.sony.com (8.8.8/8.8.8) with ESMTP id VAA20004 for ; Fri, 30 Apr 1999 21:52:33 -0700 (PDT) Received: by mail2.sjc.in.sel.sony.com id VAA14299; Fri, 30 Apr 1999 21:52:33 -0700 (PDT) Received: from tannoudji.arch.sel.sony.com by erty.arch.sel.sony.com (SMI-8.6/SMI-SVR4) id VAA21365; Fri, 30 Apr 1999 21:52:01 -0700 Received: by tannoudji.arch.sel.sony.com (SMI-8.6/SMI-SVR4) id VAA05554; Fri, 30 Apr 1999 21:51:12 -0700 Date: Fri, 30 Apr 1999 21:51:12 -0700 From: bwitt@arch.sel.sony.com (Brian Witt) Message-Id: <199905010451.VAA05554@tannoudji.arch.sel.sony.com> To: vsta@bodhi.zendo.com Subject: booting up (simple) ((Sorry this isn't VSTa specific, but I want to use VSTa code as a reference.)) I've been studying your 386 VSTa boot code, both 1.5.1 and 1.6.2 source. I'm building a toy operating system to be used as the loader for an undergrad OS course. (They currently use M68010 machines, the AT&T 3B1. But they've broken down so many times, the techs refused to fix them.) I want to develop completely under UNIX (HP-UX 10 and Solaris). For the students I was thinking of writing a loader that would run from MS-DOS. It would also provide ring 0 nano-kernel functions to manage the descriptor tables. It would load the student's program into memory starting at 1M (plus COFF header). Loader/nano-kernel uses MS-DOS to read the OS file, and ROM BIOS to copy it into >= 1Meg RAM (doesn't need to be fast). Later use FTP. The main OS would run ring 1 with full I/O access. Requests for CR3 is nano-kernel territory. The nano-kernel and page tables stay below 640K. Create a special segment just for video RAM. Couple of questions.... (1) Do you really have to copy things down to location 0? For students using 16M RAM machines, they won't miss the lower 1M. (2) Are there conventions for kernel segments. Otherwise I'll follow the FreeBSD processor-depend stuff. (3) Next week I build my target '486 machine. I believe boot loaders and LILO are much work to interface with. Is this justified? thanks for your time. ============ brian witt (SJ2C6) bwitt@arch.sel.sony.com Sony US Research, Distributed Systems Lab, USA 408-955-3021 "Capitalism has taken over at the expense of democracy." From daemon Mon May 3 09:07:00 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA13693 for vsta-xplod; Mon, 3 May 1999 09:07:00 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA13687 for ; Mon, 3 May 1999 09:06:56 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA03690; Mon, 3 May 1999 10:11:18 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00547; Mon, 3 May 1999 10:09:33 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905031709.KAA00547@vandys-pc.vandys.cisco.com> To: bwitt@arch.sel.sony.com (Brian Witt) cc: vsta@zendo.com Subject: Re: booting up (simple) In-reply-to: Your message of "Fri, 30 Apr 1999 21:51:12 PDT." <199905010451.VAA05554@tannoudji.arch.sel.sony.com> Date: Mon, 03 May 1999 10:09:32 -0700 From: Andy Valencia [bwitt@arch.sel.sony.com (Brian Witt) writes:] >(1) Do you really have to copy things down to location 0? For > students using 16M RAM machines, they won't miss the lower 1M. If you don't, it's harder to code in DOS. Remember that only the bottom meg is directly accessible in real mode. >(2) Are there conventions for kernel segments. Otherwise I'll follow > the FreeBSD processor-depend stuff. Not that I know of. >(3) Next week I build my target '486 machine. I believe boot loaders > and LILO are much work to interface with. Is this justified? You should look at GRUB (GRand Unified Bootloader). It's the reason I stopped using my own boot loader. See: http://www.uruk.org/~erich/grub/ It knows how to load in highmem (VSTa, in fact, now loads at 1M), and handles machines with more memory than can be described by the old config mem technique. It also knows how to load multiple programs, which is how VSTa boots with all of its servers. Quite a nice little program, and no, not very hard at all to interface into. Coding up my own boot loader was MUCH more work than adapting VSTa to GRUB. I would've used it to begin with, but it didn't exist when VSTa was first coded. Regards, Andy Valencia From daemon Mon May 3 15:22:34 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA14115 for vsta-xplod; Mon, 3 May 1999 15:22:34 GMT Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id PAA14096 for ; Mon, 3 May 1999 15:22:26 GMT Received: from system (dc2-modem554.dial.xs4all.nl [194.109.130.42]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id BAA20282 for ; Tue, 4 May 1999 01:27:18 +0200 (CEST) Message-Id: <199905032327.BAA20282@smtp1.xs4all.nl> From: "chefren" To: vsta@zendo.com Date: Tue, 4 May 1999 01:27:17 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: interesting discovery Priority: normal In-reply-to: <199904281644.JAA00408@vandys-pc.vandys.cisco.com> References: Your message of "28 Apr 1999 12:31:17 EDT." X-mailer: Pegasus Mail for Win32 (v3.01d) On 28 Apr 99, at 9:43, Andy Valencia wrote: > [Mirian Crzig Lennox writes:] > > >I made an interesting discovery today... I happened to be reading > >through the Lions book on 6th edition UNIX (which is happily now > >available for purchase at fine computer bookstores everywhere), and > >came across the assertion, in the introduction, that 10,000 lines > >represents the upper bound for a body of to be understood and > >maintained by one person. > > > >If you do a wc -l on /vsta/src/os/kern/* you'll see that VSTa is just > >about that much (10590 to be exact, on my system). The entire > >/vsta/src/os/ tree tops out at just over 20,000. > > Of course, you have to contrast what v6 got in 10,000 lines (scheduler, > memory management, processes, pipes, filesystem, drivers) versus VSTa > (scheduler, memory management, processes). But VSTa permits preemption of > the kernel, threads, inter-process IPC (rather than pipes), and also > supports true VM (rather than swapping). So I guess I did OK! I'm not a programmer but I have directed good ones of them for years, here is a description of my real life experiences with this: As far as I know really good programmers up to 28 years old oversee software totally until about 10.000 lines. After about that limit both amount and time due have risen above a "certain" level and they only really know the big picture. They do start writing simple routines twice. Until about 30.000 lines or 2-3 years they can find out details pretty fast because they have an accurate "big picture" in their heads. After a longer time big changes are really difficult and even simple repairs take a lot of time. If complexity has risen above a certain level in combination with enough time that has exceeded the overview needed for a good product is lost. If a project started with a good programmer it's almost impossible to bring in a new guy who can continue development since the new one has to be so much better that you just cannot find them at that level. It's better to start again with the new guy and use more external technology that didn't exist when the first programmer started. (Instead of assembly use C, instead of writing own databases use external ones, instead of own communication use the Internet et cetera.) +++chefren From daemon Tue May 4 05:41:29 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA15163 for vsta-xplod; Tue, 4 May 1999 05:41:29 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA15156 for ; Tue, 4 May 1999 05:41:26 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA15201; Tue, 4 May 1999 06:45:51 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id GAA00361; Tue, 4 May 1999 06:45:49 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905041345.GAA00361@vandys-pc.vandys.cisco.com> To: Rob Savoye Cc: vsta@zendo.com Subject: Re: booting up (simple) In-reply-to: Your message of "Mon, 03 May 1999 19:55:05 MDT." <19990503195505.57478@welcomehome.org> Date: Tue, 04 May 1999 06:45:49 -0700 From: Andy Valencia [Rob Savoye writes:] >> You should look at GRUB (GRand Unified Bootloader). It's the reason I >> stopped using my own boot loader. See: > You might also want to check out my current post-Cygnus project Nilo. >It's a networked boot loader. It basically does a DHCP/ARP session to get >it's network config info, then it TFTPs the file and loads it. The web page >is at www.nilo.org, and it'll load GRUB format boot images, as well as Nilo's >own Tagged Image format. Initially it'll load Linux & FreeBSD, then NT & win9x >, but maybe I should make it load VSTa as well. (Whiny voice ON...) Please? Pretty please...? :-> Andy From daemon Mon May 10 05:53:48 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26528 for vsta-xplod; Mon, 10 May 1999 05:53:48 GMT Received: from dirc.bris.ac.uk ([137.222.10.51]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id FAA26509 for ; Mon, 10 May 1999 05:53:39 GMT Received: from sis.bris.ac.uk by dirc.bris.ac.uk with SMTP-PRIV (PP) with ESMTP; Mon, 10 May 1999 14:58:37 +0100 Received: from resnetih6016 (ih6016.resnet.bris.ac.uk [137.222.211.90]) by sis.bris.ac.uk (8.9.3/8.9.3) with SMTP id OAA27297 for ; Mon, 10 May 1999 14:57:18 +0100 (BST) Message-ID: <007401be9aed$046c84e0$5ad3de89@resnet.bris.ac.uk> From: Iain Hallam To: vsta Subject: Window Systems Date: Mon, 10 May 1999 14:57:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I'm new to VSTa, but already I like it very much. Could someone tell me what state any of the various window system ideas are in? I saw posts in the archives from people wanting to take MADO further, and there was also some speculation on ports of other systems (notably X11?), but no one seems to have said anything since then. Thanks, Iain Hallam. From daemon Mon May 10 11:53:30 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA26980 for vsta-xplod; Mon, 10 May 1999 11:53:30 GMT Received: from synergy.caltech.edu (lloyd-110.caltech.edu [131.215.89.110]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA26961 for ; Mon, 10 May 1999 11:53:26 GMT From: john@synergy.caltech.edu Received: (from john@localhost) by synergy.caltech.edu (8.8.7/8.8.7) id OAA08775 for vsta@zendo.com; Mon, 10 May 1999 14:36:19 -0700 Date: Mon, 10 May 1999 14:36:17 -0700 To: vsta@zendo.com Subject: Re: Window Systems Message-ID: <19990510143615.C7065@synergy.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i On Mon, May 10, 1999 at 08:14:06AM -0700, Andy Valencia wrote: > > GGI is a nicer layering of such graphics capabilities. However, so far as I > can tell from perusing the current code, it depends on things like svgalib > to handle the actual graphics card support. Therefore to get broad graphics > card support you still have to wrestle with svgalib, after which GGI might > be nice to port on top. Somebody with better knowledge can correct me. the GGI library needs some sort of device to talk to. currently it uses dynamic loading of modules to support different devices at runtime... libGGI itself doesnt talk to any hardware directly... the KGI portion however does talk to the hardware and goes into the linux kernel... hmmm perhaps it is time somebody write a 'linux kernel device driver' server which would emulate enough of the linux kernel to allow their device drivers to be used without change... it actually probaby wouldnt be as difficult as one might think, as there is a pretty strict interface which they must follow and most of them are a thin layer that just bangs the hardware... hmmm.. John -- -------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net -------------------------------------------------- ----- End forwarded message ----- -- -------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net -------------------------------------------------- From daemon Mon May 10 07:30:19 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA26632 for vsta-xplod; Mon, 10 May 1999 07:30:19 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA26626 for ; Mon, 10 May 1999 07:30:17 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA06578; Mon, 10 May 1999 08:34:59 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00410; Mon, 10 May 1999 08:15:21 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905101515.IAA00410@vandys-pc.vandys.cisco.com> To: Iain Hallam cc: vsta Subject: Re: Window Systems In-reply-to: Your message of "Mon, 10 May 1999 14:57:18 BST." <007401be9aed$046c84e0$5ad3de89@resnet.bris.ac.uk> Reply-to: vandys@cisco.com Date: Mon, 10 May 1999 08:14:06 -0700 From: Andy Valencia [Iain Hallam writes:] >I'm new to VSTa, but already I like it very much. Could someone tell me what >state any of the various window system ideas are in? I saw posts in the >archives from people wanting to take MADO further, and there was also some >speculation on ports of other systems (notably X11?), but no one seems to >have said anything since then. MGR works. MADO has some good ideas, but exists only in the form of some initial bit-blit server code. X11 could be ported, but there'll be some hassles with sockets and select(). Almost certainly a select() will have to be implemented. Of course, X11 is a big, monolithic windowing system. If you don't mind running such things, why not just run Linux or FreeBSD? svgalib would be nice to have on VSTa. You could run dedicated graphics apps directly on top of it, but you could also run things like X11, or Squeak, or MGR. Properly coded, all of these could then take advantage of the capabilities of a wide range of graphics cards. svgalib has many Linux specific bits of code, though, so that would require some work. GGI is a nicer layering of such graphics capabilities. However, so far as I can tell from perusing the current code, it depends on things like svgalib to handle the actual graphics card support. Therefore to get broad graphics card support you still have to wrestle with svgalib, after which GGI might be nice to port on top. Somebody with better knowledge can correct me. Regards, Andy Valencia From daemon Thu May 13 10:34:30 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA01638 for vsta-xplod; Thu, 13 May 1999 10:34:30 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id KAA01619 for ; Thu, 13 May 1999 10:34:24 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id OAA32379; Thu, 13 May 1999 14:38:43 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: john@synergy.caltech.edu Cc: vsta@zendo.com Date: Thu, 13 May 1999 14:37:47 -0400 Subject: Re: Window Systems Message-ID: References: <19990510143615.C7065@synergy.caltech.edu> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) john@synergy.caltech.edu writes: >the GGI library needs some sort of device to talk to. currently it uses >dynamic >loading of modules to support different devices at runtime... libGGI >itself >doesnt talk to any hardware directly... the KGI portion however does >talk to the >hardware and goes into the linux kernel... hmmm perhaps it is time >somebody >write a 'linux kernel device driver' server which would emulate enough >of the >linux kernel to allow their device drivers to be used without change... >it >actually probaby wouldnt be as difficult as one might think, as there >is a >pretty strict interface which they must follow and most of them are a >thin layer >that just bangs the hardware... hmmm.. > John That sounds like a good idea. I've looked at the source of a couple of linux drivers and it seems possible to make a linkable library that would work with existing code. There would be some overhead as the driver in Linux is expected to do kernel stuff like verifying the user's addresses, etc. And, the interrupt handlers wouldn't actually be executing in an interrupt, but as a normal process responding to an interrupt message. But, for the majority of drivers it seems like it should work. Speaking of OS compatibility, I found this on a Mach project page (http://www.cs.utah.edu/projects/flexmach/mach4/html/projects.html): " VSTa integration: Introduce some level of VSTa compatibility into Mach, so we can take advantage of some of the cool stuff that's being done in VSTa. I haven't explored this much yet, so I don't know what might be feasible, but the possibilities should at least be checked out. For starters, it would be great if we just had someone permantly acting as a go-between for the two projects: someone who can keep fairly close track of both systems, keep recent versions of both of them installed and running on their machine, suggest possible ways to cross-fertilize or make the projects converge, and so on. " Is anyone involved in this? I know that the Mach team is also trying to get more device support into their microkernel via Linux drivers. It would be nice not to duplicate efforts. How does the Mach architecture compare to VSTa's? From daemon Thu May 13 19:10:20 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA02182 for vsta-xplod; Thu, 13 May 1999 19:10:20 GMT Received: from darkstar.welcomehome.org (darkstar.welcomehome.org [192.203.188.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA02163 for ; Thu, 13 May 1999 19:10:11 GMT Received: (from rob@localhost) by darkstar.welcomehome.org (8.8.0/8.8.0) id VAA01345; Thu, 13 May 1999 21:13:34 -0600 (MDT) Message-ID: <19990513211333.19860@welcomehome.org> Date: Thu, 13 May 1999 21:13:33 -0600 From: Rob Savoye To: Eric Jacobs Cc: john@synergy.caltech.edu, vsta@zendo.com Subject: Re: Window Systems References: <19990510143615.C7065@synergy.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Eric Jacobs on Thu, May 13, 1999 at 02:37:47PM -0400 On Thu, May 13, 1999 at 02:37:47PM -0400, Eric Jacobs wrote: > That sounds like a good idea. I've looked at the source of a couple of > linux > drivers and it seems possible to make a linkable library that would > work with > existing code. There would be some overhead as the driver in Linux is > expected to do kernel stuff like verifying the user's addresses, etc. > And, the [ ... ] > Is anyone involved in this? I know that the Mach team is also trying to > get > more device support into their microkernel via Linux drivers. It would > be > nice not to duplicate efforts. How does the Mach architecture compare Check out OSkit (http://www.cs.utah.edu/projects/flux/oskit/). It has a portable device driver framework that uses Linux of FreeBSD drivers in source form, and has all the "fake" kernel support you'd need. I'm currently using it for my Nilo project (www.nilo.org) so I can use any ethernet card support by Linux. Way easier than writting a packet driver... What's also really cool is the latest OSKit snapshot (after the 0.97 release) which has support for running OSKit hosted applications as a user task on Linux, which is great for debugging. Unfortunately, they haven't yet created wrappers for the graphics cards, although they also have an MGR and X11 port. It might be possible to use their kernel routines to speed up supporting svgalib. btw - OSKit is also GPL'd. - rob - From daemon Sun May 16 22:13:24 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA08617 for vsta-xplod; Sun, 16 May 1999 22:13:24 GMT Received: from mx-a.qnet.com ([209.221.198.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA08598; Sun, 16 May 1999 22:13:20 GMT Received: from cello.qnet.com (stork@cello.qnet.com [209.221.198.10]) by mx-a.qnet.com (8.9.1a/8.9.1) with ESMTP id XAA20346; Sun, 16 May 1999 23:18:58 -0700 (PDT) Received: from localhost (stork@localhost) by cello.qnet.com (8.9.0/8.8.5) with ESMTP id XAA21639; Sun, 16 May 1999 23:18:42 -0700 (PDT) X-Authentication-Warning: cello.qnet.com: stork owned process doing -bs Date: Sun, 16 May 1999 23:18:41 -0700 (PDT) From: Heredity Choice To: VSTa@zendo.com cc: vsta-digest@zendo.com Subject: Re: VSTa Digest #412 In-Reply-To: <199905160001.AAA07361@bodhi.zendo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There have been a number of projects that have run a Mach kernel under BSD or Linux. NeXT used a Mach 2.5 kernel, which was not a true microkernel, under BSD. XINU (UNIX spelt backwards) was a commercial project in Berkeley which used BSD on either the Mach 2.5 or the Mach 3.0 kernel. The latter was considered experimental. LITES runs BSD on the Mach 3.0 kernel. MKLINUX is a development by Apple running Linux on the Mach microkernel. Paul Smith From daemon Mon May 17 10:15:01 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA09450 for vsta-xplod; Mon, 17 May 1999 10:15:01 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA09444 for ; Mon, 17 May 1999 10:14:57 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA05903; Mon, 17 May 1999 11:18:38 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00536; Mon, 17 May 1999 10:20:45 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905171720.KAA00536@vandys-pc.vandys.cisco.com> To: Stanislaw Stepien cc: vsta@zendo.com Subject: Re: progect status In-reply-to: Your message of "Mon, 17 May 1999 10:52:54 +0200." Reply-to: vandys@cisco.com Date: Mon, 17 May 1999 10:20:45 -0700 From: Andy Valencia [Stanislaw Stepien writes:] > hi, im new in here > could you fill me with current status of this project The project status is basically what you see in the latest drop (1.6.2, I believe). The vsta/doc/features.txt file pretty much maps out what has happened over time. The mail archives at www.zendo.com/vsta will let you know about recent activities... there aren't many. Regards... Andy Valencia From daemon Fri May 21 06:36:17 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA15259 for vsta-xplod; Fri, 21 May 1999 06:36:17 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id GAA15240 for ; Fri, 21 May 1999 06:36:12 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id KAA13767 for ; Fri, 21 May 1999 10:41:23 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vsta@zendo.com Date: Fri, 21 May 1999 10:39:13 -0400 Subject: Problems with GCC on 386 Message-ID: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I had installed VSTa on a 386 hoping to just mess around with the kernel on it. Everything seems to run ok except when I try to recompile the kernel with GCC. It won't seem to inline any functions; if the function is marked "inline" it simply ignores it and generates hundreds of linker errors instead. So I had to reboot into FreeBSD, set to a.out and re-make the kernel in there (it worked for compilation, but ld dumped core.) Then I boot back into VSTa, finish linking it, and then it works. Is there any way to get this compile properly on an old system, or is inlining functions such an advanced operation that it requires a floating-point unit? From daemon Fri May 21 07:13:26 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA15309 for vsta-xplod; Fri, 21 May 1999 07:13:26 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA15303 for ; Fri, 21 May 1999 07:13:24 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA02049; Fri, 21 May 1999 08:18:38 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00575; Fri, 21 May 1999 08:18:36 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905211518.IAA00575@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Problems with GCC on 386 In-reply-to: Your message of "Fri, 21 May 1999 10:39:13 EDT." Reply-to: vandys@cisco.com Date: Fri, 21 May 1999 08:18:35 -0700 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I had installed VSTa on a 386 hoping to just mess around with the >kernel on it. Everything seems to run ok except when I try to recompile >the kernel with GCC. It won't seem to inline any functions; if the >function >is marked "inline" it simply ignores it and generates hundreds of linker >errors instead. So I had to reboot into FreeBSD, set to a.out and >re-make >the kernel in there (it worked for compilation, but ld dumped core.) >Then I >boot back into VSTa, finish linking it, and then it works. Is there any >way >to get this compile properly on an old system, or is inlining functions >such >an advanced operation that it requires a floating-point unit? Actually, your gcc should simply croak on GCC, at least if you use the optimizer. There's no FPU emulation, so you either have the hardware, or GCC should take a SIGFPU. Without inlining, the way gcc treats inlined functions is kind of broken, so at least for building kernel source I think you're stuck. :-( Andy From daemon Fri May 21 19:05:06 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA16031 for vsta-xplod; Fri, 21 May 1999 19:05:06 GMT Received: from charleston.softhome.net (qmailr@charleston.SoftHome.net [204.144.231.41]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id TAA16012 for ; Fri, 21 May 1999 19:05:03 GMT Message-Id: <199905211905.TAA16012@bodhi.zendo.com> Received: (qmail 304 invoked by uid 417); 22 May 1999 03:31:49 -0000 Received: from unknown (HELO pentium-100) (203.35.12.211) by smtp.softhome.net with SMTP; 22 May 1999 03:31:49 -0000 From: "James Campbell Haggerty" To: vsta@zendo.com Date: Sat, 22 May 1999 13:10:17 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Extended chars. + other newbie questions Reply-to: j.h@softhome.net Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01c) I installed VSTa a couple of weeks ago, and it's working quite well. However, there's one serious problem - none of the non-terminal characters on my keyboard work - e.g. arrow keys, ins, del, etc. I also can't use CAPS-LOCK (no effect and no light) and NUM-LOCK (this appears to work, but the light doesn't change). For example, if I enter an arrow key at the shell prompt I get A, or B etc. At the login prompt I get OA, OB etc. However, enter the ANSI codes manually - ESC[A - works fine, but this is a pain. Is this a problems with cons? termcap? Can someone explain how VSTa implements its keyboard handling? Please help! (excuse the possible stupidity of this question, as I am both fairly inexperienced with UNICES and programming). A couple of other less important questions: - How can I change the background in MGR? - What does "cons3" do, and can you replace the one on the website with one that isn't corrupted? - What happened to the mailing list archives? The last message was in Oct. 98 on the web site, but it says it is automatically updated daily. Has the address of the updater been deleted from the mailing list? Thanks in advance, James From daemon Sat May 22 06:30:31 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA18821 for vsta-xplod; Sat, 22 May 1999 06:30:31 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA18815 for ; Sat, 22 May 1999 06:30:28 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA19629; Sat, 22 May 1999 07:35:38 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00319; Sat, 22 May 1999 07:35:35 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905221435.HAA00319@vandys-pc.vandys.cisco.com> To: Stanislaw Stepien cc: Eric Jacobs , vsta@zendo.com Subject: Re: Problems with GCC on 386 In-reply-to: Your message of "Sat, 22 May 1999 10:05:03 +0200." Reply-to: vandys@cisco.com Date: Sat, 22 May 1999 07:35:34 -0700 From: Andy Valencia [Stanislaw Stepien writes:] > hi there >I have one question: why floting point operations are needed to compile >programs ? Which part of compiler uses floting points operations ? From memory, there's this one register usage calculation which uses floating point instead of integer/fixed point. In the very earliest version of gcc I ever ported to VSTa, I got a patch out of the old djgpp (gcc for DOS) port which changed it to not use float. Later versions of djgpp stopped patching gcc, so eventually VSTa supported the FPU and I stopped patching, too. This is mostly OK, but occasionally bites some poor soul using a 80386 or 80486sx. If somebody wanted, they might be able to dredge up old VSTa (or djgpp) gcc source, extract the technique, and see what it would take to bring it forward. I'd be happy to fold a successful patch back in and make that the gcc for the distribution. Compilers using the FPU for basic algorithms seems wrong to me, too. Andy Valencia From daemon Sat May 22 06:47:42 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA18943 for vsta-xplod; Sat, 22 May 1999 06:47:42 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA18937 for ; Sat, 22 May 1999 06:47:40 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA19851; Sat, 22 May 1999 07:52:56 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00372; Sat, 22 May 1999 07:52:54 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905221452.HAA00372@vandys-pc.vandys.cisco.com> To: j.h@softhome.net cc: vsta@zendo.com Subject: Re: Extended chars. + other newbie questions In-reply-to: Your message of "Sat, 22 May 1999 13:10:17 +1000." <199905211905.TAA16012@bodhi.zendo.com> Reply-to: vandys@cisco.com Date: Sat, 22 May 1999 07:52:54 -0700 From: Andy Valencia ["James Campbell Haggerty" writes:] >However, there's one serious problem - none of the non-terminal >characters on my keyboard work - e.g. arrow keys, ins, del, etc. I >also can't use CAPS-LOCK (no effect and no light) and NUM-LOCK >(this appears to work, but the light doesn't change). CAPS LOCK I disabled intentionally. See vsta/src/srv/mach/cons2; I think I left the code for it under an ifdef. But I hate caps lock... it seems to do more damage than good. >For example, if I enter an arrow key at the shell prompt I get >A, or B etc. At the login prompt I get OA, OB etc. >However, enter the ANSI codes manually - ESC[A - works fine, but >this is a pain. That stuff at least used to work. Again, if you take a peek in the console server you can find the code which would--delta bugs--generate exactly the same sequence. >Is this a problems with cons? termcap? Can someone explain how >VSTa implements its keyboard handling? The source I named is a process which takes keyboard interrupts and extracts the typed characters. Any process using a TTY accesses bytes through the usual read()/write() interface. Code in libc turns this into a simple I/O protocol, which is what cons2/rw.c expects as it takes I/O requests. So you should be able to follow the code as it takes the special key event, puts data in the typing buffer, and later extracts this to complete TTY reads. >- How can I change the background in MGR? Don't know that you can! >- What does "cons3" do, and can you replace the one on the >website with one that isn't corrupted? cons3 was a chunk of code which also appeared in Linux to implement a full ANSI terminal emulator, including neat stuff like color, enhanced attributes, and so forth. But it was somewhat less efficient, and nobody seemed to be using it, so cons2 is the default one. At this point, I think there are a couple features missing from it--like ^C handling. >- What happened to the mailing list archives? The last message >was in Oct. 98 on the web site, but it says it is automatically >updated daily. Has the address of the updater been deleted from >the mailing list? Hmmm... looks like a bug in hypermail. I'll update and debug it if it still doesn't work its way through the whole archive. Andy From daemon Tue May 25 11:47:27 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA23657 for vsta-xplod; Tue, 25 May 1999 11:47:27 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id LAA23638 for ; Tue, 25 May 1999 11:47:21 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id PAA30750 for ; Tue, 25 May 1999 15:52:44 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vsta@zendo.com Date: Tue, 25 May 1999 15:51:51 -0400 Subject: Wild PID's Message-ID: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I have been working on putting together a VSTa boot disk off of floppies. Everything seems okay, but one strange thing is happening: after reading about half the disk, the PID's have increased by approximately 3000. Is this okay/normal?? From daemon Tue May 25 12:26:49 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA23730 for vsta-xplod; Tue, 25 May 1999 12:26:49 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA23724 for ; Tue, 25 May 1999 12:26:47 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA00356; Tue, 25 May 1999 13:32:06 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id NAA01350; Tue, 25 May 1999 13:32:04 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905252032.NAA01350@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Wild PID's In-reply-to: Your message of "Tue, 25 May 1999 15:51:51 EDT." Reply-to: vandys@cisco.com Date: Tue, 25 May 1999 13:32:04 -0700 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I have been working on putting together a VSTa boot disk >off of floppies. Everything seems okay, but one strange >thing is happening: after reading about half the disk, the >PID's have increased by approximately 3000. Is this >okay/normal?? Pretty much... the floppy server spins up a thread when he needs timing support. That'd cause you to work your way through PID's. It's probably also a symptom that something needs to be optimized. :-> Andy From daemon Tue May 25 18:09:09 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA24170 for vsta-xplod; Tue, 25 May 1999 18:09:09 GMT Received: from mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id SAA24151 for ; Tue, 25 May 1999 18:09:03 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id WAA10474; Tue, 25 May 1999 22:13:56 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Tue, 25 May 1999 22:12:58 -0400 Subject: Re: Wild PID's Message-ID: References: <199905252032.NAA01350@vandys-pc.vandys.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@cisco.com writes: >Pretty much... the floppy server spins up a thread when he needs timing >support. That'd cause you to work your way through PID's. It's >probably >also a symptom that something needs to be optimized. :-> Oh, yeah... I saw that before, but I didn't make the connection :) PID's only have to be unique, so it was just a curiousity rather than an actual problem. If a message loop wants to be notified of a timer event, it would have to create a thread, true; but I was under the impression that tfork'ing (and even forking) under VSTa was pretty efficient? (maybe not 3000 times in a row, though. :) Speaking about the floppy driver, I had to make a couple of changes to make it work on a boot disk. After getting it to link as a boot server, the floppy driver would crash trying to allocate the bounce buffer on certain systems. The error was EBUSY, which I assume was generated by mach_page_wire(), noticing that the original page had already been attached to some physical memory. I'm probably not explaining this right, and I didn't really understand what I was doing, but on a whim I changed the malloc() in fd to a direct mmap() for anonymous memory, and lo and behold, it started working. I'm still not sure what happened though. Does malloc always commit to physical memory? It doesn't seem like it should. From daemon Tue May 25 21:45:20 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA24416 for vsta-xplod; Tue, 25 May 1999 21:45:20 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id VAA24410 for ; Tue, 25 May 1999 21:45:16 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA03849; Tue, 25 May 1999 22:50:44 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id WAA00354; Tue, 25 May 1999 22:49:46 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905260549.WAA00354@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Wild PID's In-reply-to: Your message of "Tue, 25 May 1999 22:12:58 EDT." Reply-to: vandys@cisco.com Date: Tue, 25 May 1999 22:49:46 -0700 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >PID's only have to be unique, so it was just a curiousity rather than an >actual problem. If a message loop wants to be notified of a timer event, >it would have to create a thread, true; but I was under the impression >that tfork'ing (and even forking) under VSTa was pretty efficient? >(maybe not 3000 times in a row, though. :) Actually, given the speed of a floppy, it's probably not too bad! >Speaking about the floppy driver, I had to make a couple of changes >to make it work on a boot disk. After getting it to link as a boot >server, >the floppy driver would crash trying to allocate the bounce buffer on >certain systems. The error was EBUSY, which I assume was generated >by mach_page_wire(), noticing that the original page had already been >attached to some physical memory. First question is whether your system has more than 16 megs of RAM? ISA DMA can only address the first 16 megs, so you have to start using bounce buffers. >I'm probably not explaining this >right, and I didn't really understand what I was doing, but on a whim >I changed the malloc() in fd to a direct mmap() for anonymous memory, >and lo and behold, it started working. I'm still not sure what happened >though. Does malloc always commit to physical memory? It doesn't >seem like it should. No, malloc() generally gives you virtual memory, with the physical memory behind it faulted in on demand. But that memory can be allocated anywhere in the full physical range--which can result in buffers in high memory which the floppy DMA can't touch. For quite a long time we had a patch to cap memory at 15 megs or so. I fixed up the bounce buffer stuff (with, apparently, some bugs left :->) because I got tired of seeing most of my 64 megs in my SMP box sitting idle. This is probably what will also prod me to finally cook up x86 SMP support! If you can figure out what's going wrong I'll be happy to try and fix it. Andy From daemon Wed May 26 07:03:53 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA25178 for vsta-xplod; Wed, 26 May 1999 07:03:53 GMT Received: from mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id HAA25159 for ; Wed, 26 May 1999 07:03:43 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id LAA01887; Wed, 26 May 1999 11:08:37 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Wed, 26 May 1999 11:07:28 -0400 Subject: Re: fd server DMA Message-ID: References: <199905260549.WAA00354@vandys-pc.vandys.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@cisco.com writes: >No, malloc() generally gives you virtual memory, with the physical >memory >behind it faulted in on demand. But that memory can be allocated >anywhere >in the full physical range--which can result in buffers in high memory >which >the floppy DMA can't touch. >For quite a long time we had a patch to cap memory at 15 megs or so. I >fixed up the bounce buffer stuff (with, apparently, some bugs left :->) >because I got tired of seeing most of my 64 megs in my SMP box sitting >idle. >This is probably what will also prod me to finally cook up x86 SMP >support! >If you can figure out what's going wrong I'll be happy to try and fix >it. Well, I looked at the source again, and here's what seems to be happening :) If when fd mallocs the bounce buffer, it happens to be located in < 16M, mach_page_wire will say, okay, that's ISA DMA-able and leave it alone. You won't have a problem. If for some reason fd gets a page in high memory, mach_page_wire will have to move it beneath the 16M boundary. That much we already knew. The problem is that malloc() is guaranteed only to give you usable memory; there's no telling whether that memory will be committed or uncommitted, if the block requested would fit into a bucket (less than 32k, I think.) In fact, free() never gives the allocated bucket memory back to the OS until the process exits. It simply reuses, which is fine for most cases, but this time it causes trouble. fd requests a 512-byte bounce buffer, which is allocated using the bucket system. If that memory was already committed (and used) in physical memory, it will have been already attached to that process's pview, and mach_page_wire will refuse to move it. So, you could fix this a couple of ways: 1) Always use mmap() for trying to wire pages for ISA DMA. This works, because you know mmap() going to give you unused virtual memory. Also, this particular need is rare enough to justify doing it differently in this one case. 2) Have page_wire() adopt the policy of "the customer is always right"; i.e., if the process gives a virtual address that is already in use, simply detach all of the other outstanding references. 3) Have free() not only deallocate but also decommit the memory it frees. I don't think there is a syscall that will do this, and it also seems expensive and unnecessary for the vast majority of applications. From daemon Fri May 28 08:24:07 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA28383 for vsta-xplod; Fri, 28 May 1999 08:24:07 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA28377 for ; Fri, 28 May 1999 08:24:03 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA14975 for ; Fri, 28 May 1999 09:29:39 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA01702 for ; Fri, 28 May 1999 09:29:37 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199905281629.JAA01702@vandys-pc.vandys.cisco.com> To: vsta@zendo.com Subject: Mailing list WWW indexer fixed Reply-to: vandys@cisco.com Date: Fri, 28 May 1999 09:29:37 -0700 From: Andy Valencia One of our dearly departed subscribers (in his unsubscribe message, sent to the mailing list itself, to add insult to injury :->) also provided us with an example of a corrupted MIME header. This confused hypermail (the SW which indexes the mailing list into a WWW page) and it lost all mail messages after that one. I've fixed hypermail to ignore this mistake, and the mailing list archive at http://www.zendo.com/vsta/mail/current/ is now up to date. Sorry for any inconvience! Andy From daemon Mon May 31 07:04:05 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA04922 for vsta-xplod; Mon, 31 May 1999 07:04:05 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id HAA04913; Mon, 31 May 1999 07:04:02 GMT Message-Id: <199905310704.HAA04913@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: arkadion@hotmail.com Cc: vsta@zendo.com Subject: Re: VSTa & vi/emacs In-reply-to: Your message of "Sat, 29 May 1999 19:59:17 MST." <3750A984.C79C90F6@hotmail.com> Date: Mon, 31 May 1999 07:04:02 +0000 From: Andy Valencia [Legolas Pascal writes:] >I installed VSTa on a computer, >and after logging in as root, I try to run 'vi' or 'emacs' >and both give me errors concerning the terminal. >Emacs complains that TERM is not defined and vi says >"OOPs" a bunch of times. What am I doing wrong? Did you monkey with the TERM environment variable? It should have been set to "nansi" in /vsta/etc/rc. I'm going to create a sample account "guest" in /vsta/guest (actually, the account exists today, but its home has been /tmp). That account will have more examples of supporting files like the "sh" profile and _exrc for "vim". But none of this should be needed if the default environment has been set up correctly by the boot sequence. Andy From daemon Tue Jun 1 04:51:19 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id EAA06299 for vsta-xplod; Tue, 1 Jun 1999 04:51:19 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id EAA06279; Tue, 1 Jun 1999 04:51:14 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id IAA02794; Tue, 1 Jun 1999 08:56:56 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@zendo.com Cc: arkadion@hotmail.com, vsta@zendo.com Date: Tue, 1 Jun 1999 08:55:43 -0400 Subject: Re: VSTa & vi/emacs Message-ID: References: <199905310704.HAA04913@bodhi.zendo.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@zendo.com writes: >>I installed VSTa on a computer, >>and after logging in as root, I try to run 'vi' or 'emacs' >>and both give me errors concerning the terminal. >>Emacs complains that TERM is not defined and vi says >>"OOPs" a bunch of times. What am I doing wrong? >Did you monkey with the TERM environment variable? It should have been >set to "nansi" in /vsta/etc/rc. Also make sure that the environment is connected to /env. If not, use vsta$ mount ENV /env Then you also might need to recreate the per-connect directory: vsta$ mkdir "/env/#" or, to get into a certain account's environment, for example: vsta$ mkdir "/env/root/#" Note that disconnecting and reconnecting to /env causes you to lose your per-connect environment, which is where the POSIX layer stores its environmental variables. It's made complicated by the fact that sh has its own environment cache and that it doesn't report errors during getenv()/setenv()/putenv(). After doing the mkdir you should be able to do TERM=nansi and export TERM and that will properly export to the child processes. From daemon Tue Jun 1 06:41:15 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA06513 for vsta-xplod; Tue, 1 Jun 1999 06:41:15 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA06507 for ; Tue, 1 Jun 1999 06:41:13 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA11039; Tue, 1 Jun 1999 07:46:59 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00289; Tue, 1 Jun 1999 07:46:57 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199906011446.HAA00289@vandys-pc.vandys.cisco.com> To: arkadion@hotmail.com Cc: vsta@zendo.com Subject: Re: ok... Reply-to: vandys@cisco.com Date: Tue, 01 Jun 1999 07:46:56 -0700 From: Andy Valencia >Ok, I did what runrc should have done... and now started emacs again >but now it complains "Incomplete termcap entry" >As if it wasn't finding the termcap in /vsta/lib... >i looked in that directory and found termcap and libtermcap.a (it should >have been libtermcap.a but with vsta ls it showed libterm~1.a... perhaps >that's a problem?) >Termcap had all the neccessary stuff for nansi, so now I'm stumped. What >could the problem be? Hmmm, I'm starting to suspect an issue with how you extracted all the stuff. VSTa on a DOS filesystem assumes truncation of the filename to 8.3 (8-letter filename, 3-letter file extension). It sounds like your extraction kept the full filename in the new filesystem format (which is legit), but renamed the truncated version to one of those new *~.; Wed, 2 Jun 1999 18:51:33 GMT Received: from fcgateway (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with SMTP id WAA08496 for ; Wed, 2 Jun 1999 22:56:49 -0400 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vsta@zendo.com Date: Wed, 2 Jun 1999 22:55:24 -0400 Subject: More DMA fun Message-ID: Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) I was playing with the bounce buffer in the fd server some more, and I started having a new problem: when the fd server exits after a session when the bounce buffer is NOT used, the kernel panics. It happens during a long series of sanity checks in pset.c. I suspect that the assert itself is in error. The logic of the sanity check is that if a page is valid (PP_V), then it should have a cached reference on the attach list (this is after all of the references are freed.) But in the case of the fd server, when the bounce buffer is allocated, page_wire needs to get a physical address, so it calls pset_fillslot, but then immediately decrements the reference count because it's not going to attach it yet. That procedure causes the page to become valid, but if the page is never actually referenced by the process, it will never end up with even a cache reference. This causes the panic "v !atl". Since the data structures accurately represent the state of the system (no bad pointers or wrong reference counts, etc.), it seems to me that this is a false alarm. Andy? This problem is easy to replicate: write a program that mmaps a buffer of anonymous memory, wire it and then try to exit. It'll panic. If you write anything to the buffer before you exit, though, the panic won't happen. The original fd server doesn't have this problem, even when it never uses the bounce buffer. This means that a reference does get on the attach list. However, it is exactly this condition that causes mach_page_wire to fail on certain machines (if the page is above the 16M mark, it requires that the page is not referenced in order to move it.) This is the problem that I was originally trying to fix by changing malloc() to mmap(). From daemon Mon Jun 7 09:44:58 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA18068 for vsta-xplod; Mon, 7 Jun 1999 09:44:58 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA18062 for ; Mon, 7 Jun 1999 09:44:55 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA21098 for ; Mon, 7 Jun 1999 10:50:49 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00883 for ; Mon, 7 Jun 1999 10:50:46 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199906071750.KAA00883@vandys-pc.vandys.cisco.com> To: vsta@zendo.com Subject: Fwd: VM bug Date: Mon, 07 Jun 1999 10:50:45 -0700 From: Andy Valencia Real good debug work here. Note that the VSTa list doesn't permit binary attachments in messages, so I'm forwarding Eric's message, along with the test program in source form. I need to scratch my head on the COW aspect a bit before I send an actual answer. Andy Valencia >From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) >To: vsta@zendo.com >Date: Sun, 6 Jun 1999 19:47:59 -0400 >Subject: Threads race for VM >Message-ID: >Organization: Montgomery County Public Schools >MIME-Version: 1.0 > >I just finished unconvering a nasty race for virtual memory that >sometimes occurs in multi-threaded processes. The most likely to >be affected are processes that call static-linked functions for the >first time in two or more threads at the same time. > >Race.c, when linked using the static libraries (-lc_s), will cause >a kernel panic after the thread fork (kern/atl.c: add_atl: already >there). The sequence of events I suspect goes something like this: >One thread goes first, and calls syslog. That page isn't loaded >into memory yet, so it locks the page slot and asks the server for >that page, with fod_fillslot. Before that read is completed, the >other thread also tries to call syslog. The page isn't available >yet, so it also faults. When this thread goes to lock the page >slot, the slot is busy and so it blocks. The first thread completes >the read and attaches the page, sets the hardware translation, >and releases the lock. However, the second thread has already >faulted! So the second thread wakes up, references the page that was >just loaded, and tries to attach it, but this would mean that a >page is being attached twice for the same pview, which is a no-no >and the kernel panics. > >I added a simple loop to vm_fault.c after the lock_slot() that scans >the attach list to see if the page is already there before it goes to >fill it, and if it is, it just skips it and returns without an error. >The logic is that if that page is already attached, there shouldn't >have been a fault, and we just return. This simple solution works for >all situations except for copy-on-write; a COW page would already >have an attachment for that page anyway. More thought is required for >this one; COW pages may still be able to race (although I haven't >encountered a situation where this happens.) > >The real issue here, I suppose, is that page slot "locks" aren't >really like the normal p_lock/v_lock kind of lock, but rather more >like semaphores that set up a critical section that encompasses the >perpage, attach list and hat_*trans information. When another thread >tries to access any address in that page while we have the lock, it's >violating our critical section. Of course, the i386 doesn't know that; >it just does what the HAT tells it to do. So when a thread gets a >fault for a page and the page slot is busy, that means that when the >i386 generated the fault, it used the HAT information when it was not >algorithmically correct to do so. > >What this means is that when lock_slot finds the slot is busy and >has to wait, we need to recheck all of the conditions that could >have caused a fault, because the processor wasn't using "thread-safe" >information. Fortunately, this condition seems to be rather rare. >Perhaps a more ideal solution would be to have lock_slot() return >a flag which indicates whether it had to wait for the slot to be >free. That way we wouldn't have to scan the pp_atl every time. >Or maybe we could just have vm_fault return in such a case, to try >to regenerate the fault now that the HAT is up-to-date? > >Using shared libraries with -lc, race.c won't panic the kernel >because the libc shared libraries are likely already loaded by the >time the program runs. If you put a syslog() before the thread fork, >it will also avoid the panic, because syslog gets paged in from the >binary before the race happens. This can make debugging this kind of >thing a real pain; when I put syslog's in to see where the panic was >happening, the problem went away! Race.c: #include #include void thread(void) { syslog(LOG_INFO, "thread info"); mutex_thread(0); } int main(void) { int t; t = tfork(thread, 0); syslog(LOG_INFO, "main info"); mutex_thread(0); return(0); } From daemon Sun Jul 4 05:58:42 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA06388 for vsta-xplod; Sun, 4 Jul 1999 05:58:42 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA06380 for ; Sun, 4 Jul 1999 05:58:38 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA08035; Sun, 4 Jul 1999 07:06:02 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00272; Sun, 4 Jul 1999 07:05:45 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199907041405.HAA00272@vandys-pc.vandys.cisco.com> To: Simon Britnell cc: vsta@zendo.com Subject: Re: Is anyone cross-compiling VSTa under linux? set_core assertion failure. In-reply-to: Your message of "Sun, 04 Jul 1999 21:01:25 +1200." <377F22E5.2FC97FA5@peace.com> Reply-to: vandys@cisco.com Date: Sun, 04 Jul 1999 07:05:44 -0700 From: Andy Valencia [Simon Britnell writes:] >set_core fails the pfn>0 assertion ( pfn passed in is actually 0 ). >set_core is called from fod_fillslot. The pfn passed in is obtained >from alloc_page() immediately prior to the set_core call. This means, basically, that you ran out of memory. The assertion is wrong, but fixing the assertion will merely mean your system will hang one page allocation later. Periodically people do indeed cross compile from UNIX-en of various sorts. The Cygnus distribution of the tools added a description for VSTa quite a while ago, and its parameters are still an accurate description of what's needed. Regards, Andy From daemon Tue Jul 6 10:01:52 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA09622 for vsta-xplod; Tue, 6 Jul 1999 10:01:52 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA09616 for ; Tue, 6 Jul 1999 10:01:40 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA10808; Tue, 6 Jul 1999 11:09:09 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id LAA00657; Tue, 6 Jul 1999 11:07:53 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199907061807.LAA00657@vandys-pc.vandys.cisco.com> To: edmundo@rano.demon.co.uk cc: vsta@zendo.com Subject: Re: some questions In-reply-to: Your message of "Sun, 04 Jul 1999 20:37:27 BST." Reply-to: vandys@cisco.com Date: Tue, 06 Jul 1999 11:07:53 -0700 From: Andy Valencia [edmundo@rano.demon.co.uk writes:] >Has VSTa been tested with SMP yet? Nope, it needs some new code first. >Does it work with more than 16 MB >of memory yet? Yes, delta some bugs reported while exercising the floppy. IDE (and any other programmed I/O) has worked fine for ages. >How do I set up swap? There's a lot on this in the mail archives. >How do I use the network? By randoming messing around, running ne and >ka9q from the shell, I got stuff I typed on another machine to appear >on the machine running VSTa, so it seems possible with my hardware, >but I couldn't get telnetd to work so that I could actually log in. You have to launch telnetd as root, so it can assume your login ID. >Is the following problem already known, or solved? > Assertion failed line 374 file ../kern/vm_page.c > set_core: bad index >I got this once by typing "ps" in one console while making ka9q in >another console. I can get it reproducibly by malloc-ing an array of >10000000 char and writing to the array. You ran out of memory. >What does "perm" mean? It keeps appearing. Probably an exit status of 1 from some command. >Is it possible to download an archive of the mailing list? It's >cheaper for me to browse off-line. In addition to the archives in http://www.zendo.com/vsta/, there's also "Vsta[0-9]*.gz" files in the distribution area, which are archives of text going all the way back. >The man pages for msg_port and msg_connect give the wrong return type >in the prototype. The man page for msg_portname gives the wrong >function name, and a different return type from include/sys/msg.h, but >in this case I assume the include file is wrong? I'll look into this. >If there is a discussion anywhere of how VSTa's IPC primitives were >chosen, I'd be interested to read it. What are the advantages and >disadvantages compared with the IPC in L4/Fiasco, for example? VSTa pre-dates these OS's (by quite a bit, I think), so it's never come up. By the time they were making their decisions VSTa was already pretty much written. Andy From daemon Tue Jul 6 14:13:02 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA10001 for vsta-xplod; Tue, 6 Jul 1999 14:13:02 GMT Received: from mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id OAA09982 for ; Tue, 6 Jul 1999 14:12:58 GMT Received: from (fcgateway.mcps.k12.md.us [205.222.5.94]) by mcps.k12.md.us (8.6.12/8.6.12) with ESMTP id SAA09565; Tue, 6 Jul 1999 18:19:43 -0400 Message-id: Date: Tue, 06 Jul 1999 18:16:41 -0400 Subject: Re(2): Is anyone cross-compiling VSTa under linux? set_core assertion failure. To: vandys@cisco.com Cc: simonb@peace.com, vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit For some reason I did not see the original message, only Andy's response. vandys@cisco.com writes: > >Periodically people do indeed cross compile from UNIX-en of various sorts. >The Cygnus distribution of the tools added a description for VSTa quite a >while ago, and its parameters are still an accurate description of what's >needed. One thing I noticed that you need to watch out for when cross compiling was to make sure you have GNU ld for a.out. The a.out ld that comes with FreeBSD, for example, won't understand the vsta.lnk file. What was the original problem? From daemon Thu Jul 15 09:13:14 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA25083 for vsta-xplod; Thu, 15 Jul 1999 09:13:14 GMT Received: from shelbyville.oai.com ([204.57.59.144]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA25064 for ; Thu, 15 Jul 1999 09:13:08 GMT Received: (from mirian@localhost) by shelbyville.oai.com (8.9.3/8.9.3) id NAA04702; Thu, 15 Jul 1999 13:20:33 -0400 From: Mirian Crzig Lennox To: vsta@zendo.com Subject: microkernel design question Original-Sender: lennox@alcita.com Organization: Alcita Technologies, Inc. Date: 15 Jul 1999 13:20:33 -0400 In-Reply-To: Andy Valencia's message of "Mon, 07 Jun 1999 10:50:45 -0700" Message-ID: Lines: 34 Hi VSTa folks! I have a question. How much does the fact that every driver in VSTa runs as a separate process impact performance? As example, on my NetBSD box, I have the following "drivers" running: IDE SCSI ATAPI VGA card WSCons (virtual consoles driver) NE2000 network card TCP/IP NFS BSD FFS filesystem MS-DOS FAT filesystem Linux EXT2 filesystem ISO 9660 filesystem SoundBlaster sound card Sun audio interface MIDI PS/2 mouse This is pretty typical for a real-world machine. On a VSTa box, each of these 16 drivers/subsystems would be a separate process, with the scheduling, context-switching and vm overhead that that implies. OTOH, because the design of VSTa is for most everything to be a usermode process, I'm sure the overhead is much less than in a monolithic OS like UNIX. The question is, how much less, and does it ever become the performance bottleneck? -- Mirian Crzig Lennox Systems Anarchist Invest in America -- buy a Congressman! From daemon Thu Jul 15 11:27:07 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA25222 for vsta-xplod; Thu, 15 Jul 1999 11:27:07 GMT Received: from malasada.lava.net (malasada.lava.net [199.222.42.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA25203 for ; Thu, 15 Jul 1999 11:27:04 GMT Received: from localhost (1723 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Thu, 15 Jul 1999 09:35:25 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #2 built 1999-Jun-23) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: Re: microkernel design question To: lennox@alcita.com (Mirian Crzig Lennox) Date: Thu, 15 Jul 1999 09:35:24 -1000 (HST) Cc: vsta@zendo.com In-Reply-To: from "Mirian Crzig Lennox" at Jul 15, 99 01:20:33 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > As example, on my NetBSD box, I have the following "drivers" running: > IDE > SCSI > ATAPI > VGA card > WSCons (virtual consoles driver) > NE2000 network card > TCP/IP > NFS > BSD FFS filesystem > MS-DOS FAT filesystem > Linux EXT2 filesystem > ISO 9660 filesystem > SoundBlaster sound card > Sun audio interface > MIDI > PS/2 mouse > > This is pretty typical for a real-world machine. On a VSTa box, each > of these 16 drivers/subsystems would be a separate process, not quite. In BSD, you configure subdrivers seperately from drivers (for example soundblaster subdriver and the audio subsystem). In VSTa these two would likely be in the same process. Perhaps the master driver would be encapsulated in a library. At any rate, ATAPI and IDE may well be together, console and VGA would likely be together, MIDI, soundblaster and audio would likely be together. The filesystems would only be run when they are in use [ie. a filesystem is mounted] (do you normally use nfs, ffs, fat, ext2 and iso9660 on the same time on the same system?). As for the answer to your question, I don't know. Hopefully someone else will pick that up. > Mirian Crzig Lennox Systems Anarchist From daemon Thu Jul 15 12:03:11 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA25308 for vsta-xplod; Thu, 15 Jul 1999 12:03:11 GMT Received: from shelbyville.oai.com ([204.57.59.144]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA25289 for ; Thu, 15 Jul 1999 12:03:07 GMT Received: (from mirian@localhost) by shelbyville.oai.com (8.9.3/8.9.3) id QAA01141; Thu, 15 Jul 1999 16:10:27 -0400 From: Mirian Crzig Lennox To: vsta@zendo.com Subject: Re: microkernel design question References: Original-Sender: lennox@alcita.com Organization: Alcita Technologies, Inc. Date: 15 Jul 1999 16:10:26 -0400 In-Reply-To: newsham@lava.net's message of "Thu, 15 Jul 1999 09:35:24 -1000 (HST)" Message-ID: Lines: 22 newsham@lava.net (Tim Newsham) writes: > > not quite. In BSD, you configure subdrivers seperately from drivers > (for example soundblaster subdriver and the audio subsystem). In VSTa > these two would likely be in the same process. So far, that's not the way it seems to work in VSTa. There seems to be an interest in keeping the hardware-specific drivers in their own processes (e.g. the ne process is separate from the ka9q process), which I think is a laudable goal... it keeps each piece of the system relatively simple and without "magic" interdependencies. > The filesystems > would only be run when they are in use [ie. a filesystem is mounted] > (do you normally use nfs, ffs, fat, ext2 and iso9660 on the same time on > the same system?). If it's a multiboot machine, then certainly. -- Mirian Crzig Lennox Systems Anarchist Invest in America -- buy a Congressman! From daemon Fri Jul 16 06:28:37 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA26471 for vsta-xplod; Fri, 16 Jul 1999 06:28:37 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA26465 for ; Fri, 16 Jul 1999 06:28:34 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA21060; Fri, 16 Jul 1999 07:36:28 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00322; Fri, 16 Jul 1999 07:35:55 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199907161435.HAA00322@vandys-pc.vandys.cisco.com> To: Edmund GRIMLEY EVANS cc: Mirian Crzig Lennox , vsta@zendo.com Subject: Re: microkernel design question In-reply-to: Your message of "Fri, 16 Jul 1999 09:54:41 BST." <378EF351.C85DFD35@rano.demon.co.uk> Reply-to: vandys@cisco.com Date: Fri, 16 Jul 1999 07:35:55 -0700 From: Andy Valencia [Edmund GRIMLEY EVANS writes:] >The loss of performance greatly depends on the task but can be only 5%. Edmund is quite correct. The question is not whether splitting things into processes adds overhead--it certainly does--but what is this overhead, amortized over the service it provides? So if a server gives you something which will take 1 millisecond of work to use, and the server took 500 microseconds to get it, and your context switch is 10 microseconds, then you're looking at 10/1500, or less than 1%. Of course, you can play with scenarios until the overhead is 10%, or 50%, or whatever. If the scenarios are real, practical, and frequently occurring ones, then this sort of ratio is generally a sign that it's time to redesign your client/server interface. >If your microkernel architecture allows you do SMP better, then you >might be able to beat some monolithic systems, such as Linux, on a >multiprocessor system. The reason NT was 4 times faster than Linux in >tests sponsored by Microsoft was that the tests were designed to >exploit Linux's inability to run more than one processor at a time in >kernel-mode on a system with 4 processors. At least that's the >impression I have. Well, I designed VSTa with a desire to permit processes, threads, and all kernel services to be able to run in parallel. The kernel itself is an attempt at a pretty efficient SMP implementation. Most of the processes are not; they gain simplicity by using quite a bit of single threading. >You can do SMP properly without a microkernel, though. I think that's >what Solaris does. They do. It started out badly, and has improved quite a bit (we use Solaris SMP servers for SW development at Cisco). >What's SMP like on BSD? Are there any free operating systems that do >SMP better than Linux? Is anyone here working on that? Linux is pretty much ahead of the game. FreeBSD is also a single-lock kernel design. Of the free OS's, the two I know of which do real SMP parallelism in the OS are Mach and VSTa. Andy From daemon Sat Jul 24 12:51:10 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA12606 for vsta-xplod; Sat, 24 Jul 1999 12:51:10 GMT Received: from mlwkwi-ns1.usxc.net (mlwkwi-cluster1.usxc.net [209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA12587 for ; Sat, 24 Jul 1999 12:51:05 GMT Received: from debian ([209.141.38.106]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA41AA for ; Sat, 24 Jul 1999 15:59:56 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.101) for ; Sat, 24 Jul 1999 16:06:02 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <3799E469.E6127984@usxchange.net> Date: Sat, 24 Jul 1999 16:06:01 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Announce: Booting from a vsta partition Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello VSTa comunity, I would like to announce that I added vstafs support to the grub boot loader. I put the stage1, stage2 and the modified sourcecode into the ftp.zendo.com/incoming ftpsite/directory. If someone wants to try it out, the first s/he has to do is to make a vsta partition. This is described in the docs in the vsta distribution. As next the partition type has to be changed to 0x9e (vstafs). In the grub source code tarball there is a menu.lst with my boot configuration as an example. If possible, I would like to know how it works on other systems before I send the patches to Erich Boylen. Thoms J Erdos From daemon Mon Jul 26 06:19:16 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA15223 for vsta-xplod; Mon, 26 Jul 1999 06:19:16 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA15217 for ; Mon, 26 Jul 1999 06:19:12 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA02916; Mon, 26 Jul 1999 07:27:39 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00575; Mon, 26 Jul 1999 07:27:37 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199907261427.HAA00575@vandys-pc.vandys.cisco.com> To: "Thomas J. Erdos" cc: vsta@zendo.com Subject: Re: Announce: Booting from a vsta partition In-reply-to: Your message of "Sat, 24 Jul 1999 16:06:01 -0000." <3799E469.E6127984@usxchange.net> Reply-to: vandys@cisco.com Date: Mon, 26 Jul 1999 07:27:37 -0700 From: Andy Valencia ["Thomas J. Erdos" writes:] >I would like to announce that I added vstafs support to the grub boot >loader. I put the stage1, stage2 and the modified sourcecode into the >ftp.zendo.com/incoming ftpsite/directory. Nice stuff! I've moved it into ftp://ftp.zendo.com/vsta/pickup/grub_vstafs/. Andy From daemon Tue Jul 27 12:43:07 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA17165 for vsta-xplod; Tue, 27 Jul 1999 12:43:07 GMT Received: from synergy.caltech.edu (lloyd-110.caltech.edu [131.215.89.110]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA17146 for ; Tue, 27 Jul 1999 12:43:02 GMT From: john@synergy.caltech.edu Received: (from john@localhost) by synergy.caltech.edu (8.8.7/8.8.7) id PAA15731 for vsta@zendo.com; Tue, 27 Jul 1999 15:41:14 -0700 Date: Tue, 27 Jul 1999 15:41:12 -0700 To: vsta@zendo.com Subject: Re: Announce: Booting from a vsta partition Message-ID: <19990727154109.I12087@synergy.caltech.edu> References: <3799E469.E6127984@usxchange.net> <199907261427.HAA00575@vandys-pc.vandys.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: <199907261427.HAA00575@vandys-pc.vandys.cisco.com>; from Andy Valencia on Mon, Jul 26, 1999 at 07:27:37AM -0700 although theres no mention of it on the original grub webpage, grub is no longer maintained by eric, it has now become an offical gnu project and is being maintained at http://www.gnu.org/software/grub it was up to 5.91 as of yesterday and is being developed under CVS... until recently I had thought that all grub development stopped from the main pages until i happend upon the above site..... they also have an utility that runs under unix-like oses to install it to the HD directly... (i think, havnt tried it) John -- -------------------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net California Institute of Technology, Student. Sun Microsystems, Solaris Kernel Group. -------------------------------------------------------------- From daemon Fri Jul 30 08:40:41 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA21525 for vsta-xplod; Fri, 30 Jul 1999 08:40:41 GMT Received: from herc.dbi.ro (herc.dbi.ro [193.230.134.76]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA21506 for ; Fri, 30 Jul 1999 08:40:34 GMT Received: by herc.dbi.ro with Internet Mail Service (5.5.1960.3) id <3SMW2G3R>; Fri, 30 Jul 1999 18:44:51 +0200 Message-ID: <51BDB358AE5AD211997F00A024AB07A20DFE53@herc.dbi.ro> From: Mihai Ionescu To: "'vsta@zendo.com'" Subject: Booting problem Date: Fri, 30 Jul 1999 18:44:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Hi, I have a big problem when I try to boot VSTA 1.61 I have 2 HDD, one is master on the first controler and it is NTFS and the second one is SLAVE on the SECOND controler. I putted the vsta directory on the second drive. The problem is that I could'n succed to convince VSTA to see my second driver. I tryed: module=/vsta/boot/wd d1:readp -- failed - No units found module=/vsta/boot/wd d1:readp irq=15 baseio=368 --failed - No units found What sould I do? Thanks, Mihai From daemon Fri Jul 30 10:27:23 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA21622 for vsta-xplod; Fri, 30 Jul 1999 10:27:23 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA21616 for ; Fri, 30 Jul 1999 10:27:21 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA29410; Fri, 30 Jul 1999 11:36:00 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id LAA01571; Fri, 30 Jul 1999 11:35:59 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199907301835.LAA01571@vandys-pc.vandys.cisco.com> To: Mihai Ionescu cc: "'vsta@zendo.com'" Subject: Re: Booting problem In-reply-to: Your message of "Fri, 30 Jul 1999 18:44:46 +0200." <51BDB358AE5AD211997F00A024AB07A20DFE53@herc.dbi.ro> Reply-to: vandys@cisco.com Date: Fri, 30 Jul 1999 11:35:58 -0700 From: Andy Valencia [Mihai Ionescu writes:] >I have a big problem when I try to boot VSTA 1.61 I have 2 HDD, one is >master on the first controler and it is NTFS and the second one is SLAVE >on the SECOND controler. I putted the vsta directory on the second >drive. The problem is that I could'n succed to convince VSTA to see my >second driver. >module=/vsta/boot/wd d1:readp -- failed - No units found >module=/vsta/boot/wd d1:readp irq=15 baseio=368 --failed - No units >found Have you tried letting it find both drives? Also, see if you can get it to find just the first drives on each controller. You need to localize which part of the driver logic is failing. Andy From daemon Fri Jul 30 14:37:29 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA21904 for vsta-xplod; Fri, 30 Jul 1999 14:37:29 GMT Received: from smartwall.fh-rosenheim.de (firewall-user@smartwall.fh-rosenheim.de [141.60.160.7]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA21885 for ; Fri, 30 Jul 1999 14:37:24 GMT Received: by smartwall.fh-rosenheim.de; id AAA22589; Sat, 31 Jul 1999 00:46:33 +0200 (CEST) Received: from mehlbox.rz.fh-rosenheim.de(141.60.50.15) by smartwall.fh-rosenheim.de via smap (4.1) id xma022420; Sat, 31 Jul 99 00:45:14 +0200 Received: from mailserv.fh-rosenheim.de (root@inn.awi.fh-rosenheim.de [141.60.112.10]) by fh-rosenheim.de (8.9.1/8.9.1) with SMTP id AAA31909 for ; Sat, 31 Jul 1999 00:36:25 +0200 Received: from modem36.rz.fh-rosenheim.de by mailserv.fh-rosenheim.de (AIX 3.2/UCB 5.64/4.03) id AA24203; Sat, 31 Jul 1999 00:41:23 +0200 Sender: root@smartwall.fh-rosenheim.de Message-Id: <37A22B0E.7193C305@mindless.com> Date: Sat, 31 Jul 1999 00:45:34 +0200 From: Michael Dingler X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.33 i686) X-Accept-Language: en Mime-Version: 1.0 To: vsta@zendo.com Subject: Current state of Vsta? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What's going on in the Vsta world? The web-site is pretty old and if I remember correctly, the majordomo said that development has stalled or something. So, what's planned, on what projects do you work? And (*shock*), may I help? ;) ...Michael... From daemon Sat Jul 31 15:44:28 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA25423 for vsta-xplod; Sat, 31 Jul 1999 15:44:28 GMT Received: from mlwkwi-ns1.usxc.net (mlwkwi-cluster1.usxc.net [209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id PAA25404 for ; Sat, 31 Jul 1999 15:44:22 GMT Received: from debian ([209.141.38.225]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA6E79 for ; Sat, 31 Jul 1999 18:53:34 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.101) for ; Sat, 31 Jul 1999 19:00:10 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <37A347B9.36F4F53F@usxchange.net> Date: Sat, 31 Jul 1999 19:00:09 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Grub and the VSTa filesystem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello VSTa comunity, a few days ago I announced, that I added VSTa filesystem support to the GRUB bootlloader. John Meacham replied to my announce that some work has been done on the last known GRUB bootloader. So I downloaded the latest version and tried to fix it. While I was working on the newer version, I found that the bootloader I uploaded to the VSTa ftp site, doesn't work correctly. The only problem with it is that, one cannot install the second stage of the bootloader onto a vstafs partition. I simply forgot to add two lines into the vstafs_read subroutine. So I tried with the newer version, but that didn't work either because the installation procedure of GRUB assumes that the second stage file on the harddrive begins at offset 0 of a sector. This is however not the case for vstafs. The begin of the file is somewhere at the end of the first block. Here an exempt from the headerfile: struct fs_file { daddr_t fs_prev; /* Previous version of this file 0 */ ulong fs_rev; /* Revision # 4 */ ulong fs_len; /* File length in bytes 8 */ ushort fs_type; /* Type of file 12 */ ushort fs_nlink; /* # dir entries pointing to this 14 */ struct prot /* Protection on this file 16 */ fs_prot; uint fs_owner; /* ...creator's UID 32 */ uint fs_nblk; /* # extents 36 */ struct alloc /* ... tuples of extents 40 */ fs_blks[MAXEXT]; time_t fs_ctime, /* Create/mod timestamps 296 */ fs_mtime; char fs_pad[16]; /* Pad to 32-byte boundary */ /* ...this keeps fs_dirent's aligned 304 */ char fs_data[0]; /* Data starts here 320 */ }; The solution would be to move "char fs_data[0]" to the begin of the next block, whereever it is, in the current extent or in the next extent, or the first entry in the fs_file could be jump instruction to the start of the data, or modify the bootloader. The last option is not simple at all. I have to discuss it with the current developer of GRUB. So right now it is still possible to boot the whole VSTa system from a vstafs partition, that means the root filesystem is vstafs, the kernel and the modules are loaded from the vstafs partition. The bootloader still needs to be installed to ffs, ext2fs or fat. Sorry. Thomas J. Erdos From daemon Sat Jul 31 22:16:20 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA25830 for vsta-xplod; Sat, 31 Jul 1999 22:16:20 GMT Received: from mlwkwi-ns1.usxc.net (mlwkwi-cluster1.usxc.net [209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA25811 for ; Sat, 31 Jul 1999 22:16:16 GMT Received: from debian ([209.141.37.238]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA10B4; Sun, 1 Aug 1999 00:53:55 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.101) for ; Sun, 1 Aug 1999 01:00:34 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <37A39C31.BFC0992D@usxchange.net> Date: Sun, 01 Aug 1999 01:00:33 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gary Wong , vsta@zendo.com Subject: Re: Grub and the VSTa filesystem References: <9908010103.AA06375@brigantine.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Wong wrote: > Thomas J. Erdos writes: > >into the vstafs_read subroutine. So I tried with the newer version, but > >that didn't work either because the installation procedure of GRUB > >assumes that the second stage file on the harddrive begins at offset 0 > >of a sector. This is however not the case for vstafs. The begin of the > >file is somewhere at the end of the first block. Here an exempt from the > >headerfile: > > > >struct fs_file { > ... > > /* ...this keeps fs_dirent's aligned > >304 */ > > char fs_data[0]; /* Data starts here 320 */ > >}; > > > >The solution would be to move "char fs_data[0]" to the begin of the next > >block, whereever it is, in the current extent or in the next extent, or > >the first entry in the fs_file could be jump instruction to the start > >of the data, or modify the bootloader. The last option is not simple at > >all. I have to discuss it with the current developer of GRUB. > > I must be missing something, but can't you just add (512-320) zero bytes > to the start of the bootloader, so that the "real" data starts on the next > block boundary? > Yes. You are missing something. The GRUB consists of two parts, (sometimes three): -stage1, is loaded by the BIOS from the bootsector of a floppy or harddrive. (-stage1.5, is loaded by stage1 and contains only one filesystem unlike stage2) -stage2 is loaded by stage1. The question is now, how does the first stage bootloader, - which is only 512 bytes big, and does not know about filesystems- where to find stage2, that might be stored on a harddrive, as a file on a filesystem, is much bigger than 512 bytes, has the knowledge about the filesystem, and the blocks need not succeed each other. When the stage2 is installed, while reading the stage2 file, the bootloader stores the sectors which were read, in the stage1. When stage1 is loaded by the BIOS, it just loads the stored sectors, and voila stage2 is there whithout any information about the filesystem. This means also, that one shouldn't move stage2 from the original position, else the system won't boot again. > > Cheers, > Gary. > -- > Gary Wong, Department of Computer Science, University of Arizona > gary@cs.arizona.edu http://www.cs.arizona.edu/~gary/ Thomas J. Erdos From daemon Sun Aug 1 05:45:41 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA26382 for vsta-xplod; Sun, 1 Aug 1999 05:45:41 GMT Received: from herc.dbi.ro (herc.dbi.ro [193.230.134.76]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA26363 for ; Sun, 1 Aug 1999 05:45:35 GMT Received: by herc.dbi.ro with Internet Mail Service (5.5.1960.3) id <3SMW2GST>; Sun, 1 Aug 1999 15:50:18 +0200 Message-ID: <51BDB358AE5AD211997F00A024AB07A20DFE54@herc.dbi.ro> From: Mihai Ionescu To: "'vsta@zendo.com'" Subject: RE: Booting problem Date: Sun, 1 Aug 1999 15:50:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain > -----Original Message----- > From: Andy Valencia [SMTP:vandys@cisco.com] > Sent: Friday, July 30, 1999 9:36 PM > To: Mihai Ionescu > Cc: 'vsta@zendo.com' > Subject: Re: Booting problem > > [Mihai Ionescu writes:] > > >I have a big problem when I try to boot VSTA 1.61 I have 2 HDD, one > is > >master on the first controler and it is NTFS and the second one is > SLAVE > >on the SECOND controler. I putted the vsta directory on the second > >drive. The problem is that I could'n succed to convince VSTA to see > my > >second driver. > >module=/vsta/boot/wd d1:readp -- failed - No units found > >module=/vsta/boot/wd d1:readp irq=15 baseio=368 --failed - No units > >found > > Have you tried letting it find both drives? Also, see if you can get > it to > find just the first drives on each controller. You need to localize > which > part of the driver logic is failing. > > Andy > > Hi Andy, I tried letting it find the both drives and something very funny is happening. If I let only module=/vsta/boot/wd d0:readp, it fails saying that 'can't register name server disk/wd', but if I put something like: module=/vsta/boot/wd d0:readp module=/vsta/boot/wd d0:readp irq =15 (because if I don't put irq=15 it will fail with the message 'can't enable irq 14') it recognize in the both times the first drive (the one with the NTFS filesystem) and it is possible to connect to it: mount disk/wd /wd works just fine). If I put something like: module=/vsta/boot/wd d0:readp module=/vsta/boot/wd d1:readp irq =15 namer=disk/wd2 , boot process 7 will die and only the first harddisk will be available. The "best" I obtained was with the commands: module=/vsta/boot/wd d0:readp module=/vsta/boot/wd d1:1002:16:52 (these are the second hard disk parameters) irq=15 namer=disk/wd2 everything works, it recognize the both HDD, if I put something like: mount 1 /namer cd namer ls tty disk cd disk ls wd wd2 cd wd2 1024 but when I try mount 1024 /wd2 it fails saying 'can't connect to server'. but the first one (wd has the associated id 1025) mount 1025 /wd it works just fine. I tried to modify the sources of the WD server. For the first HDD, in the wd_main function it enters for the first time with the code M_ISR (I suppose it is called from the kernel), and, when the mount operation is called, it works fine. But for the second it does never enter with the code M_ISR (I think because it does not recognize hardware the hard disk). Do you have any ideas? I must add that I installed VSTA on two other computers on the first HDD and it worked just fine. Mihai From daemon Sun Aug 1 07:45:53 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA26480 for vsta-xplod; Sun, 1 Aug 1999 07:45:53 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA26474 for ; Sun, 1 Aug 1999 07:45:51 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA08148; Sun, 1 Aug 1999 08:54:36 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00330; Sun, 1 Aug 1999 08:53:37 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908011553.IAA00330@vandys-pc.vandys.cisco.com> To: "Thomas J. Erdos" cc: Gary Wong , vsta@zendo.com Subject: Re: Grub and the VSTa filesystem In-reply-to: Your message of "Sun, 01 Aug 1999 01:00:33 -0000." <37A39C31.BFC0992D@usxchange.net> Reply-to: vandys@cisco.com Date: Sun, 01 Aug 1999 08:53:37 -0700 From: Andy Valencia ["Thomas J. Erdos" writes:] >The question is now, how does the first stage bootloader, - which is only 512 >bytes big, and does not know about filesystems- where to find stage2, that >might be stored on a harddrive, as a file on a filesystem, is much bigger >than 512 bytes, has the knowledge about the filesystem, and the blocks need >not succeed each other. I suspect one could pad the stage2 with (512-320) bytes, and then have the bmap'ing of it ignore the first block. So the "real" stage2 contents would start at offset 0 in a 512 byte block, and that block would be the first one mapped in stage1's list of blocks. It'd be a little screwy, but it should do the job.... Andy Valencia From daemon Sun Aug 1 14:36:17 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA26860 for vsta-xplod; Sun, 1 Aug 1999 14:36:17 GMT Received: from mlwkwi-ns1.usxc.net (mlwkwi-cluster1.usxc.net [209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA26841 for ; Sun, 1 Aug 1999 14:36:13 GMT Received: from debian ([209.141.38.48]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA2208; Sun, 1 Aug 1999 17:45:26 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.101) for ; Sun, 1 Aug 1999 17:52:10 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <37A4894A.D96C6E5@usxchange.net> Date: Sun, 01 Aug 1999 17:52:10 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: vandys@cisco.com CC: Gary Wong , vsta@zendo.com Subject: Re: Grub and the VSTa filesystem References: <199908011553.IAA00330@vandys-pc.vandys.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Valencia wrote: > ["Thomas J. Erdos" writes:] > > >The question is now, how does the first stage bootloader, - which is only 512 > >bytes big, and does not know about filesystems- where to find stage2, that > >might be stored on a harddrive, as a file on a filesystem, is much bigger > >than 512 bytes, has the knowledge about the filesystem, and the blocks need > >not succeed each other. > > I suspect one could pad the stage2 with (512-320) bytes, and then have the > bmap'ing of it ignore the first block. So the "real" stage2 contents would > start at offset 0 in a 512 byte block, and that block would be the first one > mapped in stage1's list of blocks. It'd be a little screwy, but it should > do the job.... > > Andy Valencia I have to appologize to Gary, but when I read his e-mail it was too late, and I didn't really paid much attention what he said so I didn't explaind the real problem. Now Andy suggests the same thing. The problem with this solution is that the same subroutines in the stage2 read the menu.lst file , the kernel and the modules the same way. That means the first (512-320) bytes must be filled with comments for the menu.lst and the kernel and modules have to be modified and recompiled the same way like the stage2 file. Again - if I didn't explain it clearly- the same subroutines are used once at the installation to read in and mark the blocks used by the stage2 file on the filesystem and once at startup when the menu.lst, the kernel and the modules are read into the memory. If any questions left unanswered, I hope I can return an answere. Thomas J. Erdos From daemon Sun Aug 1 19:45:02 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA27250 for vsta-xplod; Sun, 1 Aug 1999 19:45:02 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA27241 for ; Sun, 1 Aug 1999 19:44:58 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA19626; Sun, 1 Aug 1999 20:53:43 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id UAA00328; Sun, 1 Aug 1999 20:52:45 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908020352.UAA00328@vandys-pc.vandys.cisco.com> To: "Thomas J. Erdos" cc: Gary Wong , vsta@zendo.com Subject: Re: Grub and the VSTa filesystem In-reply-to: Your message of "Sun, 01 Aug 1999 17:52:10 -0000." <37A4894A.D96C6E5@usxchange.net> Reply-to: vandys@cisco.com Date: Sun, 01 Aug 1999 20:52:44 -0700 From: Andy Valencia ["Thomas J. Erdos" writes:] >The problem with this solution is that the same subroutines in the stage2 read >the menu.lst file , the kernel and the modules the same way. That means the fi >rst >(512-320) bytes must be filled with comments for the menu.lst and the kernel a >nd >modules have to be modified and recompiled the same way like the stage2 file. >Again - if I didn't explain it clearly- the same subroutines are used once at >the >installation to read in and mark the blocks used by the stage2 file on the >filesystem and once at startup when the menu.lst, the kernel and the modules >are >read into the memory. >If any questions left unanswered, I hope I can return an answere. Ah, thanks for clarifying it! Well, as far as telling stage1 where to get blocks, what you describe is fine for loading stage2; the boot file will be at offset 0 in the first block. You'd have to make sure you never used this copy of stage2 for any other type of filesystem(!). If stage2's disk I/O is organized so that the filesystem specific code has to return the block # where the data starts, then yes, it does sound like a problem for the other files. But I was thrown off a bit by the fact that the fsys_table[] has a read_func vector, which the common read() routine in disk_io.c uses. But now I see that there's a NO_BLOCK_FILES which I guess is avoiding this code path? But I still don't see the block map connection in the fsys_table... my snapshot's pretty old, maybe that's the problem. But are you *sure* this is really a problem? I thought from your note on Saturday that your stage2 was accessing kernel and modules from vstafs? Anyway, yes, we'll have to pad all of'em the same way. I still maintain that it'd be screwy, but could be made to work. OTOH, two changes to vstafs would take care of the problem. The format of the file header could be changed so the 192 bytes of storage are first, followed by the inode-type information. This would handle the case of short files, like a short menu.lst. Second, vstafs could be changed so that files > 192 bytes would start at offset 0 in the next sector. So larger files would waste the 192 bytes, but that's only ~38% waste in the worst case, and drops to less than 5% waste by the time you reach just 4k. vstafs was coded at a time when disk space efficiency mattered a little bit, but since then $$$/MB makes this sort of small-scale optimization moot. This'll require rebuilding any existing vstafs. mkfs should be OK after a recompile. fsck will need a bit of work. The block allocator in the filesystem's where most of the action is. It'll also have to handle copying the "short file" contents upward to the new block when file size starts <= 192 and grows beyond it subsequently. Andy Valencia From daemon Sun Aug 1 19:45:56 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA27258 for vsta-xplod; Sun, 1 Aug 1999 19:45:56 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA27252 for ; Sun, 1 Aug 1999 19:45:53 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA19626; Sun, 1 Aug 1999 20:53:43 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id UAA00328; Sun, 1 Aug 1999 20:52:45 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908020352.UAA00328@vandys-pc.vandys.cisco.com> To: "Thomas J. Erdos" cc: Gary Wong , vsta@zendo.com Subject: Re: Grub and the VSTa filesystem In-reply-to: Your message of "Sun, 01 Aug 1999 17:52:10 -0000." <37A4894A.D96C6E5@usxchange.net> Reply-to: vandys@cisco.com Date: Sun, 01 Aug 1999 20:52:44 -0700 From: Andy Valencia ["Thomas J. Erdos" writes:] >The problem with this solution is that the same subroutines in the stage2 read >the menu.lst file , the kernel and the modules the same way. That means the fi >rst >(512-320) bytes must be filled with comments for the menu.lst and the kernel a >nd >modules have to be modified and recompiled the same way like the stage2 file. >Again - if I didn't explain it clearly- the same subroutines are used once at >the >installation to read in and mark the blocks used by the stage2 file on the >filesystem and once at startup when the menu.lst, the kernel and the modules >are >read into the memory. >If any questions left unanswered, I hope I can return an answere. Ah, thanks for clarifying it! Well, as far as telling stage1 where to get blocks, what you describe is fine for loading stage2; the boot file will be at offset 0 in the first block. You'd have to make sure you never used this copy of stage2 for any other type of filesystem(!). If stage2's disk I/O is organized so that the filesystem specific code has to return the block # where the data starts, then yes, it does sound like a problem for the other files. But I was thrown off a bit by the fact that the fsys_table[] has a read_func vector, which the common read() routine in disk_io.c uses. But now I see that there's a NO_BLOCK_FILES which I guess is avoiding this code path? But I still don't see the block map connection in the fsys_table... my snapshot's pretty old, maybe that's the problem. But are you *sure* this is really a problem? I thought from your note on Saturday that your stage2 was accessing kernel and modules from vstafs? Anyway, yes, we'll have to pad all of'em the same way. I still maintain that it'd be screwy, but could be made to work. OTOH, two changes to vstafs would take care of the problem. The format of the file header could be changed so the 192 bytes of storage are first, followed by the inode-type information. This would handle the case of short files, like a short menu.lst. Second, vstafs could be changed so that files > 192 bytes would start at offset 0 in the next sector. So larger files would waste the 192 bytes, but that's only ~38% waste in the worst case, and drops to less than 5% waste by the time you reach just 4k. vstafs was coded at a time when disk space efficiency mattered a little bit, but since then $$$/MB makes this sort of small-scale optimization moot. This'll require rebuilding any existing vstafs. mkfs should be OK after a recompile. fsck will need a bit of work. The block allocator in the filesystem's where most of the action is. It'll also have to handle copying the "short file" contents upward to the new block when file size starts <= 192 and grows beyond it subsequently. Andy Valencia From daemon Thu Aug 5 17:26:55 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA03592 for vsta-xplod; Thu, 5 Aug 1999 17:26:55 GMT Received: from mlwkwi-ns1.usxc.net (mlwkwi-cluster1.usxc.net [209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA03573 for ; Thu, 5 Aug 1999 17:26:50 GMT Received: from debian ([209.141.37.54]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA423E for ; Thu, 5 Aug 1999 20:36:07 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.101) for ; Thu, 5 Aug 1999 20:43:16 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <37A9F764.D5E33206@usxchange.net> Date: Thu, 05 Aug 1999 20:43:16 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Re: Grub and the VSTa filesystem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I sent this e-mail already once, but it seams it didn't arrived. So I try it again. This was my response. Andy Valencia wrote: > Ah, thanks for clarifying it! > > Well, as far as telling stage1 where to get blocks, what you describe is > fine for loading stage2; the boot file will be at offset 0 in the first > block. You'd have to make sure you never used this copy of stage2 for any > other type of filesystem(!). > > If stage2's disk I/O is organized so that the filesystem specific code has > to return the block # where the data starts, then yes, it does sound like a > problem for the other files. But I was thrown off a bit by the fact that > the fsys_table[] has a read_func vector, which the common read() routine in > disk_io.c uses. But now I see that there's a NO_BLOCK_FILES which I guess > is avoiding this code path? But I still don't see the block map connection > in the fsys_table... my snapshot's pretty old, maybe that's the problem. > The current snapshot also uses the block file method for reading files, but only the fatfs makes use of it. Every other filesystem (including vstafs) has its own **fs_read func vector. Check out the filesys.h header and look for struct fsys_entry fsys_table[]. > > But are you *sure* this is really a problem? I thought from your note on > Saturday that your stage2 was accessing kernel and modules from vstafs? > That didn't change yet. It is still true. Let's look to it again. The first step to install GRUB is to dump the stage1 and stage2 with dd to a floppy disk. The second step is to make a copy of stage2 into the (hdX,Y)/boot/grub directory. When the computer boots from the floppy, it loads first stage1, then stage1 loads stage2 also from the floppy. Now we want to install stage1 to the MBR of the harddrive, and we want this stage1 to use the stage2 we copied to (hdX,Y)/boot/grub. So we invoke the install command, which calls read("(hdX,Y)/boot/grub/stage2"). the read subroutine calls vstafs_read(addr,len). Vstafs_read() finds from the fs_file structure where the stage2 begins and reads it whith devread(sector,offset,len,addr). Each time devread is called, a function debug_fs_func is called which makes record for stage1 about the start sector and the length of the block which is read by devread, but not about the offset. If it would save the offset too, we wouldn't have any problems. This way stage1 knows where and how to find stage2. When next time the computer boots, the BIOS loads stage1 from the MBR. stage1 then loads according to its records the stage2. First GRUB tries to find the menu.lst file. Read("/boot/grub/menu.lst") is invoked which calls vstafs_read, which calls devread. But debug_fs_func is not used in this case, because the call didn't come from the install command. Thus we can use the filesystem support. The offset part in devread is used actually for reading in the header of the kernel, for testing the type of it. It tests if it is multiboot compliant, or piggy-back, or ... . Depending on what it is, the stage2 part of the bootloader uses the correct method to load the kernel. > > Anyway, yes, we'll have to pad all of'em the same way. I still maintain > that it'd be screwy, but could be made to work. > > OTOH, two changes to vstafs would take care of the problem. The format of > the file header could be changed so the 192 bytes of storage are first, > followed by the inode-type information. This would handle the case of short > files, like a short menu.lst. Second, vstafs could be changed so that files > > 192 bytes would start at offset 0 in the next sector. So larger files > would waste the 192 bytes, but that's only ~38% waste in the worst case, and > drops to less than 5% waste by the time you reach just 4k. vstafs was coded > at a time when disk space efficiency mattered a little bit, but since then > $$$/MB makes this sort of small-scale optimization moot. > I had an idea for these 192 bytes. MS-DOS or may be better is to say Windows gets its information about a file from the file extension. These 192 bytes could do a similar but extended job. Let's say we have a graphical environment, which could save informations in this area. Let's take a sound file as an example. It could store the type of the file (sound-file), the format of the sound file (.au,.wav,...), which application can open it (player, modifier, ...) and so on. If the user selects the file and it is executable, these informations would start the correct application. Any other suggestions? Thomas J. Erdos From daemon Sun Aug 8 16:13:44 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA10146 for vsta-xplod; Sun, 8 Aug 1999 16:13:44 GMT Received: from ns1.mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id QAA10127 for ; Sun, 8 Aug 1999 16:13:38 GMT Received: from (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with ESMTP id UAA00198; Sun, 8 Aug 1999 20:22:44 -0400 Message-id: Date: Sun, 08 Aug 1999 20:17:55 -0400 Subject: Re: Current state of Vsta? To: mdingler@mindless.com Cc: vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit mdingler@mindless.com writes: >What's going on in the Vsta world? The web-site is >pretty old and if I remember correctly, the majordomo >said that development has stalled or something. > >So, what's planned, on what projects do you work? >And (*shock*), may I help? ;) > >...Michael... I see no one's answered, so I'll give it a try... I think actually the hardest thing to do is to decide what to do, in this case. :) Typically in a free operating system project a lot of ork is done on porting various free unix-ish software to the new OS. Of course we do have GCC and other utilities ported to VSTa. But I don't think we want to build the whole OS that way. For example, it was pretty much decided that we don't want X ported for the GUI, because it doesn't fit well with the VSTa micro-ish philosophy, and besides that, other free OS's like FreeBSD and Linux run it better. In other words, we don't want to have the architecture compete directly with what's already been done. POSIX compatibility is fine (and very helpful, too), but I think VSTa is looking for something new. VSTa is definitely in need of a good SVGA graphics module that could handle stuff like bitmaps, clipping, etc. The only catch is it would have to run well as a user process. Perhaps a combination of a shared library and a process would be best. The library could handle things like off-screen bitmaps and other tasks that can run independently in each process. When it comes time to actually display the graphics, the library would send a request out to the video process, which would serialize all of the requests and talk to the video hardware. For upper level GUI stuff, I really don't know. Andy has talked about running a language called Squeak to handle some of the higher-level stuff. It sounds interesting. I think we're really in the market for something new here. I'm imagining something that can go along with VSTa's object-orientedness. I'm not talking about an object-oriented GUI that means we define a C++ class called Button or some nonsense. The objects I'm referring to here are the objects of the system; what the user is trying to interact with. It's a different paradigm than most user interfaces use. A VSTa process, I would imagine, would interface with its GUI in a manner that's different from the way a Windows app interacts with the Windows GUI. Instead of saying something like "edit field #6 goes here", it would say "this object has these attributes and it works with these objects like this." The GUI process would work with the objects the user is using and what the user is trying to do, and try to present it in a meaningful way. It's a tall order, I know. But I'd really hate to see something like COM/OLE that's a decently designed standard, technically, but which turns out to be so utterly useless in practical use it's not even funny. Or like QNX: a really slick lightweight OS that can pack a convincing Windows 95 clone on a 1.44mb floppy, but doesn't go beyond Windows' functionality. In terms of the VSTa kernel: there are a couple of bugs to fix but they aren't too serious. The biggest hole I see in the VSTa message system--here's something to think about--is manifested in the telnetd program in the KA9Q package. Here's what happens: when someone telnets in, telnetd gets the connection and prepares to run login. But it can't hand the raw TCP connection to login, because something has to be there to run the telnet protocol. So instead it forks off and stays behind to run a message loop that interprets the protocol. Then the original process execs into "login //####" where #### is the port number of the message loop that will run the protocol. The problem is that that number is a public server number. Any process can open that "//####" and connect to telnetd. A user could write a process that hides in the background poking around at port numbers, trying to run a fake login process that will record passwords. Etc. The traditional ACL way of solving this, of course, is to require that the client who opens "//####" has sys privileges, or whatever. That certainly would work, but it doesn't sit well with me for two reasons: first, it's not really the VSTa philsophy. Things that usually would require administrator privileges in other OS's (for example, running a file system) can be done by ordinary users in VSTa. There's nothing about wanting to use a message loop to perform a private function that requires superuser privileges. Second, this situation is bound to crop up again, especially as process becomes more modularized. A method for doing private-mode server invocations securely seems appropriate. Even with the ACL pseudo-solution, it won't work in all cases: you couldn't prevent two processes with the same ACL credentials from interfering with each other. From daemon Mon Aug 9 06:45:19 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA11158 for vsta-xplod; Mon, 9 Aug 1999 06:45:19 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA11152 for ; Mon, 9 Aug 1999 06:45:16 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA04812; Mon, 9 Aug 1999 07:54:24 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00417; Mon, 9 Aug 1999 07:53:35 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908091453.HAA00417@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: mdingler@mindless.com, vsta@zendo.com Subject: Re: Current state of Vsta? In-reply-to: Your message of "Sun, 08 Aug 1999 20:17:55 EDT." Reply-to: vandys@cisco.com Date: Mon, 09 Aug 1999 07:53:35 -0700 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I see no one's answered, so I'll give it a try... I didn't answer because each time we get a query like this and I answer, the person goes away. So I thought I'd let somebody else try "first contact". :-> >VSTa is definitely in need of a good SVGA graphics module that could >handle stuff like bitmaps, clipping, etc. Also blit! Especially as connected to the bitblit support of the various graphics chips. >The problem is that that number is a public server number. Any process >can open that "//####" and connect to telnetd. A user could write a >process that hides in the background poking around at port numbers, >trying to run a fake login process that will record passwords. Etc. Since all connections are authenticated, I don't see the problem. You always know the identity of the connecting process. Even if you didn't want to depend on that, you could generate a 128-bit number which the connector had to supply before their connection would be accepted and used. >The traditional ACL way of solving this, of course, is to require that >the client who opens "//####" has sys privileges, or whatever. That >certainly would work, but it doesn't sit well with me for two reasons: >first, it's not really the VSTa philsophy. Right. Instead, VSTa tries to preserve the identity (i.e., mechanism) while leaving policy to the server. I think there's enough mechanism available to solve this problem. Andy Valencia From daemon Mon Aug 9 11:08:04 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA11468 for vsta-xplod; Mon, 9 Aug 1999 11:08:04 GMT Received: from ns1.mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id LAA11449 for ; Mon, 9 Aug 1999 11:07:57 GMT Received: from (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with ESMTP id PAA12823; Mon, 9 Aug 1999 15:16:56 -0400 Message-id: Date: Mon, 09 Aug 1999 15:12:05 -0400 Subject: Re(2): Current state of Vsta? To: vandys@cisco.com Cc: mdingler@mindless.com, vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit vandys@cisco.com writes: >Since all connections are authenticated, I don't see the problem. You >always know the identity of the connecting process. Is it possible to know the pid of a process trying to connect? That would be ideal. I seem to remember having to have the kernel search through all the procs to find whose port it is. >Even if you didn't want to depend on that, you could generate a 128-bit >number which the connector had to supply before their connection would be >accepted and used. Yeah... (sigh) That would work, too. >Right. Instead, VSTa tries to preserve the identity (i.e., mechanism) >while leaving policy to the server. I think there's enough mechanism >available to solve this problem. There is, but I'm suggesting there might be a whole different way of thinking about how servers are initiated and used. I was playing a while ago with a modification to the library and dos that would let you do things like: mount //disk/fd:fd0!dos /floppy The exclamation point here indicates that the next path element is the name of a server that will operate on the path up to that point. So it's really equivalent to saying: dos -d //disk/fd:fd0 -n fs/dosfloppy & mount fs/dosfloppy /floppy In fact I originally devised it as a shorthand to doing that sort of thing. But I realized that in this case there really is no need for a global name at all. The only legitimate place that should have a connection to that instance of dos is in my mount table. I can fork() and clone() it to whoever needs it from there. So I made dos so it skipped its normal authentication policies, and also added reference counts so that it would automatically exit. Then I realized you could do things like: mount //fs/root:eric/mydiskimage!dos /image as an ordinary user. The role of dos is different now. It's no longer a system-level server, like wd, but more like a user-level utility, like tar. It's simply performing a computational task on a file that the user has access to. If the user has write access to that image file, the user should be able to make changes to it. The user is simply using dos as a utility function, an alternative to using the hex editor. So then I had to make dos skip ALL of its authentication and policies, including access stuff. If the client said write, then dos would try to write. Because dos has the same privileges as the user, though, dos couldn't write the image file if the user couldn't. The VSTa mechanism for identifying and authenticating users works great, I think, for most system-wide, system-level services. You can, I'm sure, get VSTa to do the things like the telnetd and the dos thing either absolutely (checking the pid) or practically (generating a 128-bit random number.) It's just an area of VSTa that hasn't been developed much, in terms of convention even if no new code needs to be written. Just something to think about... From daemon Tue Aug 10 06:03:16 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id GAA12898 for vsta-xplod; Tue, 10 Aug 1999 06:03:16 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id GAA12892 for ; Tue, 10 Aug 1999 06:03:13 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA09184; Tue, 10 Aug 1999 07:12:24 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00403; Tue, 10 Aug 1999 07:12:21 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908101412.HAA00403@vandys-pc.vandys.cisco.com> To: Eric Dines cc: "VSTa Mail list (E-mail)" Subject: Re: Where can I get the pre-built binaries for ka9q please? cheers Eric In-reply-to: Your message of "Tue, 10 Aug 1999 12:23:57 +0800." Reply-to: vandys@cisco.com Date: Tue, 10 Aug 1999 07:12:20 -0700 From: Andy Valencia [Eric Dines writes:] >Where can I get the pre-built binaries for ka9q please? There might be a "net" executable in either vsta/src/srv/ka9q or right in /vsta/bin. Otherwise send me private E-mail and I can put one on FTP for pickup. Andy Valencia From daemon Thu Aug 12 15:24:44 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA16506 for vsta-xplod; Thu, 12 Aug 1999 15:24:44 GMT Received: from bilby.wn.com.au (bilby.wn.com.au [203.10.1.17]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id PAA16487 for ; Thu, 12 Aug 1999 15:24:36 GMT Received: from server.gbb.com.au (server.gbb.com.au [203.13.74.202]) by bilby.wn.com.au (NTMail 3.03.0018/1.aadu) with ESMTP id ta764601 for ; Fri, 13 Aug 1999 07:34:43 +0800 Received: by INTERNETSERVER with Internet Mail Service (5.5.2232.9) id ; Fri, 13 Aug 1999 07:43:10 +0800 Message-ID: From: Eric Dines To: "VSTa Mail list (E-mail)" Subject: gcc problem Date: Fri, 13 Aug 1999 07:43:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Under 1.5.2 I cannot seem to be able to compile anything with gcc. I get the message gcc: installation problem, cannot exec cpp no entry gcc: Program cpp got fatal signal 127 perm $ Can anyone advise please? thanks Eric esd@deakin.edu.au From daemon Fri Aug 13 08:28:59 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA17584 for vsta-xplod; Fri, 13 Aug 1999 08:28:59 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA17578 for ; Fri, 13 Aug 1999 08:28:54 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA11623; Fri, 13 Aug 1999 09:38:14 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00638; Fri, 13 Aug 1999 09:37:41 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908131637.JAA00638@vandys-pc.vandys.cisco.com> To: Eric Dines cc: "VSTa Mail list (E-mail)" Subject: Re: gcc problem In-reply-to: Your message of "Fri, 13 Aug 1999 07:43:04 +0800." Reply-to: vandys@cisco.com Date: Fri, 13 Aug 1999 09:37:41 -0700 From: Andy Valencia [Eric Dines writes:] >Under 1.5.2 I cannot seem to be able to compile anything with gcc. >I get the message >gcc: installation problem, cannot exec cpp no entry >gcc: Program cpp got fatal signal 127 What's your mount table look like at this point? Can you run cpp manually? It should be in /vsta/bin/cpp. Also, somewhere back in the mists of time there was a bug in the old gcc executable where if you had another mount point of /v, /vs, /vst, or /vsta, then gcc could fail to lookup its path correctly. It was a bug in libc, but gcc had been statically linked back then. Some time later (1.6, if my change logs are correct) I rebuilt gcc properly and it now uses shlib's like everything else--and this problem went away. Andy From daemon Sun Aug 15 21:17:01 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA23199 for vsta-xplod; Sun, 15 Aug 1999 21:17:01 GMT Received: from bilby.wn.com.au ([203.10.1.17]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id VAA23180 for ; Sun, 15 Aug 1999 21:16:55 GMT Received: from server.gbb.com.au (server.gbb.com.au [203.13.74.202]) by bilby.wn.com.au (NTMail 3.03.0018/1.aadu) with ESMTP id la770937 for ; Mon, 16 Aug 1999 13:27:16 +0800 Received: by INTERNETSERVER with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 13:35:37 +0800 Message-ID: From: Eric Dines To: "VSTa Mail list (E-mail)" Subject: What is required to build a user server? Date: Mon, 16 Aug 1999 13:35:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain What specifications are required to build a user server? eg. What would be required to build a server that printed "Hello World" How is the server invoked? cheers Eric esd@deakin.edu.au From daemon Wed Aug 18 18:32:11 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA27356 for vsta-xplod; Wed, 18 Aug 1999 18:32:11 GMT Received: from mail.mcps.k12.md.us ([205.222.5.117]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA27337 for ; Wed, 18 Aug 1999 18:32:05 GMT Received: from fcgateway.mcps.k12.md.us (fcgateway.mcps.k12.md.us [205.222.5.94]) by mail.mcps.k12.md.us (8.9.3/8.9.3) with ESMTP id WAA03022; Wed, 18 Aug 1999 22:40:42 -0400 Message-id: Date: Wed, 18 Aug 1999 22:36:12 -0400 Subject: Re: What is required to build a user server? To: esd@gbb.com.au Cc: vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit esd@gbb.com.au writes: >What specifications are required to build a user server? > >eg. What would be required to build a server that printed "Hello World" > >How is the server invoked? > >cheers > >Eric In VSTa, a server is a process that creates one or more message ports and presumably receives on them every once in a while. Other than that, they're no different from any other process. They run as user code and can make any system calls that other processes can. They can be clients to other servers as well as being a server itself. For example, if you run vstafs on your hard disk, then vstafs is a client to wd and server to sh, ls, gcc, etc, whatever process is using that filesystem. In this way the process has two different "faces" to the operating system. Any process can behave this way. (What would you call 'em, servents? Or cliers?) Servers are also invoked just as you would other processes. If you decide you need to use the floppy drive in the middle of a session, just do: # fd & Don't forget the &, as otherwise you connect your terminal to fd, and fd doesn't interact on stdin or stdout. There's nothing saying it couldn't, however, as a matter of convention, servers run unattended and don't usually expect to talk to a human user. To be considered a server, a process creates a message port using the syscall msg_port(). There are basically two ways to call it: handle = msg_port(###, NULL); handle = msg_port(NULL, &portname); You would use the first syntax if you wanted to establish the server on a specific global port name, which you would specify as the first parameter. There are a couple of officially assigned port names in the VSTa headers. You can, of course, pick any number you like, but msg_port() will fail if that number is already taken. Mostly likely you'll want to use the second form. In this case, the system will pick a port number for you and store it in the variable whose address you pass in the second parameter. This is usually what you want. Then you can give that port number to other processes. That's the number they'll use to connect to your server. The VSTa standard service namer allows servers to associate their port numbers with text identifiers in a global, hierarchical namespace. So, for instance, programs can use //fs/root:a/b/c instead of //1025:a/b/c. The library function namer_register() can do the grudge work for you. Lookup helper functions are also included in the library. The value that's returned by msg_port is your process's private handle on to that message port. Don't pass this value to other processes; it has no meaning in their context. It is not the same as the global port name. Note that you can create multiple ports if you want to. The limit is defined in the kernel; I think it is set to 4 currently. Most servers will only need one message port. To handle messages that come in from clients, you would use the msg_receive syscall: struct msg m; x = msg_receive(handle, &m); This is a blocking call that waits for the next message to come in from any client (or potential client.) The message structure has the following fields: m_sender : an opaque number used to identify the client m_op : this is the operation code. It's either a number that the client gave in its msg_send() call, or a kernel-generated (and trusted) M_ system message. See below. m_arg : a single argument to go with the operation. m_arg1 : another argument for the operation. (Not usually used.) m_nseg : The number of data buffers that the client has sent. Usually only one, but clients can send up to four buffers in a single call. Servers should handle clients who send more than one buffer at a time. (There are library functions to help with this.) m_seg : An array of buffer definitions that the client sent. m_buf : A quick way to reference the first buffer. m_buflen : A quick way to reference the length of the first buffer. If msg_receive() returns a negative number, the receive operation was interrupted by an event while waiting for a client. Bit 31 of m_op, known as M_READ, has a special meaning. It is used to indicate the direction of data flow between the client and server. If clear, it means that the client is sending buffers to the server. If set, it means that the server is sending buffers to the client. It's the client's responsibility to get the value of M_READ right. The server will usually mask it out. If a client asks for FS_READ instead of FS_READ|M_READ, for example, the server will work just fine; however, the kernel will never transfer the buffers to the client. Once a msg_receive() has returned successfully, the client will be blocked waiting for some kind of response from the server. In general, the two possible responses (but see below) are msg_reply(), indicating success (you can pass an integer back, as the return value for msg_send()), and msg_err(), with which you can pass back an error string. Message operation codes that are at or below the predefined constant M_RESVD are reserved for the kernel; ordinary clients can't deliberately send them with msg_send(). The most important ones are the following: M_CONNECT : a client is trying to connect. The m_buf contains a trusted array of the user's permissions. In this case, you don't use msg_reply() to indicate success. You rather use msg_accept() instead. Errors are still reported with msg_err(). M_DISCONNECT: a client has disconnected. This message is a bit different in that it is asynchronous: no reply is necessary; the client is already gone. M_DUP : a client has requested a clone of this connection instance. Essentially, the client becomes two initially identical clients, each independent from then on. This is necessary for fork() as well as the clone() syscall. In general, servers should let their clients clone themselves. M_ABORT : the client is no longer requesting the operation. Happens when the client is interrupted (by event, for example) while they're waiting for the server to respond. You'll likely only need to do any processing for this message if you poll for messages in between the msg_receive() and the msg_reply()/msg_err() of a client operation (i.e., you're asynchronous). In that case, you need to clear the asynchronous request and msg_reply() to the M_ABORT. If you're not asynchronous, too late; you've already replied and your message has been thrown out. In this case, just msg_reply() to the M_ABORT. M_ISR : this message is sent by the kernel when a hardware interrupt has occurred that your server has requested. You must have enabled the IRQ in order to receive this message. Messages above M_RESVD are user messages. The most common ones are the filesystem messages: All devices: FS_STAT FS_WSTAT - these handle reading and writing of attributes Character special: (pipes, console, serial, TCP, etc.) above plus: FS_READ FS_WRITE Files: all above plus FS_SEEK FS_ABSREAD FS_ABSWRITE - optional, these two combine a seek and r/w operation Directories/file systems: all above except FS_WRITE and FS_ABSWRITE plus FS_OPEN FS_RENAME FS_REMOVE In the case of FS_OPEN, the client descends a level into the hierarchy. The client is then "inside" the file they opened. The other two manipulate the current directory, but don't change the client. FS_READ on a directory reads a list of names of items that may be FS_OPEN'ed. Any other messages can be defined; the messages numbers are not interpreted by the kernel at all. I would encourage the creation of additional classes of message operations if a server has actions that do not fit well into the already existing message codes. (Some VSTa servers, such as sema, insist on using the FS_ message codes even though they don't really make sense in what the server has to do.) Hopefully this will get you started. Also don't be afraid to look at the source of some of the VSTa servers. They're well commented. A couple of other things: message ports exist in a process-wide context; they aren't associated with any particular thread. Any thread may receive messages on any port. If two threads msg_receive on the same port at the same time, one will get the next message, the other will get the message after that. However, the most common use of threads in servers is to have one run the message loop while the others do client operations. From daemon Thu Aug 19 10:40:51 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA28316 for vsta-xplod; Thu, 19 Aug 1999 10:40:51 GMT Received: from mlwkwi-ns1.usxc.net ([209.141.41.11]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA28297 for ; Thu, 19 Aug 1999 10:40:45 GMT Received: from usxchange.net ([209.141.37.202]) by mlwkwi-ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA7095 for ; Thu, 19 Aug 1999 10:00:06 -0500 Message-ID: <37BC1D05.C19F262C@usxchange.net> Date: Thu, 19 Aug 1999 10:04:38 -0500 From: "Thomas J. Erdos" Reply-To: erdost@usxchange.net X-Mailer: Mozilla 4.04 [en]C--USXC-1.0 (Win95; U) MIME-Version: 1.0 To: vsta@zendo.com Subject: Re: What is required to build a user server? References: Content-Type: multipart/mixed; boundary="------------190DDE0CC7E6E7694FD6A7F8" This is a multi-part message in MIME format. --------------190DDE0CC7E6E7694FD6A7F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Jacobs wrote: > > Content cut > This is a great description. Is this going to be added to the documentation? I would yet add a short example. Let it be the "Hello World" server, that could serve as a skeleton for new servers. Thomas J. Erdos --------------190DDE0CC7E6E7694FD6A7F8 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Thomas J. Erdos Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Thomas J. Erdos n: Erdos;Thomas J. org: A.C.E., Inc. adr: 2231 Holmgren Way, Ste. B;;;Green Bay;WI;54304;U.S.A. email;internet: erdost@usxchange.net title: Software Engineer tel;work: (920) 490-0821 tel;fax: (920) 490-0823 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------190DDE0CC7E6E7694FD6A7F8-- From daemon Fri Aug 20 19:51:29 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA00432 for vsta-xplod; Fri, 20 Aug 1999 19:51:29 GMT Received: from bilby.wn.com.au ([203.10.1.17]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id TAA00413 for ; Fri, 20 Aug 1999 19:51:19 GMT Received: from server.gbb.com.au (server.gbb.com.au [203.13.74.202]) by bilby.wn.com.au (NTMail 3.03.0018/1.aadu) with ESMTP id ba786579 for ; Sat, 21 Aug 1999 12:01:27 +0800 Received: by INTERNETSERVER with Internet Mail Service (5.5.2232.9) id ; Sat, 21 Aug 1999 12:10:22 +0800 Message-ID: From: Eric Dines To: "VSTa Mail list (E-mail)" Subject: Several problems Date: Sat, 21 Aug 1999 12:10:16 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain I am being driven to distraction, for some wierd reason I cannot get gcc to work properly. eg: $gcc hello.c -o hello.o on one machine cpp fails, on another machine ld fails. The same installation, gunzipped off ftp site. Can anyone give me the early version of DJGPP that produces the required a.out files? Second Trauma...Editors ====================== vi doesn't seem too happy. It print on the screen OOPS OOPSterminal capaility cm required OOPS OOPS OOPS vi accepts input ok, and the commands seem to work, its just that it prints OOPS all over the screen. ======================= ed is fine?! ======================= emacs Environment variable TERM not defined perm. I don't know how to fix this. Third....Network ======================= My ne2000 lights up from running ne as follows in inittab bg:/vsta/boot/ne 0x300,5 but even when I call "net" from the $ prompt, I can't ping in or out (or do anything else). Running net from inittab means net is up and running before ne is functioning. What should I have in the autoexec.net file? I have tried a raft of combinations. Is there a detailed how-to on networking...I have searched the archives, but need more info. please? Fourth...runrc ======================= runrc is not functioning, :not found :not found exit: Illegal number: 0 Is there any reason for this? From the source code, it would appear that this could be causing many of my problems. Both /vsta/bin/sh and /vsta/etc/rc appear to be there, but I wondering if sh is problematic? cheers Eric esd@deakin.edu.au From daemon Fri Aug 20 21:28:55 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA00510 for vsta-xplod; Fri, 20 Aug 1999 21:28:55 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id VAA00504 for ; Fri, 20 Aug 1999 21:28:53 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA00940; Fri, 20 Aug 1999 22:38:34 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id WAA01893; Fri, 20 Aug 1999 22:38:32 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908210538.WAA01893@vandys-pc.vandys.cisco.com> To: Eric Dines cc: "VSTa Mail list (E-mail)" Subject: Re: Several problems In-reply-to: Your message of "Sat, 21 Aug 1999 12:10:16 +0800." Reply-to: vandys@cisco.com Date: Fri, 20 Aug 1999 22:38:31 -0700 From: Andy Valencia [Eric Dines writes:] >I am being driven to distraction, for some wierd reason I cannot get gcc to >work properly. >... Classic sign of your archiver converting files to DOS (\r\n) line termination. Try and re-install using an archiver which doesn't "help" you in this way, and things will probably go better. Andy From daemon Sun Aug 22 18:02:57 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA05499 for vsta-xplod; Sun, 22 Aug 1999 18:02:57 GMT Received: from bilby.wn.com.au (bilby.wn.com.au [203.10.1.17]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id SAA05480 for ; Sun, 22 Aug 1999 18:02:50 GMT Received: from server.gbb.com.au (server.gbb.com.au [203.13.74.202]) by bilby.wn.com.au (NTMail 3.03.0018/1.aadu) with ESMTP id ca789466 for ; Mon, 23 Aug 1999 10:13:01 +0800 Received: by INTERNETSERVER with Internet Mail Service (5.5.2232.9) id ; Mon, 23 Aug 1999 10:22:24 +0800 Message-ID: From: Eric Dines To: "VSTa Mail list (E-mail)" Subject: FW: Several problems Date: Mon, 23 Aug 1999 10:22:23 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain > >I am being driven to distraction, for some wierd reason I cannot get gcc > to > >work properly. > >... > >Classic sign of your archiver converting files to DOS (\r\n) line >termination. Try and re-install using an archiver which doesn't "help" you >in this way, and things will probably go better. >Andy YEP! you're dead right. I thought I had untarred them under Linux, but obviously I must have used winzip? thanks heaps eric From daemon Mon Aug 23 12:24:26 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA06628 for vsta-xplod; Mon, 23 Aug 1999 12:24:26 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA06602 for ; Mon, 23 Aug 1999 12:23:05 GMT Received: from vandys-pc.vandys.cisco.com (cchan-4.cisco.com [171.69.228.69]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA03244; Mon, 23 Aug 1999 13:32:51 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id NAA01696; Mon, 23 Aug 1999 13:31:56 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199908232031.NAA01696@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: esd@gbb.com.au, vsta@zendo.com Subject: Re: What is required to build a user server? In-reply-to: Your message of "Wed, 18 Aug 1999 22:36:12 EDT." Reply-to: vandys@cisco.com Date: Mon, 23 Aug 1999 13:31:56 -0700 From: Andy Valencia >In VSTa, a server is a process that creates one or more message ports >and presumably receives on them every once in a while. >... Awesome stuff. I'm going to format this and put it in the docs section of the WWW site. >To be considered a server, a process creates a message port using the >syscall msg_port(). There are basically two ways to call it: > > handle = msg_port(###, NULL); > > handle = msg_port(NULL, &portname); I think the former argument is an integer, so "msg_port(0, &portname)" is probably more correct. NULL happens to be 0 in current VSTa ports, but consider that (void *)0 is also a valid value, and that would choke the msg_port prototype, which expects an int (or rather, port_name, I think). > M_ABORT : the client is no longer requesting the operation. > Happens when the client is interrupted (by event, > for example) while they're waiting for the server > to respond. You'll likely only need to do any > processing for this message if you poll for > messages in between the msg_receive() and the > msg_reply()/msg_err() of a client operation (i.e., > you're asynchronous). What you write is quite correct, but I think I'll to mention that this is very common in servers structured as event loops. >Messages above M_RESVD are user messages. The most common ones are the >filesystem messages: I think I'll mention the explicit header files (sys/msg.h, sys/fs.h). Andy From daemon Thu Sep 16 14:13:59 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA04093 for vsta-xplod; Thu, 16 Sep 1999 14:13:59 GMT Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA04074 for ; Thu, 16 Sep 1999 14:13:55 GMT From: werts@us.ibm.com Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.132.205]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA206460; Thu, 16 Sep 1999 18:54:14 -0400 Received: from d53mta03h.boulder.ibm.com (d53mta03h.boulder.ibm.com [9.99.142.3]) by westrelay02.boulder.ibm.com (8.8.8m2/NCO v2.05) with SMTP id QAA238510; Thu, 16 Sep 1999 16:54:43 -0600 Received: by d53mta03h.boulder.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 872567EE.007DDA74 ; Thu, 16 Sep 1999 16:54:39 -0600 X-Lotus-FromDomain: IBMUS To: vsta@zendo.com cc: werts@jps.net Message-ID: <872567EE.007DD951.00@d53mta03h.boulder.ibm.com> Date: Thu, 16 Sep 1999 15:48:23 -0700 Subject: Development alternatives worth exploring? Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable I really admire what has been attempted in VSTa. It would be even better if it was a viable applications platform, so let me pose a speculative question. Could more progress be made towards a usable QNX/Plan 9 hybrid by partnering with another project? Specifically I have in mind the L4/Fiasco project. They have 1- a running system which seems at least superficially similar to QNX, 2 - they have a Linux port with X support (although X support may not be stable) and 3 - their project seems to still have some life left in it. The URL for their project is http://os.inf.tu-dresden.de/fiasco/. [I do not consider hosting Linux/X as the ultimate goal, but it is a useful intermediate goal.] Porting the Plan 9 features from VSTa to the new system would surely be a non-trivial effort but would result in a new code base with a larger group of contributors working on it. The joining of resources might just be enough to make the resulting system a viable, open source, microkernel based applications platform. Or as another (probably less feasible) alternative could the salient features of VSTa be ported into FreeBSD (the Linux developers appear to be downright hostile to microkernels) allowing it to evolve in new directions? Thanks for your time. Regards, Michael Werts ---------------------------------------------------------- Michael Werts E-mail: werts@us.ibm.com Voice: 408.463.2169 (T/L 543.2169) Fax: 408.463.2633 (T/L 543.2633) IBM Corporation =B7 Santa Teresa Lab 555 Bailey Avenue =B7 San Jose =B7 California =B7 95141 ---------------------------------------------------------- = From daemon Thu Sep 16 19:45:42 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA04436 for vsta-xplod; Thu, 16 Sep 1999 19:45:42 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA04430 for ; Thu, 16 Sep 1999 19:45:40 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA14928; Thu, 16 Sep 1999 21:26:01 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id VAA00291; Thu, 16 Sep 1999 21:26:00 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199909170426.VAA00291@vandys-pc.vandys.cisco.com> To: "Chris McNett" cc: vsta@zendo.com Subject: Re: Removal In-reply-to: Your message of "Thu, 16 Sep 1999 19:32:43 CDT." Reply-to: vandys@cisco.com Date: Thu, 16 Sep 1999 21:26:00 -0700 From: Andy Valencia ["Chris McNett" writes:] >How do I remove myself from this list? In general, for any list in God's creation, you send to -request@ for the @ list. Usually "unsubscribe" all by itself in the body of the message will suffice. So sending this note to vsta-request@zendo.com would have achieved the desired effect. In this case, I've manually removed you from the list. Andy Valencia From daemon Fri Sep 24 19:36:14 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA18608 for vsta-xplod; Fri, 24 Sep 1999 19:36:14 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id TAA18598; Fri, 24 Sep 1999 19:36:09 GMT Message-Id: <199909241936.TAA18598@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: "Dines, Eric" Cc: vsta@zendo.com Subject: Re: Network Cards In-reply-to: Your message of "Wed, 22 Sep 1999 18:17:53 +0800." Date: Fri, 24 Sep 1999 19:36:09 +0000 From: Andy Valencia ["Dines, Eric" writes:] >Can you forward to me the correct config. files to get the network card >happening please? >autoexec.net >inittab They should be in /vsta/etc. >How close a clone to a 'true' NE2000 should the card be? I have a Kingston >ISA NE2000 compatible...I assume that should be OK. Most generic NE2000 cards have worked OK for me. The only hard part is knowing what the I/O base and IRQ are. If they're soft configurable, you have to grit your teeth and boot a Mickeysoft OS to set up the cards. >Any pointers on getting the networking functional!?!% Edit /vsta/etc/autoexec.net. Mostly set up your IP address, hostname, domain name, and a domain server. Then run "/vsta/boot/ne ," for instance: "ne 0x300,3 &" (ampersand, i.e., run in background). Once the server prints out a reasonable MAC address for your card (found it OK, it'll take it about a second), then run "net" from /vsta/srv/srv/ka9q. By default it should use /vsta/etc/autoexec.net, and by default the ethernet driver should be found OK by the "attach eth eth0 1500" line of the autoexec.net. You should now be at the prompt for ka9q, with TCP/IP up. You should be able to "ping " and get a response showing how much time it took. From here you'll need to start referring to the source of ka9q to see all the commands which are available. If you log into another VSTa console as root, you should be able to run the "telnetd" command in the ka9q/cmd subdirectory, and once that's running, you should be able to telnet into the system and log in. You can also run ka9q/cmd/proxyd, after which if you set up ka9q on a second system, you should be able to do "mount //fs/root@ /rem", after which the remote's root filesystem is available under /rem. You could also do "mount //fs/proc@ /proc2", and then kill remote processes by "echo -n kill > /proc2//note". proxyd needs to run on the system you're mounting *from*. FYI, on the side, I've been hacking on getting VSTa booting under the x86 CPU emulator "bochs". I can boot up the microkernel, console, and testsh, and am looking at a bug in bochs' handling of interrupts versus "rep insw" for transferring multiple sectors from IDE. I'll hopefully get a little more time to fix it up, submit the patches back to the author, and then this'll be a nice extra option for doing VSTa hacking without having to deal with disk partitions (or even rebooting your hardware!). Andy Valencia From daemon Sat Sep 25 09:00:59 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA21599 for vsta-xplod; Sat, 25 Sep 1999 09:00:59 GMT Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA21580 for ; Sat, 25 Sep 1999 09:00:54 GMT Received: from rano.demon.co.uk ([158.152.194.10] helo=rano.rano.org) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 11UvAF-000LXb-0B for vsta@zendo.com; Sat, 25 Sep 1999 16:59:11 +0000 Received: from ege by rano.rano.org with local (Exim 2.05 #1 (Debian)) id 11Us65-0002of-00; Sat, 25 Sep 1999 14:42:41 +0100 Date: Sat, 25 Sep 1999 14:42:41 +0100 From: Edmund GRIMLEY EVANS To: vsta@zendo.com Subject: Re: Network Cards Message-ID: <19990925144241.E261@rano.rano.org> References: <199909241936.TAA18598@bodhi.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909241936.TAA18598@bodhi.zendo.com>; from Andy Valencia on Fri, Sep 24, 1999 at 07:36:09PM +0000 Sender: Edmund GRIMLEY EVANS Andy Valencia: > >How close a clone to a 'true' NE2000 should the card be? I have a Kingston > >ISA NE2000 compatible...I assume that should be OK. > > Most generic NE2000 cards have worked OK for me. The only hard part is > knowing what the I/O base and IRQ are. If they're soft configurable, you > have to grit your teeth and boot a Mickeysoft OS to set up the cards. I set up my ISA NE2000 network card under DR-DOS, which I had downloaded free of charge and keep in a safe place for use only in an emergency. I felt bad about it, but managing to flash-upgrade my modem under Linux cheered me up a bit ... From daemon Mon Oct 4 02:55:34 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id CAA06557 for vsta-xplod; Mon, 4 Oct 1999 02:55:34 GMT Received: from frodo.marshall.edu (SYSTEM@[206.212.27.122]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id CAA06538 for ; Mon, 4 Oct 1999 02:55:30 GMT Received: from marshall.edu (webmail.MARSHALL.EDU [206.212.27.46]) by MARSHALL.EDU (PMDF V5.2-31 #35868) with ESMTP id <01JGQ8XTGS5O8WWJ0G@MARSHALL.EDU> for vsta@zendo.com; Mon, 4 Oct 1999 07:37:44 EDT Date: Mon, 04 Oct 1999 06:41:43 -0500 From: Matthew Stapleton Subject: MGR To: vsta@zendo.com Message-id: <01JGQ8XTH1KU8WWJ0G@MARSHALL.EDU> MIME-version: 1.0 X-Mailer: IMHO for Roxen Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit X-Originating-IP: [206.212.45.134] I recently installed VSTa on a fat-16 hdd and I also unpacked the mgr.tz, which I understand to be the GUI for VSTa. When I tried running the program /mgr/bin/mgr the screen froze with various strips of colors running down the screen. Of course, I had to reset and then I tried compiling, and it complained about some errors and did not complete. How do I configure VSTa to run MGR? Do I need to set the mouse up before trying MGR? What am I doing wrong? Matthew From daemon Mon Oct 4 07:07:01 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA06770 for vsta-xplod; Mon, 4 Oct 1999 07:07:01 GMT Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA06764 for ; Mon, 4 Oct 1999 07:06:58 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA15625; Mon, 4 Oct 1999 08:48:26 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00315; Mon, 4 Oct 1999 08:43:03 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199910041543.IAA00315@vandys-pc.vandys.cisco.com> To: "Dan Liebgold" cc: vsta@zendo.com Subject: Re: FAT32? In-reply-to: Your message of "Wed, 29 Sep 1999 13:03:01 PDT." <000201bf0e08$4d182b20$0500a8c0@SHUWA> Reply-to: vandys@cisco.com Date: Mon, 04 Oct 1999 08:43:02 -0700 From: Andy Valencia ["Dan Liebgold" writes:] >I'm looking into making the necessary modifications to the DOS/FAT = >server to be able to support FAT32 disks (in addition to FAT12 and = >FAT16). Has anyone done any work in this area? I pulled a recent copy of mtools (which already support FAT32). It didn't look too hard, but certainly not trivial. I haven't heard of anybody else attempting it. Regards, Andy Valencia From daemon Mon Oct 4 07:46:23 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA06855 for vsta-xplod; Mon, 4 Oct 1999 07:46:23 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA06849 for ; Mon, 4 Oct 1999 07:46:20 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA11128; Mon, 4 Oct 1999 09:27:26 -0700 (PDT) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00675; Mon, 4 Oct 1999 09:27:20 -0700 (PDT) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199910041627.JAA00675@vandys-pc.vandys.cisco.com> To: Matthew Stapleton cc: vsta@zendo.com Subject: Re: MGR, plus related fun In-reply-to: Your message of "Mon, 04 Oct 1999 06:41:43 CDT." <01JGQ8XTH1KU8WWJ0G@MARSHALL.EDU> Reply-to: vandys@cisco.com Date: Mon, 04 Oct 1999 09:27:20 -0700 From: Andy Valencia [Matthew Stapleton writes:] >I recently installed VSTa on a fat-16 hdd and I also unpacked the mgr.tz, >which I understand to be the GUI for VSTa. When I tried running the program >/mgr/bin/mgr the screen froze with various strips of colors running down the >screen. Of course, I had to reset and then I tried compiling, and it >complained about some errors and did not complete. How do I configure VSTa >to run MGR? Do I need to set the mouse up before trying MGR? What am I >doing wrong? You definitely need to have a mouse running before you start MGR. If you want to recompile, start only with the part in /vsta/mgr/src/mgr; some of the other parts of the source tree don't compile cleanly. And I'd say MGR is more *a* GUI rather than *the* GUI. But it works. Related news: With two patches to bochs (an x86 emulator: http://www.bochs.com) I can now boot VSTa multi-user, run a mouse server, and start MGR. It's a real kick to have a full, normal VSTa environment virtualized under a FreeBSD X window! I've submitted the patches back to bochs.com, but haven't heard back on whether/when they'll release them. One of the fixes is definitely generic, having to do with insb/insw instruction emulation versus page faults. For now, interested parties can pick up a working copy of Bochs in: http://www.vsta.org/Software/bochs/bochs.tar.gz I've put the bootable hard disk image (300 megs, sorry) in: http://www.vsta.org/Software/bochs/322M.gz (The entire VSTa source tree is also within this virtual disk.) A bootable floppy disk image is in: http://www.vsta.org/Software/bochs/vsta.flp.gz And my startup invocation shell script in: http://www.vsta.org/Software/bochs/vsta.sh You can probably omit the floppy disk, since the hard disk is bootable. Once you're running I've seen some oddities with the keyboard after entering kernel debugger, and also the clock ticks *way* too fast--probably a problem with the clock divisor emulation. But still, this is a really great way to work with VSTa without having to boot down to cold iron (silicon). Regards, Andy Valencia From daemon Mon Oct 4 13:56:06 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA07218 for vsta-xplod; Mon, 4 Oct 1999 13:56:06 GMT Received: from ns1.mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id NAA07199 for ; Mon, 4 Oct 1999 13:56:00 GMT Received: from fcgateway.mcps.k12.md.us (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with ESMTP id SAA17237; Mon, 4 Oct 1999 18:36:41 -0400 Message-id: Date: Mon, 04 Oct 1999 18:28:38 -0400 Subject: Re: MGR To: staple12@MARSHALL.EDU Cc: vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit staple12@marshall.edu writes: >I recently installed VSTa on a fat-16 hdd and I also unpacked the mgr.tz, >which I understand to be the GUI for VSTa. When I tried running the >program /mgr/bin/mgr the screen froze with various strips of colors >running down the screen. Of course, I had to reset and then I tried >compiling, and it complained about some errors and did not complete. How >do I configure VSTa to run MGR? Do I need to set the mouse up before >trying MGR? What am I doing wrong? > It's the mouse, as I recall, mgr is very picky about having the mouse daemon running. From daemon Mon Nov 1 02:47:16 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id CAA25854 for vsta-xplod; Mon, 1 Nov 1999 02:47:16 GMT Received: from hestia.its.deakin.edu.au (root@hestia.its.deakin.edu.au [128.184.136.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id CAA25835 for ; Mon, 1 Nov 1999 02:47:05 GMT Received: from deakin.edu.au ([128.184.83.188]) by hestia.its.deakin.edu.au (8.9.3/8.9.3) with ESMTP id UAA00795 for ; Mon, 1 Nov 1999 20:48:33 +1100 (EST) Message-ID: <381D61EE.54EF676F@deakin.edu.au> Date: Mon, 01 Nov 1999 20:48:31 +1100 From: Max Int X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: NET fails Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Suddenly I am getting debugger errors when ka9q- net service is trying to start. Assertion failed line 36 file ../kern/atl.c add_atl: already there I didn't think I had made any changes to the system; can anyone help? thanks Eric esd@deakin.edu.au From daemon Mon Nov 1 10:34:01 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA26341 for vsta-xplod; Mon, 1 Nov 1999 10:34:01 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA26335 for ; Mon, 1 Nov 1999 10:33:47 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA22158; Mon, 1 Nov 1999 09:34:53 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00664; Mon, 1 Nov 1999 09:34:51 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911011734.JAA00664@vandys-pc.vandys.cisco.com> To: Max Int cc: vsta@zendo.com Subject: Re: NET fails In-reply-to: Your message of "Mon, 01 Nov 1999 20:48:31 +1100." <381D61EE.54EF676F@deakin.edu.au> Reply-to: vandys@cisco.com Date: Mon, 01 Nov 1999 09:34:51 -0800 From: Andy Valencia [Max Int writes:] >Suddenly I am getting debugger errors when ka9q- net service is trying >to start. >Assertion failed line 36 file ../kern/atl.c >add_atl: already there >I didn't think I had made any changes to the system; can anyone help? You'll find some notes on this under "Threads race for VM" in the (recent) mail archives. I'm thinking that the real/ultimate fix will be to use clock_slot(), and letting the fault resolution drop back out to usermode to restart the instruction. This will be the most efficient for the non-error case, which is the one we want to favor. Other fixes would be to scan lists and such, but that costs extra CPU cycles. Let me know if you're not up to kernel hacking, and I'll play with it tonight. As a workaround, you could try running with a kernel built without DEBUG defined; it'll probably run OK, with some possibility of Bad Things (tm) if you start and stop the net process a lot without rebooting. Andy Valencia From daemon Mon Nov 1 14:19:04 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA26683 for vsta-xplod; Mon, 1 Nov 1999 14:19:04 GMT Received: from ns1.mcps.k12.md.us (ns1.mcps.k12.md.us [205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id OAA26664 for ; Mon, 1 Nov 1999 14:18:58 GMT Received: from nasta (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with SMTP id QAA05341; Mon, 1 Nov 1999 16:19:38 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: esd@deakin.edu.au Cc: vsta@zendo.com Date: Mon, 1 Nov 1999 14:10:05 -0400 Subject: Re: NET fails Message-ID: References: <381D61EE.54EF676F@deakin.edu.au> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) esd@deakin.edu.au writes: >Suddenly I am getting debugger errors when ka9q- net service is trying >to start. >Assertion failed line 36 file ../kern/atl.c >add_atl: already there >I didn't think I had made any changes to the system; can anyone help? >thanks >Eric This sounds like a bug I ran into a while back that dealt with a race of two threads generating the same page fault at the same time. I can post the patch but here's something that may (or may not) help: try linking the offending service against the static -lc_s library. There's a slim chance that avoids the problem by causing the library to page in before the two threads try to page it in at the same time. Of course, if that util doesn't use threads, then all I'm saying here is wrong. If it does use threads, you can also try to put a little sleep() at the beginning of each function that's tfork'd. From daemon Tue Nov 2 07:51:31 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA27764 for vsta-xplod; Tue, 2 Nov 1999 07:51:31 GMT Received: from ns1.mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id HAA27745 for ; Tue, 2 Nov 1999 07:51:25 GMT Received: from nasta (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with SMTP id JAA12242; Tue, 2 Nov 1999 09:51:48 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: esd@deakin.edu.au, vsta@zendo.com Date: Tue, 2 Nov 1999 07:35:58 -0400 Subject: Re: NET fails Message-ID: References: <199911011734.JAA00664@vandys-pc.vandys.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@cisco.com writes: >You'll find some notes on this under "Threads race for VM" in the >(recent) >mail archives. I'm thinking that the real/ultimate fix will be to use >clock_slot(), and letting the fault resolution drop back out to >usermode to >restart the instruction. This will be the most efficient for the >non-error >case, which is the one we want to favor. Other fixes would be to scan >lists >and such, but that costs extra CPU cycles. I looked at the code again and I was thinking something similar. I was going to have lock_slot() return a value to indicate whether it had to sleep in order to lock the slot, and if so, vas_fault would simply try the instruction again. We probably wouldn't want to use clock_slot() alone, because that would mean the thread would remain continuously generating faults and looking up the page while the I/O pages in. From daemon Tue Nov 2 09:46:09 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA27882 for vsta-xplod; Tue, 2 Nov 1999 09:46:09 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA27876 for ; Tue, 2 Nov 1999 09:46:02 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA27855; Tue, 2 Nov 1999 08:47:10 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00321; Tue, 2 Nov 1999 08:46:52 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911021646.IAA00321@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: esd@deakin.edu.au, vsta@zendo.com Subject: Re: NET fails In-reply-to: Your message of "Tue, 02 Nov 1999 07:35:58 -0400." Reply-to: vandys@cisco.com Date: Tue, 02 Nov 1999 08:46:52 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I looked at the code again and I was thinking something >similar. I was going to have lock_slot() return a value >to indicate whether it had to sleep in order to lock the >slot, and if so, vas_fault would simply try the instruction >again. We probably wouldn't want to use clock_slot() >alone, because that would mean the thread would remain >continuously generating faults and looking up the page >while the I/O pages in. Yes, you're absolutely right. We still want to sleep on the slot until it becomes unlocked. Nice call... are you coding this, or shall I? Thanks! Andy From daemon Wed Nov 3 12:41:15 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA29767 for vsta-xplod; Wed, 3 Nov 1999 12:41:15 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA29761 for ; Wed, 3 Nov 1999 12:41:06 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA27499; Wed, 3 Nov 1999 11:42:08 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id LAA01605; Wed, 3 Nov 1999 11:41:51 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911031941.LAA01605@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Threads race for VM In-reply-to: Your message of "Sun, 06 Jun 1999 19:47:59 EDT." Reply-to: vandys@cisco.com Date: Wed, 03 Nov 1999 11:41:51 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >What this means is that when lock_slot finds the slot is busy and >has to wait, we need to recheck all of the conditions that could >have caused a fault, because the processor wasn't using "thread-safe" >information. Fortunately, this condition seems to be rather rare. >Perhaps a more ideal solution would be to have lock_slot() return >a flag which indicates whether it had to wait for the slot to be >free. That way we wouldn't have to scan the pp_atl every time. >Or maybe we could just have vm_fault return in such a case, to try >to regenerate the fault now that the HAT is up-to-date? After taking a slightly longer look at this, I've come the realization that this approach won't work. Imagine that thread1 has faulted on the address, and comes into the kernel. But then his clock ticks, and the CPU goes off to do that. In parallel, thread2, on another process (SMP), faults on the same address, comes in, resolves the fault, and returns. Thread1 finishes with the clock tick, and takes the lock on the slot. There is no contention, because thread2 has come and gone. And yet, not only is the page valid, but there's a mapping in their (shared) address space. I'm going to need to ponder whether it's better to add a per-virtual-page data structure to the pview, or whether it's acceptable to consult the atl list for a physical page at mapping time. I'm leaning towards the latter, since this is already done for the detach. But I can probably fix both add and delete cases if I convert to a pview-level per-page flag. Andy From daemon Thu Nov 4 12:03:05 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA01300 for vsta-xplod; Thu, 4 Nov 1999 12:03:05 GMT Received: from ns1.mcps.k12.md.us ([205.222.5.40]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id MAA01281 for ; Thu, 4 Nov 1999 12:02:55 GMT Received: from nasta (fcgateway.mcps.k12.md.us [205.222.5.94]) by ns1.mcps.k12.md.us (8.6.12/8.6.12) with SMTP id OAA02344; Thu, 4 Nov 1999 14:03:51 -0500 From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) To: vandys@cisco.com Cc: vsta@zendo.com Date: Thu, 4 Nov 1999 11:51:56 -0400 Subject: Re: Threads race for VM Message-ID: References: <199911031941.LAA01605@vandys-pc.vandys.cisco.com> Organization: Montgomery County Public Schools MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 2.0 for FirstClass(R) vandys@cisco.com writes: >After taking a slightly longer look at this, I've come the realization >that >this approach won't work. Imagine that thread1 has faulted on the >address, >and comes into the kernel. But then his clock ticks, and the CPU goes >off >to do that. >In parallel, thread2, on another process (SMP), faults on the same >address, >comes in, resolves the fault, and returns. Ah... I see. thread1 hasn't taken the pset lock yet, so he could be pre-empted without even falling asleep on a semaphore. Probably unlikely, but certainly possible. >Thread1 finishes with the clock tick, and takes the lock on the slot. >There >is no contention, because thread2 has come and gone. And yet, not only >is >the page valid, but there's a mapping in their (shared) address space. >I'm going to need to ponder whether it's better to add a >per-virtual-page >data structure to the pview, or whether it's acceptable to consult the >atl >list for a physical page at mapping time. I'm leaning towards the >latter, >since this is already done for the detach. But I can probably fix both >add >and delete cases if I convert to a pview-level per-page flag. I'm curious: how would the per-virtual-page struct help us here? I'm also wondering if that scenario could be avoided by holding off pre-emption until we have the pset lock. It's not very far from the sti() in trap() until the find_pview() in vas_fault(). Allowing another thread in that period has the effect of invalidating the processor's decision to enter the trap. Unless there's a real easy way to revalidate that decision after the slot lock is taken, I don't know if it makes sense to allow another thread to come in at that point. Eric From daemon Thu Nov 4 12:51:39 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA01359 for vsta-xplod; Thu, 4 Nov 1999 12:51:39 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA01353 for ; Thu, 4 Nov 1999 12:51:34 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA17804; Thu, 4 Nov 1999 11:52:46 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id LAA18212; Thu, 4 Nov 1999 11:52:22 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911041952.LAA18212@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Threads race for VM In-reply-to: Your message of "Thu, 04 Nov 1999 11:51:56 -0400." Reply-to: vandys@cisco.com Date: Thu, 04 Nov 1999 11:52:21 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >Ah... I see. thread1 hasn't taken the pset lock yet, so he could >be pre-empted without even falling asleep on a semaphore. >Probably unlikely, but certainly possible. In a kernel mod I did for the Oracle production systems (back when I was at Sequent), I sent out a patch before having it reviewed by "the" SMP VM guy. In his review, he found the most miniscule of potential race conditions, and commented (wryly) "it's almost impossible to hit, so they'll have to reboot only once a day". In fact, it hit twice a day, but fortunately it hung the CPU in a way which could be cleared by manual intervention (rather than a reboot). My lesson: in OS's, everything possible, happens. >I'm curious: how would the per-virtual-page struct help us >here? If you flag when the ATL is added for a given pview slot, then you can check this flag in the fault handling (and know that you should just re-run the instruction). It also streamlines address space cleanup, since you don't have to scan all the atl's for a given physical page. >I'm also wondering if that scenario could be avoided by holding >off pre-emption until we have the pset lock. It's not very far >from the sti() in trap() until the find_pview() in vas_fault(). >Allowing another thread in that period has the effect of >invalidating the processor's decision to enter the trap. Unless >there's a real easy way to revalidate that decision after the >slot lock is taken, I don't know if it makes sense to allow >another thread to come in at that point. That still wouldn't protect against another CPU running in parallel. And no, I don't think a global lock would be the right way to go! (The thread on the other processor is *probably* going to be faulting against some completely unrelated page. No need to serialize at any point.) Andy From daemon Fri Nov 5 03:22:49 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id DAA02457 for vsta-xplod; Fri, 5 Nov 1999 03:22:49 GMT Received: from charleston.softhome.net (qmailr@charleston.SoftHome.net [204.144.231.41]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id DAA02438 for ; Fri, 5 Nov 1999 03:22:45 GMT Received: (qmail 4315 invoked by uid 417); 5 Nov 1999 10:52:15 -0000 Received: from k3nw338.dial.kabelfoon.nl (HELO SoftHome.net) (195.193.25.83) by smtp.softhome.net with SMTP; 5 Nov 1999 10:52:15 -0000 Message-ID: <3822B075.2C60D994@SoftHome.net> Date: Fri, 05 Nov 1999 11:24:53 +0100 From: Stefan Rieken Organization: Flip de Egel Productions X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: alive? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am new to vsta. So, I have, off course a few questions: 1. Alive? That the copyright notice didn't include 1999 was the first sign for me that vsta might not be that alive anymore. Then Andy said this directly in his welcome note to the mailing list. How big is this scene still? How many people are there on this list? Would it be worth the effort if I started working on vsta (docs), or is this project really ending? 2. GUI? The Web site promises MADO. The MADO docs say that it is in alpha stage. Is there a way that I can use it? There is also MGR. How should I use this package (compile - what compiler? install - how?)? 3. Squeak! It was an awful good idea of Andy to mention that name. I always liked the idea of a Squeak OS. (Merely a remark than a question :-) Greets, Stefan From daemon Fri Nov 5 08:54:13 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA02800 for vsta-xplod; Fri, 5 Nov 1999 08:54:13 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA02794 for ; Fri, 5 Nov 1999 08:54:11 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA07121; Fri, 5 Nov 1999 07:55:28 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00299; Fri, 5 Nov 1999 07:55:26 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911051555.HAA00299@vandys-pc.vandys.cisco.com> To: Stefan Rieken cc: vsta@zendo.com Subject: Re: alive? In-reply-to: Your message of "Fri, 05 Nov 1999 11:24:53 +0100." <3822B075.2C60D994@SoftHome.net> Reply-to: vandys@cisco.com Date: Fri, 05 Nov 1999 07:55:25 -0800 From: Andy Valencia [Stefan Rieken writes:] >1. Alive? That the copyright notice didn't include 1999 was the first >sign for me that vsta might not be that alive anymore. Then Andy said >this directly in his welcome note to the mailing list. How big is this >scene still? How many people are there on this list? Would it be worth >the effort if I started working on vsta (docs), or is this project >really ending? VSTa's a little bit alive. From the mail archives, you can see a bit of activity--some work on DMA bounce buffers, my work getting it running under the Bochs x86 emulator, and some kernel bug work. >2. GUI? The Web site promises MADO. The MADO docs say that it is in >alpha stage. Is there a way that I can use it? There is also MGR. How >should I use this package (compile - what compiler? install - how?)? I'd be happy to see MADO alive--I think the world at large (not just VSTa) could use the kind of windowing system MADO would be. Most recently I saw the Linux-on-Psion people wrestling with an appropriate, scalable GUI. The only one I know of is Photon for QNX, but that's proprietary. >3. Squeak! It was an awful good idea of Andy to mention that name. I >always liked the idea of a Squeak OS. (Merely a remark than a question >:-) Squeak can also scale down to pretty small memory systems. Not as small as Photon, and it doesn't have the distributed capabilities of Photon. But it's a living program, supported by some of the best Smalltalk minds in the world. Most of my VSTa "brain cycles" are spent trying to figure out how you make a "real" system out of the VSTa+Squeak+? building blocks. Better docs would be absolutely welcome in VSTa, of course! Welcome, Andy Valencia From daemon Sat Nov 6 09:36:29 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA06455 for vsta-xplod; Sat, 6 Nov 1999 09:36:29 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA06449 for ; Sat, 6 Nov 1999 09:36:25 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA11480; Sat, 6 Nov 1999 08:37:45 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA06634; Sat, 6 Nov 1999 08:37:44 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199911061637.IAA06634@vandys-pc.vandys.cisco.com> To: Eddie McCreary cc: vsta@zendo.com Subject: Re: Bochs patches In-reply-to: Your message of "Fri, 05 Nov 1999 12:16:00 CST." <14371.7904.382000.285727@ALTAIR> Reply-to: vandys@cisco.com Date: Sat, 06 Nov 1999 08:37:44 -0800 From: Andy Valencia [Eddie McCreary writes:] >Andy, could you provide the patches you made to Bochs that allows Vsta >to boot? I would like to try to compile the Win32 version with the >patches and see if I can get it to run. The source is in: http://www.vsta.org/Software/bochs/bochs.tar.gz I don't really have any good way of generating diffs. I started from bochs-990920a, but didn't pour it all into source control. Yes, this was a small mistake, but since I promptly submitted the bugs I found to the developer, I wasn't expecting this source to have any longevity. The needed changes were to cpu/io.cc and iodev/harddrv.cc, if memory serves. Andy From daemon Tue Nov 30 17:27:59 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA13305 for vsta-xplod; Tue, 30 Nov 1999 17:27:59 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA13293 for ; Tue, 30 Nov 1999 17:17:45 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA28412 for ; Tue, 30 Nov 1999 16:28:49 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id QAA02670; Tue, 30 Nov 1999 16:27:32 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912010027.QAA02670@vandys-pc.vandys.cisco.com> To: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) cc: vsta@zendo.com Subject: Re: Threads race for VM In-reply-to: Your message of "Sun, 06 Jun 1999 19:47:59 EDT." Reply-to: vandys@cisco.com Date: Tue, 30 Nov 1999 16:27:32 -0800 From: Andy Valencia [Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:] >I just finished unconvering a nasty race for virtual memory that >sometimes occurs in multi-threaded processes. The most likely to >be affected are processes that call static-linked functions for the >first time in two or more threads at the same time. >... Attached below is a proposed patch to fix this problem. It seems to fix the kernel crach for me... care to look it over and also give it a spin? If it all looks OK, I'll put it in for 1.6.3. Thanks, Andy *** 1.8 1997/09/28 12:15:24 --- include/sys/pview.h 1999/11/09 15:51:44 *************** *** 18,25 **** --- 18,27 ---- struct pview /* For listing under vas */ *p_next; uchar p_prot; /* Protections on view */ struct hatpview p_hat; /* HAT contribution */ + uchar *p_valid; /* If attached to a VAS, flags which */ + /* virtual slots have mappings */ }; /* * Bits for protection *** 1.8 1997/12/22 17:32:31 --- include/sys/malloc.h 1999/11/09 16:01:32 *************** *** 43,52 **** #define MT_PGRP (21) /* Process grouping */ #define MT_ATL (22) /* Attach lists */ #define MT_FPU (23) /* FPU save state */ #define MT_OPENPORT (24) /* FOD pset data structure */ ! #define MALLOCTYPES (25) /* UPDATE when you add values above */ /* ALSO check n_allocname[] */ /* * Our per-storage-size information --- 43,53 ---- #define MT_PGRP (21) /* Process grouping */ #define MT_ATL (22) /* Attach lists */ #define MT_FPU (23) /* FPU save state */ #define MT_OPENPORT (24) /* FOD pset data structure */ + #define MT_PVIEW_VALID (25) /* pview valid page map */ ! #define MALLOCTYPES (26) /* UPDATE when you add values above */ /* ALSO check n_allocname[] */ /* * Our per-storage-size information *** 1.15 1997/09/28 12:18:26 --- src/os/dbg/dump.c 1999/11/19 14:48:40 *************** *** 296,305 **** do_dump_pview(struct pview *pv) { printf(" pview @ 0x%x vaddr 0x%x len 0x%x off 0x%x hat 0x%x\n", pv, pv->p_vaddr, pv->p_len, pv->p_off, &pv->p_hat); ! printf(" vas 0x%x next 0x%x prot 0x%x pset 0x%x\n", ! pv->p_vas, pv->p_next, pv->p_prot, pv->p_set); } /* * dump_pview() --- 296,305 ---- do_dump_pview(struct pview *pv) { printf(" pview @ 0x%x vaddr 0x%x len 0x%x off 0x%x hat 0x%x\n", pv, pv->p_vaddr, pv->p_len, pv->p_off, &pv->p_hat); ! printf(" vas 0x%x next 0x%x prot 0x%x pset 0x%x valid 0x%x\n", ! pv->p_vas, pv->p_next, pv->p_prot, pv->p_set, pv->p_valid); } /* * dump_pview() *** 1.15 1995/10/27 05:43:05 --- src/os/kern/malloc.c 1999/11/09 16:02:46 *************** *** 28,60 **** * Value to name mapping, to help the kernel debugger print * things out nicely */ char *n_allocname[MALLOCTYPES] = { ! "MT_RMAP", ! "MT_EVENT", ! "MT_EXITGRP", ! "MT_EXITST", ! "MT_MSG", ! "MT_SYSMSG", ! "MT_PORT", ! "MT_PORTREF", ! "MT_PVIEW", ! "MT_PSET", ! "MT_PROC", ! "MT_THREAD", ! "MT_KSTACK", ! "MT_VAS", ! "MT_PERPAGE", ! "MT_QIO", ! "MT_SCHED", ! "MT_SEG", ! "MT_EVENTQ", ! "MT_L1PT", ! "MT_L2PT", ! "MT_PGRP", ! "MT_ATL", ! "MT_FPU", ! "MT_OPENPORT", }; #endif /* DEBUG */ /* --- 28,41 ---- * Value to name mapping, to help the kernel debugger print * things out nicely */ char *n_allocname[MALLOCTYPES] = { ! "MT_RMAP", "MT_EVENT", "MT_EXITGRP", "MT_EXITST", "MT_MSG", ! "MT_SYSMSG", "MT_PORT", "MT_PORTREF", "MT_PVIEW", "MT_PSET", ! "MT_PROC", "MT_THREAD", "MT_KSTACK", "MT_VAS", "MT_PERPAGE", ! "MT_QIO", "MT_SCHED", "MT_SEG", "MT_EVENTQ", "MT_L1PT", ! "MT_L2PT", "MT_PGRP", "MT_ATL", "MT_FPU", "MT_OPENPORT", ! "MT_PVIEW_VALID", }; #endif /* DEBUG */ /* *** 1.8 1996/04/18 08:13:40 --- src/os/kern/pview.c 1999/11/09 16:10:30 *************** *** 35,42 **** --- 35,43 ---- void free_pview(struct pview *pv) { deref_pset(pv->p_set); + ASSERT_DEBUG(pv->p_valid == 0, "free_pview: p_valid not cleared"); FREE(pv, MT_PVIEW); } /* *************** *** 52,59 **** --- 53,61 ---- bcopy(opv, pv, sizeof(*pv)); ref_pset(pv->p_set); pv->p_next = 0; pv->p_vas = 0; + pv->p_valid = 0; return(pv); } /* *************** *** 86,95 **** struct pview *pv; extern struct pview *detach_pview(); pv = detach_pview(vas, vaddr); ! deref_pset(pv->p_set); ! FREE(pv, MT_PVIEW); } /* * attach_valid_slots() --- 88,96 ---- struct pview *pv; extern struct pview *detach_pview(); pv = detach_pview(vas, vaddr); ! free_pview(pv); } /* * attach_valid_slots() *************** *** 111,117 **** --- 112,119 ---- hat_addtrans(pv, (char *)pv->p_vaddr + ptob(x), pp->pp_pfn, pv->p_prot | ((pp->pp_flags & PP_COW) ? PROT_RO : 0)); ref_slot(ps, pp, idx); + pv->p_valid[x] = 1; } } } *** 1.57 1997/12/07 23:10:29 --- src/os/kern/proc.c 1999/11/18 16:19:30 *************** *** 44,54 **** ps = physmem_pset(pfn, pages); pv = alloc_pview(ps); pv->p_vaddr = vaddr; ! pv->p_vas = vas; ! pv->p_next = vas->v_views; ! vas->v_views = pv; return(pv); } /* --- 44,52 ---- ps = physmem_pset(pfn, pages); pv = alloc_pview(ps); pv->p_vaddr = vaddr; ! ASSERT(attach_pview(vas, pv), "mkview: attach failed"); return(pv); } /* *** 1.19 1998/12/13 22:19:14 --- src/os/kern/vm_steal.c 1999/11/09 16:14:58 *************** *** 139,146 **** --- 139,151 ---- hat_deletetrans(pv, (char *)pv->p_vaddr + ptob(a->a_idx), pp->pp_pfn); flags |= hat_getbits(pv, (char *)pv->p_vaddr + ptob(a->a_idx)); + + /* + * Virtual map under this pview not valid any more + */ + pv->p_valid[a->a_idx] = 0; } /* * Free attach list element, update ref count *** 1.8 1996/04/18 08:13:40 --- src/os/kern/vm_fault.c 1999/11/30 16:37:12 *************** *** 66,74 **** { struct pview *pv; struct pset *ps; struct perpage *pp; ! uint idx; int error = 0; int wasvalid; /* --- 66,74 ---- { struct pview *pv; struct pset *ps; struct perpage *pp; ! uint idx, pvidx; int error = 0; int wasvalid; /* *************** *** 76,83 **** --- 76,84 ---- */ if ((pv = find_pview(vas, vaddr)) == 0) { return(1); } + ASSERT_DEBUG(pv->p_valid, "vas_fault: pview !p_valid"); ps = pv->p_set; /* * Next easiest--trying to write to read-only view *************** *** 89,97 **** /* * Transfer from pset lock to page slot lock */ ! idx = btop(((char *)vaddr - (char *)pv->p_vaddr)) + pv->p_off; pp = find_pp(ps, idx); lock_slot(ps, pp); /* --- 90,99 ---- /* * Transfer from pset lock to page slot lock */ ! pvidx = btop((char *)vaddr - (char *)pv->p_vaddr); ! idx = pvidx + pv->p_off; pp = find_pp(ps, idx); lock_slot(ps, pp); /* *************** *** 121,151 **** /* * Break COW association when we write it */ if ((pp->pp_flags & PP_COW) && write) { if (wasvalid) { ! uint pvidx; ! ! /* ! * May or may not be there. If it is, remove ! * its reference from the per-page struct. ! */ ! pvidx = btop((ulong)vaddr - (ulong)pv->p_vaddr); ! if (delete_atl(pp, pv, pvidx) == 0) { ! deref_slot(ps, pp, idx); } } cow_write(ps, pp, idx); ASSERT(pp->pp_flags & PP_V, "vm_fault: lost the page 2"); } /* * With a valid slot, add a hat translation and tabulate * the entry with an atl. */ ! add_atl(pp, pv, btop((ulong)vaddr - (ulong)(pv->p_vaddr)), 0); hat_addtrans(pv, vaddr, pp->pp_pfn, pv->p_prot | ((pp->pp_flags & PP_COW) ? PROT_RO : 0)); /* * Free the various things we hold and return */ --- 123,164 ---- /* * Break COW association when we write it */ if ((pp->pp_flags & PP_COW) && write) { + /* + * May or may not be there. If it is, remove + * its reference from the per-page struct. + */ if (wasvalid) { ! if (pv->p_valid[pvidx]) { ! ASSERT(delete_atl(pp, pv, pvidx) == 0, ! "vas_fault: p_valid no atl"); ! pv->p_valid[pvidx] = 0; } + deref_slot(ps, pp, idx); } cow_write(ps, pp, idx); ASSERT(pp->pp_flags & PP_V, "vm_fault: lost the page 2"); + + /* + * If not writing to a COW association, then inhibit adding + * the translation if it's already present (another thread + * ran and brought it in for us, probably) + */ + } else if (pv->p_valid[pvidx]) { + deref_slot(ps, pp, idx); + goto out; } /* * With a valid slot, add a hat translation and tabulate * the entry with an atl. */ ! add_atl(pp, pv, pvidx, 0); hat_addtrans(pv, vaddr, pp->pp_pfn, pv->p_prot | ((pp->pp_flags & PP_COW) ? PROT_RO : 0)); + ASSERT_DEBUG(pv->p_valid[pvidx] == 0, "vas_fault: p_valid went on"); + pv->p_valid[pvidx] = 1; /* * Free the various things we hold and return */ *** 1.13 1996/01/04 22:48:17 --- src/os/kern/vas.c 1999/11/18 16:23:00 *************** *** 59,66 **** --- 59,67 ---- struct pset *ps; struct perpage *pp; int x; struct pview *pv, **pvp; + char *va; /* * Remove our pview from the vas. It's singly linked, so we * have to search from the front. *************** *** 76,83 **** --- 77,85 ---- pvp = &pv->p_next; } ASSERT(pv, "detach_pview: lost a pview"); v_lock(&vas->v_lock, SPL0_SAME); + ASSERT_DEBUG(pv->p_valid, "detach_pview: !p_valid"); ps = pv->p_set; /* * Walk each valid slot, and tear down any HAT translation. *************** *** 85,125 **** p_lock_void(&ps->p_lock, SPL0_SAME); for (x = 0; x < pv->p_len; ++x) { uint pfn, idx; - idx = pv->p_off + x; - pp = find_pp(ps, idx); - /* ! * Can't be a translation if not a valid page */ ! if (!(pp->pp_flags & PP_V)) { continue; } pfn = pp->pp_pfn; /* * Lock the slot. Lock the underlying page. Delete * translation, and deref our use of the slot. */ lock_slot(ps, pp); ! if (delete_atl(pp, pv, x) == 0) { ! char *va; ! /* ! * Valid in our view; delete HAT translation. Record ! * ref/mod bits for final time. ! */ ! va = pv->p_vaddr; ! va += ptob(x); ! hat_deletetrans(pv, va, pfn); ! pp->pp_flags |= hat_getbits(pv, va); ! ! /* ! * Release our reference to the slot ! */ ! deref_slot(ps, pp, idx); ! } unlock_slot(ps, pp); /* * Reacquire pset lock --- 87,131 ---- p_lock_void(&ps->p_lock, SPL0_SAME); for (x = 0; x < pv->p_len; ++x) { uint pfn, idx; /* ! * Skip all but those with active mappings */ ! if (!pv->p_valid[x]) { continue; } + + /* + * Point to the mapping + */ + idx = pv->p_off + x; + pp = find_pp(ps, idx); + ASSERT_DEBUG(pp->pp_flags & PP_V, + "detach_pview: p_valid !PP_V"); pfn = pp->pp_pfn; /* * Lock the slot. Lock the underlying page. Delete * translation, and deref our use of the slot. */ lock_slot(ps, pp); ! ASSERT(delete_atl(pp, pv, x) == 0, ! "detach_pview: p_valid but not ATL"); ! /* ! * Valid in our view; delete HAT translation. Record ! * ref/mod bits for final time. ! */ ! va = pv->p_vaddr; ! va += ptob(x); ! hat_deletetrans(pv, va, pfn); ! pp->pp_flags |= hat_getbits(pv, va); ! ! /* ! * Release our reference to the slot ! */ ! deref_slot(ps, pp, idx); unlock_slot(ps, pp); /* * Reacquire pset lock *************** *** 136,143 **** --- 142,155 ---- * Let hat hear about detach */ hat_detach(pv); + /* + * Free valid map memory + */ + FREE(pv->p_valid, MT_PVIEW_VALID); + pv->p_valid = 0; + return(pv); } /* *************** *** 174,181 **** --- 186,199 ---- pv->p_vas = 0; return(0); } vaddr = pv->p_vaddr; + + /* + * Get the memory for the valid map + */ + pv->p_valid = MALLOC(pv->p_len, MT_PVIEW_VALID); + bzero(pv->p_valid, pv->p_len); /* * Now that we're committed, link it onto the vas */ From daemon Thu Dec 9 16:10:00 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA03144 for vsta-xplod; Thu, 9 Dec 1999 16:10:00 GMT Received: from hestia.its.deakin.edu.au (root@hestia.its.deakin.edu.au [128.184.136.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA03114 for ; Thu, 9 Dec 1999 16:09:10 GMT Received: from deakin.edu.au ([128.184.83.188]) by hestia.its.deakin.edu.au (8.9.3/8.9.3) with ESMTP id KAA01651 for ; Fri, 10 Dec 1999 10:21:06 +1100 (EST) Message-ID: <38503942.5B718F50@deakin.edu.au> Date: Fri, 10 Dec 1999 10:20:34 +1100 From: Eric Dines X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Bochs on Win32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >[Eddie McCreary writes:] >>Andy, could you provide the patches you made to Bochs that allows Vsta >>to boot? I would like to try to compile the Win32 version with the >>patches and see if I can get it to run. >The source is in: > http://www.vsta.org/Software/bochs/bochs.tar.gz >I don't really have any good way of generating diffs. I started from >bochs-990920a, but didn't pour it all into source control. Yes, this was a >small mistake, but since I promptly submitted the bugs I found to the >developer, I wasn't expecting this source to have any longevity. The needed >changes were to cpu/io.cc and iodev/harddrv.cc, if memory serves. >Andy Did you have any success with Win32 Bochs Eddie? I am having no end of trouble compiling Bochs under Linux. I think its the CPU on my machine generating errors/bodgy code. regards Eric esd@deakin.edu.au From daemon Thu Dec 9 18:00:46 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA03345 for vsta-xplod; Thu, 9 Dec 1999 18:00:46 GMT Received: from hestia.its.deakin.edu.au (root@hestia.its.deakin.edu.au [128.184.136.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA03326 for ; Thu, 9 Dec 1999 18:00:37 GMT Received: from deakin.edu.au ([128.184.83.188]) by hestia.its.deakin.edu.au (8.9.3/8.9.3) with ESMTP id MAA00518 for ; Fri, 10 Dec 1999 12:12:36 +1100 (EST) Message-ID: <3850535D.E1ABC1A4@deakin.edu.au> Date: Fri, 10 Dec 1999 12:11:57 +1100 From: Eric Dines X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: less archives Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can anybody tell me what format the tz compressed archives are stored on ftp.cynus. I want the less, sed and vim sources, but every attempt at uncompressing them fails. Incidently is there a version of the shell that has keystroke history? regards Eric esd@deakin.edu.au From daemon Fri Dec 10 05:21:49 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA04126 for vsta-xplod; Fri, 10 Dec 1999 05:21:49 GMT Received: from hestia.its.deakin.edu.au (root@hestia.its.deakin.edu.au [128.184.136.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id FAA04107 for ; Fri, 10 Dec 1999 05:21:39 GMT Received: from deakin.edu.au ([128.184.83.188]) by hestia.its.deakin.edu.au (8.9.3/8.9.3) with ESMTP id XAA28755 for ; Fri, 10 Dec 1999 23:33:41 +1100 (EST) Message-ID: <3850F31F.BF8CBB47@deakin.edu.au> Date: Fri, 10 Dec 1999 23:33:36 +1100 From: Eric Dines X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Re: less archives References: <3850535D.E1ABC1A4@deakin.edu.au> <19991210094820.C3472@daisy.vocalis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks Edmund, but I have had no joy whatsoever. If anyone has got an uncompressed copy would they mind sending me a fresh tarball please? Eric esd@deakin.edu.au Edmund GRIMLEY EVANS wrote: > > Can anybody tell me what format the tz compressed archives are stored on > > ftp.cynus. > > Probably .tar.gz. Try tar xvzf whatever.tz From daemon Fri Dec 10 16:12:26 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA04957 for vsta-xplod; Fri, 10 Dec 1999 16:12:26 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA04951 for ; Fri, 10 Dec 1999 16:11:59 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA06046; Fri, 10 Dec 1999 15:23:35 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id PAA01436; Fri, 10 Dec 1999 15:23:31 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912102323.PAA01436@vandys-pc.vandys.cisco.com> To: Eric Dines cc: vsta@zendo.com Subject: Re: less archives In-reply-to: Your message of "Fri, 10 Dec 1999 12:11:57 +1100." <3850535D.E1ABC1A4@deakin.edu.au> Reply-to: vandys@cisco.com Date: Fri, 10 Dec 1999 15:23:30 -0800 From: Andy Valencia [Eric Dines writes:] > Incidently is there a version of the shell that >has keystroke history? The current shell has keystroke history (at least as I understand the term). Cooked mode TTY's all automatically get command line editing, because cooked mode uses getline(). So any program which gets its input from a TTY in cooked mode (shell, RCS, ed, ...) has command line editing. Andy From daemon Fri Dec 17 11:33:55 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA18179 for vsta-xplod; Fri, 17 Dec 1999 11:33:55 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA18173 for ; Fri, 17 Dec 1999 11:33:44 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA04799; Fri, 17 Dec 1999 10:45:31 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA08576; Fri, 17 Dec 1999 10:45:11 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912171845.KAA08576@vandys-pc.vandys.cisco.com> To: "Dines, Eric" cc: "'vsta@zendo.com'" Subject: Re: Future Directions In-reply-to: Your message of "Tue, 14 Dec 1999 20:59:22 +0800." Reply-to: vandys@cisco.com Date: Fri, 17 Dec 1999 10:45:10 -0800 From: Andy Valencia ["Dines, Eric" writes:] >Are there any new experimental Op Systems techniques or prospective new >directions on the horizon that VSTa may embrace? >ie What's next on the agenda? First thing is to get VSTa current with all those PCI systems--before ISA disappears and VSTa can't be run on modern systems! Longer term, I think I agree with Linus that the real game is what runs on top of the kernel. I've mentioned Squeak (www.squeak.org) in the past, and still think this is a very interesting system. I have reservations about the fact that the Smalltalk runtime philosophy is that any problem in any function can jeopardize all other functions. I think in this day and age it simply isn't good enough that your mail, editing, news, and browsing is all at risk from any fault. You can run more than one virtual machine, but then you lose the ability to seamlessly access any type of data from any other appropriate application. This approach seems to give up much of the power of the OO environment. So I've been pondering multiple VM's, but with really tight integration of mechanisms similar to Java's object serialization. There'd be one VM which owned and maintained the display. This VM might run some core set of trusted tasks. Then additional VM instances would be fired up; the display object in these additional VM's would be the remote handle of the single physical display. The bulk of the work would be mapping out (based on trial and error) which kinds of objects should be private to a VM instance, and which should be shared. Also, how sharing is implemented, and so forth. My current imaginings is that VSTa would make a pretty good OS to host the VM's--it would handle clock ticks, filesystem, disks, and all that low level stuff. When you logged onto VSTa, your VM would fire up to provide your base GUI. As you invoked actions, other VM's would seamlessly be called into existence. As you hacked on some app and blew up your entire runtime environment, that VM would be debugged/scrapped, but your primary VM and all other VM's would be isolated and thus undamaged. Andy Valencia From daemon Sat Dec 18 17:37:47 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA22221 for vsta-xplod; Sat, 18 Dec 1999 17:37:47 GMT Received: from casablanca.magic.fr (casablanca.magic.fr [195.154.101.81]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA22202 for ; Sat, 18 Dec 1999 17:37:37 GMT Received: from mail.magic.fr (Pallando@ppp-216.net10.magic.fr [195.154.128.216]) by casablanca.magic.fr (8.8.8/8.8.8) with SMTP id BAA10877 for ; Sun, 19 Dec 1999 01:50:04 +0100 (MET) From: MONTAGNAT =?iso-8859-1?Q?Cl=E9ment?= Reply-To: clmontagnat@magic.fr To: vsta@zendo.com Date: Sun, 19 Dec 1999 01:49:20 +0100 Message-ID: X-Mailer: YAM 2.0Preview7 [020] - Amiga Mailer by Marcel Beck - http://www.yam.ch Subject: Hello! MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I have an Amiga 68030 an d i want to test VSTa. How can i do it please? thanks -- = MONTAGNAT Cl=E9ment Pallando IRCNet channels AmigaFR et ArtBas ICQ UIN: 26516207 From daemon Sun Dec 19 09:20:21 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA23339 for vsta-xplod; Sun, 19 Dec 1999 09:20:21 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA23333 for ; Sun, 19 Dec 1999 09:20:17 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA23481; Sun, 19 Dec 1999 08:32:21 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00255; Sun, 19 Dec 1999 08:32:16 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912191632.IAA00255@vandys-pc.vandys.cisco.com> To: clmontagnat@magic.fr cc: vsta@zendo.com Subject: Re: Hello! In-reply-to: Your message of "Sun, 19 Dec 1999 01:49:20 +0100." Reply-to: vandys@cisco.com Date: Sun, 19 Dec 1999 08:32:16 -0800 From: Andy Valencia [MONTAGNAT =?iso-8859-1?Q?Cl=E9ment?= writes:] > Hello, >I have an Amiga 68030 an d i want to test VSTa. How can i do it please? Amiga is very much out of date, and was never more than a "for hardy souls only" type of port. Given that, if you know Amiga internals and 68030, the starting point is the files in v1.5.2/amiga.tz. If somebody could get this all running in an Amiga emulator, I might even be interested in maintaining it on an ongoing basis. It would be a good way to keep VSTa honestly portable. Regards, Andy Valencia From daemon Sun Dec 19 18:00:04 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA24004 for vsta-xplod; Sun, 19 Dec 1999 18:00:04 GMT Received: from lh2.rdc1.bc.home.com (ioracle@ha2.rdc1.bc.wave.home.com [24.2.10.67]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA23982 for ; Sun, 19 Dec 1999 17:59:58 GMT Received: from cr983598-a.poco1.bc.wave.home.com ([24.113.125.239]) by lh2.rdc1.bc.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <19991220011231.TNUZ19112.lh2.rdc1.bc.home.com@cr983598-a.poco1.bc.wave.home.com>; Sun, 19 Dec 1999 17:12:31 -0800 From: Vince Hodges MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14429.33421.7168.92937@cr983598-a.poco1.bc.wave.home.com> Date: Sun, 19 Dec 1999 17:12:45 -0800 (PST ) To: vandys@cisco.com Cc: clmontagnat@magic.fr, vsta@zendo.com Subject: Re: Hello! In-Reply-To: <199912191632.IAA00255@vandys-pc.vandys.cisco.com> References: <199912191632.IAA00255@vandys-pc.vandys.cisco.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) >>>>> "Andy" == Andy Valencia writes: Andy> [MONTAGNAT =?iso-8859-1?Q?Cl=E9ment?= Andy> writes:] >> Hello, I have an Amiga 68030 an d i want to test VSTa. How can >> i do it please? Andy> Amiga is very much out of date, and was never more than a Andy> "for hardy souls only" type of port. Given that, if you Andy> know Amiga internals and 68030, the starting point is the Andy> files in v1.5.2/amiga.tz. Andy> If somebody could get this all running in an Amiga emulator, Andy> I might even be interested in maintaining it on an ongoing Andy> basis. It would be a good way to keep VSTa honestly Andy> portable. Unfortunately, AFAIK, none of the current Amiga emulators emulate the MMU, so this isn't possible (even if I did have the time :) -- Vince Hodges "Beware geeks bearing diffs" vhodges@home.com http://members.home.com/vhodges/ From daemon Mon Dec 20 11:23:20 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA25078 for vsta-xplod; Mon, 20 Dec 1999 11:23:20 GMT Received: from koto.qnet.com (koto.qnet.com [207.155.37.7]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA25059; Mon, 20 Dec 1999 11:22:34 GMT Received: from SARAH (56k-palm-02-44.dial.qnet.com [209.221.196.155]) by koto.qnet.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-54999U700L2S100V35) with SMTP id AAA5303; Mon, 20 Dec 1999 10:35:07 -0800 Message-ID: <013301bf4b18$03c7d770$31c4ddd1@SARAH> From: "Heredity Choice" To: , References: <199912200001.AAA24316@bodhi.zendo.com> Subject: Re: PCI Date: Mon, 20 Dec 1999 10:27:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 > First thing is to get VSTa current with all those PCI systems--before ISA > disappears and VSTa can't be run on modern systems! I understand the difficulty with adding PCI to VSTa is the BIOS of the Intel platform having been written for a macrokernel. WindowsNT (pardon the obscenity) supports PCI on a microkernel. If you throw enough code at the problem, you can do anything. Would the PowerPC G4 or the AlphaPC provide a friendlier platform for a PCI enabled VSTa? Does anybody have an opinion on garbage collection as seen in Inferno and Oberon? Paul Smith From daemon Wed Dec 22 00:00:26 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA27403 for vsta-xplod; Wed, 22 Dec 1999 00:00:26 GMT Received: from mail6.fw-sj.sony.com (mail6.fw-sj.sony.com [198.93.2.28]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id XAA27381 for ; Tue, 21 Dec 1999 23:58:03 GMT Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail6.fw-sj.sony.com (8.8.8/8.8.8) with ESMTP id HAA04439 for ; Wed, 22 Dec 1999 07:10:13 GMT Received: by mail2.sjc.in.sel.sony.com id HAA21592; Wed, 22 Dec 1999 07:10:13 GMT Received: by tannoudji.arch.sel.sony.com (8.8.8+Sun/SMI-SVR4) id XAA03104; Tue, 21 Dec 1999 23:10:13 -0800 (PST) Date: Tue, 21 Dec 1999 23:10:13 -0800 (PST) From: bwitt@arch.sel.sony.com (Brian Witt) Message-Id: <199912220710.XAA03104@tannoudji.arch.sel.sony.com> To: VSTa@zendo.com Subject: Re: PCI > From: "Heredity Choice" > > > First thing is to get VSTa current with all those PCI systems--before ISA > > disappears and VSTa can't be run on modern systems! From what I've seen of PCI, the IDE hard disk and VGA video will always be where they are. Keyboard and floppy won't move for many decades. However, the network cards are moving to PCI and bus mastering, and using them is what you lose by not having PCI. > I understand the difficulty with adding PCI to VSTa is the BIOS of the Intel > platform having been written for a macrokernel. WindowsNT (pardon the > obscenity) supports PCI on a microkernel. If you throw enough code at the > problem, you can do anything. > > Would the PowerPC G4 or the AlphaPC provide a friendlier platform for a PCI > enabled VSTa? I looked at the FreeBSD and Linux PCI manager code and from them wrote my own. There isn't that much to it. My code (also) walks the buses and adapters and functions looking for something. Devices register their manufactorer ID and product number and are called back at the right moment. It is enough to init a 3Com 3C905B NIC card. My code assumes CPU addr == bus address, which is only true for Intel PCI systems. Not true for PowerPC and Alpha. This code runs inside a protected mode system (not enough code to call it an OS, yet). It's a school project, and I use the UIUC BOOT.COM program (thanx to Brian S.). If people are interested I can separate out the code. Right now is buried inside a tarball. > Paul Smith ============ brian witt (SJ2C6) bwitt@arch.sel.sony.com Sony US Research, Distributed Systems Lab, USA 408-955-3021 "Capitalism has taken over at the expense of democracy." From daemon Wed Dec 22 08:22:41 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA28031 for vsta-xplod; Wed, 22 Dec 1999 08:22:41 GMT Received: from mumble.frotz.net (anonymous@mumble.frotz.net [216.15.97.250]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id IAA28009 for ; Wed, 22 Dec 1999 08:22:08 GMT Received: (qmail 61258 invoked by uid 1000); 22 Dec 1999 15:35:30 -0000 Date: Wed, 22 Dec 1999 07:35:30 -0800 From: "Brian J. Swetland" To: Heredity Choice Cc: VSTa@zendo.com, vsta-digest@zendo.com Subject: Re: PCI Message-ID: <19991222073530.A61221@frotz.net> References: <199912200001.AAA24316@bodhi.zendo.com> <013301bf4b18$03c7d770$31c4ddd1@SARAH> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <013301bf4b18$03c7d770$31c4ddd1@SARAH>; from Heredity Choice on Mon, Dec 20, 1999 at 10:27:50AM -0800 Organization: Frotz Communications, Ltd. X-Mailer-Holy-War: Get Mutt, it bites! [Heredity Choice ] > > First thing is to get VSTa current with all those PCI systems--before ISA > > disappears and VSTa can't be run on modern systems! > > I understand the difficulty with adding PCI to VSTa is the BIOS of the Intel > platform having been written for a macrokernel. WindowsNT (pardon the > obscenity) supports PCI on a microkernel. If you throw enough code at the > problem, you can do anything. It depends how you want to handle it. Basic PCI support -- being able to get information about the existing PCI devices, IO ranges, etc on typical Pentium and above chipsets is not too hard. You don't need to make BIOS calls to touch PCI configuration space (BeOS, FreeBSD, etc don't). Mostly the issue is how do you want to provide this information to things that need it -- do they communicate with a PCI server to look for and reserve resources? I don't have the spec handy (but it's available in the chipset docs on Intel's developer site), but here's the common way to read/write PCI config space: typedef struct { uchar reg:8; uchar func:3; uchar dev:5; uchar bus:8; uchar rsvd:7; uchar enable:1; } confadd; uint32 read_pci(int bus, int dev, int func, int reg, int bytes) { uint32 base = 0xCFC + (reg & 0x03); union { confadd c; uint32 n; } u; u.c.enable = 1; u.c.rsvd = 0; u.c.bus = bus; u.c.dev = dev; u.c.func = func; u.c.reg = reg & 0xFC; outl(u.n,0xCF8); switch(bytes){ case 1: return inb(base); case 2: return inw(base); case 4: return inl(base); default: return 0; } } void write_pci(int bus, int dev, int func, int reg, uint32 v, int bytes) { uint32 base = 0xCFC + (reg & 0x03); union { confadd c; uint32 n; } u; u.c.enable = 1; u.c.rsvd = 0; u.c.bus = bus; u.c.dev = dev; u.c.func = func; u.c.reg = reg & 0xFC; outl(u.n,0xCF8); switch(bytes){ case 1: outb(v,base); break; case 2: outw(v,base); break; case 4: outl(v,base); break; } } Brian From daemon Wed Dec 22 08:31:04 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA28061 for vsta-xplod; Wed, 22 Dec 1999 08:31:04 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA28042 for ; Wed, 22 Dec 1999 08:30:59 GMT Received: from endymion ([198.112.115.44]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id KAA07142 for ; Wed, 22 Dec 1999 10:43:45 -0500 (EST) Reply-To: From: "Gavin Thomas Nicol" To: Subject: RE: PCI Date: Wed, 22 Dec 1999 10:37:30 -0500 Message-ID: <002301bf4c92$76024660$2c7370c6@ebt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <199912220710.XAA03104@tannoudji.arch.sel.sony.com> Importance: Normal > This code runs inside a protected mode system (not enough code to > call it an OS, yet). It's a school project, and I use the UIUC > BOOT.COM program (thanx to Brian S.). If people are interested I > can separate out the code. Right now is buried inside a tarball. It'd be good to get PCI support in, so this might well be worthwhile. From daemon Wed Dec 22 16:29:50 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA28762 for vsta-xplod; Wed, 22 Dec 1999 16:29:50 GMT Received: from proxy.iluka.com (proxy.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA28743 for ; Wed, 22 Dec 1999 16:29:07 GMT Received: from perntexc01.iluka.com ([203.13.208.1]) by proxy.iluka.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 23 Dec 1999 07:36:43 +0800 Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Dec 1999 07:47:21 +0800 Message-ID: From: "Dines, Eric" To: "'vsta@zendo.com'" Subject: RE: PCI Date: Thu, 23 Dec 1999 07:45:15 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > > I looked at the FreeBSD and Linux PCI manager code and from them > wrote my own. There isn't that much to it. My code (also) walks > the buses and adapters and functions looking for something. > Devices register their manufactorer ID and product number and are > called back at the right moment. It is enough to init a 3Com 3C905B > NIC card. > > My code assumes CPU addr == bus address, which is only true for > Intel PCI systems. Not true for PowerPC and Alpha. > > This code runs inside a protected mode system (not enough code to > call it an OS, yet). It's a school project, and I use the UIUC > BOOT.COM program (thanx to Brian S.). If people are interested I > can separate out the code. Right now is buried inside a tarball. I think that sounds great. What about the 16 mb RAM limitation that we are currently working with? regards Eric esd@deakin.edu.au ------------------------------------------------------------------------- From daemon Thu Dec 23 12:53:07 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA00303 for vsta-xplod; Thu, 23 Dec 1999 12:53:07 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA00297 for ; Thu, 23 Dec 1999 12:53:00 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA14206; Thu, 23 Dec 1999 12:05:07 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id MAA00510; Thu, 23 Dec 1999 12:05:00 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912232005.MAA00510@vandys-pc.vandys.cisco.com> To: "Dines, Eric" cc: "'vsta@zendo.com'" Subject: Re: PCI In-reply-to: Your message of "Thu, 23 Dec 1999 07:45:15 +0800." Reply-to: vandys@cisco.com Date: Thu, 23 Dec 1999 12:04:59 -0800 From: Andy Valencia ["Dines, Eric" writes:] >What about the 16 mb RAM limitation that we are currently working with? I implemented bounce buffers a while back, and removed the 16M cap at that time. I need to handle one degenerate case which Eric Jacobs found a while back, but nobody should hit that unless they're doing something like debugging the floppy driver. Andy From daemon Thu Dec 30 20:23:51 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id UAA13939 for vsta-xplod; Thu, 30 Dec 1999 20:23:51 GMT Received: from mail.hdc.com.au ([203.57.31.2]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id UAA13920 for ; Thu, 30 Dec 1999 20:23:41 GMT Received: from mycomputer (unverified [203.57.31.143]) by mail.hdc.com.au (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 31 Dec 1999 14:36:10 +1100 Message-ID: <001101bf533f$9dc2d620$8f1f39cb@mycomputer> From: =?iso-8859-1?B?RXJpayBEYWzpbg==?= To: Subject: Cluster Date: Fri, 31 Dec 1999 14:25:01 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 can VSTa become a cluster? If not will it be implemented in the future? /Erik From daemon Fri Dec 31 11:18:05 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA14872 for vsta-xplod; Fri, 31 Dec 1999 11:18:05 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA14863 for ; Fri, 31 Dec 1999 11:14:15 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA16485; Fri, 31 Dec 1999 10:26:59 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00301; Fri, 31 Dec 1999 10:26:48 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <199912311826.KAA00301@vandys-pc.vandys.cisco.com> To: erik@jpl.nu cc: vsta@zendo.com Subject: Re: Cluster In-reply-to: Your message of "Fri, 31 Dec 1999 14:25:01 +1100." <001101bf533f$9dc2d620$8f1f39cb@mycomputer> Reply-to: vandys@cisco.com Date: Fri, 31 Dec 1999 10:26:48 -0800 From: Andy Valencia [ writes:] >can VSTa become a cluster? If not will it be implemented in the future? It depends what you mean by "a cluster". Any VSTa message-based service on a node running "proxyd" (in src/srv/ka9q/cmd) can be mounted from any other node, and then the service accessed as if it was local. This includes consoles, filesystems, disks, serial ports, and /proc. Process creation probably needs to be converted to using message primitives, so that you can create processes on arbitrary nodes (interestingly, QNX4 offers this, but Quantum's next generation OS, Neutrino, does not (yet)). I suspect process migration is not worth pursuing. Does this make a VSTa cluster? Probably not. But it offers the critical building blocks which I believe can be used to construct a cluster. Andy Valencia From daemon Fri Dec 31 18:04:33 1999 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA15373 for vsta-xplod; Fri, 31 Dec 1999 18:04:33 GMT Received: from ns1.usxc.net (ns1.usxc.net [216.47.224.66]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA15354 for ; Fri, 31 Dec 1999 18:04:25 GMT Received: from debian ([216.47.231.198]) by ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA3BD1 for ; Fri, 31 Dec 1999 20:17:33 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp (ident erdost using rfc1413) id (Debian Smail3.2.0.102) for ; Fri, 31 Dec 1999 19:29:49 +0000 (GMT) Sender: erdost@usxc.net Message-ID: <386D0424.64E4E56C@usxchange.net> Date: Fri, 31 Dec 1999 19:29:40 +0000 From: "Thomas J. Erdos" X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Happy New Year Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Happy New Year to all of you on this list and let's do some more work on VSTa in the next year. Thomas From daemon Mon Jan 3 00:04:48 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA20967 for vsta-xplod; Mon, 3 Jan 2000 00:04:48 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id AAA20961 for ; Mon, 3 Jan 2000 00:04:43 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA20580; Sun, 2 Jan 2000 23:17:35 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id XAA00302; Sun, 2 Jan 2000 23:17:23 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200001030717.XAA00302@vandys-pc.vandys.cisco.com> To: Pavel Machek cc: erik@jpl.nu, vsta@zendo.com Subject: Re: Cluster In-reply-to: Your message of "Sat, 01 Jan 2000 21:40:40 +0100." <20000101214040.H257@bug.ucw.cz> Reply-to: vandys@cisco.com Date: Sun, 02 Jan 2000 23:17:23 -0800 From: Andy Valencia [Pavel Machek writes:] >> >can VSTa become a cluster? If not will it be implemented in the future? >> It depends what you mean by "a cluster". >>... >> Process creation >> probably needs to be converted to using message primitives, so that you can >> create processes on arbitrary nodes (interestingly, QNX4 offers this, but >> Quantum's next generation OS, Neutrino, does not (yet)). >Can you do at least "on-exec" migration? The quoted part of my answer applies to this. The answer is "no" (for now). Note that "exec" time is a bad point to migrate, since it implies a lot of inherited fork() environment. The POSIX spawn*() concept is much friendlier, since the new environment has a much more structured set of initial values. Andy From daemon Mon Jan 17 14:36:12 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA16556 for vsta-xplod; Mon, 17 Jan 2000 14:36:12 GMT Received: from malasada.lava.net (malasada.lava.net [199.222.42.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id OAA16533 for ; Mon, 17 Jan 2000 14:32:12 GMT Received: from localhost (1457 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Mon, 17 Jan 2000 11:46:04 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Dec-7) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: Re: Hello! To: clmontagnat@magic.fr Date: Mon, 17 Jan 2000 11:46:04 -1000 (HST) Cc: vsta@zendo.com In-Reply-To: from "MONTAGNAT =?iso-8859-1?Q?Cl=E9ment?=" at Dec 19, 99 01:49:20 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Hello, > I have an Amiga 68030 an d i want to test VSTa. How can i do it please? > thanks Hi, I did the amiga work. It is still in quite a primitive state. Its not something you can just compile and run. For example, the boot loader I used had some information about my set up hard wired into it I believe. The kernel ran well enough to run the testsh at boot up. I was able to get the cam driver to work for my particular scsi card, and run programs from the testsh. The system did have some bug in it that caused it to crash after running for a short period of time [something like a few minutes]. If you are serious about playing with the amiga code, I would be more than happy to answer any questions you have and go over my old code to refresh my memory and make a list of things you will have to do. I do not have access to an amiga (or any 680x0) system, however. > MONTAGNAT Cl=E9ment > Pallando Tim N. From daemon Wed Feb 23 05:59:13 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA02196 for vsta-xplod; Wed, 23 Feb 2000 05:59:13 GMT Received: from mail.hdc.com.au ([203.57.31.2]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id FAA02177 for ; Wed, 23 Feb 2000 05:59:00 GMT Received: from default (unverified [203.57.31.128]) by mail.hdc.com.au (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 24 Feb 2000 00:14:41 +1100 Message-ID: <001301bf7dff$ded9a040$801f39cb@default> From: =?iso-8859-1?Q?Erik_Dal=E9n?= To: Subject: Startup problems Date: Thu, 24 Feb 2000 00:12:41 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 when I try to start VSTa init says that it can't load inittab even though inittab is there. I'm running it on a 420 mb ide harddisk, dos partition. everything else seems to work fine. tips anyone? /Erik From daemon Wed Feb 23 08:59:29 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id IAA02410 for vsta-xplod; Wed, 23 Feb 2000 08:59:29 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id IAA02404 for ; Wed, 23 Feb 2000 08:59:09 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA00369; Wed, 23 Feb 2000 08:14:57 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id IAA00292; Wed, 23 Feb 2000 08:14:21 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200002231614.IAA00292@vandys-pc.vandys.cisco.com> To: erik@jpl.nu cc: vsta@zendo.com Subject: Re: Startup problems In-reply-to: Your message of "Thu, 24 Feb 2000 00:12:41 +1100." <001301bf7dff$ded9a040$801f39cb@default> Reply-to: vandys@cisco.com Date: Wed, 23 Feb 2000 08:14:21 -0800 From: Andy Valencia [=?iso-8859-1?Q?Erik_Dal=E9n?= writes:] >when I try to start VSTa init says that it can't load inittab even though >inittab is there. I'm running it on a 420 mb ide harddisk, dos partition. >everything else seems to work fine. >tips anyone? /vsta/etc/inittab is pretty much the first file which a boot module will try to find, so likely there's a mismatch going on here. I assume you saw the IDE (wd) and DOS servers come up? Do you have more than one DOS partition? Did you put inittab in /vsta/etc (sometimes people accidentally extract into some other pathname)? Andy From daemon Thu Feb 24 00:34:48 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA03490 for vsta-xplod; Thu, 24 Feb 2000 00:34:48 GMT Received: from mail.hdc.com.au ([203.57.31.2]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id AAA03460 for ; Thu, 24 Feb 2000 00:30:48 GMT Received: from default (unverified [203.57.31.122]) by mail.hdc.com.au (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 24 Feb 2000 18:45:54 +1100 Message-ID: <003d01bf7e9b$1e5e7240$7a1f39cb@default> From: =?iso-8859-1?Q?Erik_Dal=E9n?= To: "VSTa Mailinglist" Subject: re: Startup problems Date: Thu, 24 Feb 2000 18:45:27 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > I tried to start testsh instead of init and then it booted and I could run > some binaries. but if I tried to do a ls or a cat of a file it only said "no > entry" > could that be because the testsh wrote to //cons:1 and the commands had no /dev/cons to write to? From daemon Thu Feb 24 05:03:17 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id FAA03933 for vsta-xplod; Thu, 24 Feb 2000 05:03:17 GMT Received: from mail.hdc.com.au ([203.57.31.2]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id FAA03914 for ; Thu, 24 Feb 2000 05:00:30 GMT Received: from default (unverified [203.57.31.89]) by mail.hdc.com.au (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 24 Feb 2000 23:15:40 +1100 Message-ID: <000e01bf7ec0$cb40b7a0$591f39cb@default> From: =?iso-8859-1?Q?Erik_Dal=E9n?= To: "VSTa Mailinglist" Subject: more on startup problem Date: Thu, 24 Feb 2000 23:12:20 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 I tried to fiddle around with the testsh a bit more and it seems fairly obvious that the root filesystem is not mounted. should init normally do this job? anyway I mounted //fs/root and got two vsta directories but when I tried to check the contents it was empty. the GRUB commands I used where root=(hd0,0) kernel=/vsta/boot/vsta module=/vtsa/boot/cons module=/vsta/boot/namer module=/vsta/boot/wd d0:readp module=/vsta/boot/dos -d //disk/wd:wd0_dos0 -n fs/root module=/vsta/boot/init boot then init complained that it couldn't find inittab so I also tried with testsh instead of init and then the root filesystem wasn't mounted but I only got those empty directories when I tried to mount it. and by the way, is it necessary to have vsta in a folder called vsta? (I do but as I don't have anything else on the harddisk at the moment it feels unnecessary) /Erik From daemon Thu Mar 2 11:30:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA19713 for vsta-xplod; Thu, 2 Mar 2000 11:30:46 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA19707 for ; Thu, 2 Mar 2000 11:30:43 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA06476 for ; Thu, 2 Mar 2000 10:46:24 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id KAA00788 for ; Thu, 2 Mar 2000 10:46:23 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200003021846.KAA00788@vandys-pc.vandys.cisco.com> To: vsta@zendo.com Subject: Potential installation problem Reply-to: vandys@cisco.com Date: Thu, 02 Mar 2000 10:46:22 -0800 From: Andy Valencia Hello, folks. I've begun hacking on the DOS filesystem to support FAT-32. The way it supported FAT-12/16 was really a hack, so I'm trying to really clean up the support for different FAT formats. As a part of this, I realized that not only does the server not support an increasingly common filesystem format, but it has no clear error check to catch it (I *thought* it did, but I've now realized that there are legal FAT-32 filesystems which will slip through). For my current test FAT-32 filesystem, the symptom is that the filesystem mounts up, but appears empty. So if you're having trouble with, say, inittab's which can't be found, this may be the culprit. WWW site installation tutorial updated. Hopefully I can push out a new release with FAT-32 support shortly. BTW... stay tuned for a mid-April announcement on this list. :-> Regards, Andy Valencia From daemon Mon Mar 6 19:35:00 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA29368 for vsta-xplod; Mon, 6 Mar 2000 19:35:00 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA29346 for ; Mon, 6 Mar 2000 19:34:50 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id DAA25440; Tue, 7 Mar 2000 03:51:30 +0100 Date: Tue, 7 Mar 2000 03:51:30 +0100 (CET) From: Erik Dalen To: Andy Valencia cc: vsta@zendo.com Subject: Re: Potential installation problem In-Reply-To: <200003021846.KAA00788@vandys-pc.vandys.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Mar 2000, Andy Valencia wrote: > Hello, folks. > > I've begun hacking on the DOS filesystem to support FAT-32. The way it > supported FAT-12/16 was really a hack, so I'm trying to really clean up the > support for different FAT formats. > actually wouldn't it be better to fix up the ext2fs driver to really work as ext2fs is probably better than FAT-32? > As a part of this, I realized that not only does the server not support an > increasingly common filesystem format, but it has no clear error check to > catch it (I *thought* it did, but I've now realized that there are legal > FAT-32 filesystems which will slip through). For my current test FAT-32 > filesystem, the symptom is that the filesystem mounts up, but appears empty. > So if you're having trouble with, say, inittab's which can't be found, this > may be the culprit. > I found the problem. It wasn't FAT-32 but as I said there was 2 vsta folders, and they where both of type f?!? so I removed one of them and then the other one changed to type d and then it all worked. The mkdir I used was from DOS 6.22 > WWW site installation tutorial updated. Hopefully I can push out a new > release with FAT-32 support shortly. > I'm already looking forward to it :) > BTW... stay tuned for a mid-April announcement on this list. :-> > > Regards, > Andy Valencia > /Erik From daemon Tue Mar 7 10:11:41 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id KAA00411 for vsta-xplod; Tue, 7 Mar 2000 10:11:41 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id KAA00398 for ; Tue, 7 Mar 2000 10:11:36 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA01448; Tue, 7 Mar 2000 09:27:33 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00480; Tue, 7 Mar 2000 09:27:30 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200003071727.JAA00480@vandys-pc.vandys.cisco.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: Potential installation problem In-reply-to: Your message of "Tue, 07 Mar 2000 03:51:30 +0100." Reply-to: vandys@cisco.com Date: Tue, 07 Mar 2000 09:27:30 -0800 From: Andy Valencia [Erik Dalen writes:] >> I've begun hacking on the DOS filesystem to support FAT-32. The way it >> supported FAT-12/16 was really a hack, so I'm trying to really clean up the >> support for different FAT formats. >actually wouldn't it be better to fix up the ext2fs driver to really work >as ext2fs is probably better than FAT-32? It depends. If my goal was to work on a better filesystem, then yes, ext2fs is in almost all ways a better filesystem. But if my goal is to support the most widely adopted filesystem, then the FAT filesystem wins hands down. Many systems with ext2fs as their primary filesystem also have a FAT partition. But virtually no systems with a primary FAT filesystem have ext2fs. So keeping my FAT support current seems like a prudent investment in "keeping the doors open". >I found the problem. It wasn't FAT-32 but as I said there was 2 vsta >folders, and they where both of type f?!? so I removed one of them and >then the other one changed to type d and then it all worked. The mkdir I >used was from DOS 6.22 Huh. Wonder how you managed that? Glad you got it straightened out. Andy From daemon Thu Mar 9 09:46:39 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id JAA03832 for vsta-xplod; Thu, 9 Mar 2000 09:46:39 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id JAA03826 for ; Thu, 9 Mar 2000 09:46:30 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA29198 for ; Thu, 9 Mar 2000 09:02:34 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id JAA00489 for ; Thu, 9 Mar 2000 09:02:30 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> To: vsta@zendo.com Subject: VSTa update Reply-to: vandys@cisco.com Date: Thu, 09 Mar 2000 09:02:30 -0800 From: Andy Valencia Hello, Just a little update on stuff I'm doing on VSTa. FAT32 is looking good; I'm on hold for GNU GRUB to release a version with some critical fixes for *their* FAT32 support, after which I can test a fully native system and check in my work. I'm still thinking about a port of Squeak to VSTa. In preparation for that, I've done an implementation of select(), and have that working as of yesterday evening. It looks like a server which supports select() will need to add around 50 lines of code, plus I had to implement a "selfs" server to manage all the common state. The good news is that the underlying message model required no changes, so select() required no kernel modifications, and will work over distributed messaging just fine. Viva microkernels! I'm still looking for a good graphics library to control video hardware. When I port Squeak, it's easy enough to support one of the base SVGA modes (I'll just copy the code from my MGR port). But it'd be nice to support the extended resolution (and hardware blit support) of modern video cards. I was told a while ago that libsvga was dead, but I seem to see a lot of activity with respect to it on the Linux lists. It's the closes thing, philosophically, to what I'd like to use. Can anybody with a deeper understanding give me some guidance? Thanks, Andy Valencia From daemon Fri Mar 10 00:49:56 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id AAA05030 for vsta-xplod; Fri, 10 Mar 2000 00:49:56 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id AAA05011 for ; Fri, 10 Mar 2000 00:49:51 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id JAA05122 for ; Fri, 10 Mar 2000 09:07:14 +0100 Date: Fri, 10 Mar 2000 09:07:13 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: Re: VSTa update In-Reply-To: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Mar 2000, Andy Valencia wrote: > Hello, > > Just a little update on stuff I'm doing on VSTa. FAT32 is looking good; > I'm on hold for GNU GRUB to release a version with some critical fixes for > *their* FAT32 support, after which I can test a fully native system and > check in my work. > sounds nice, keep up the good work :) > I'm still thinking about a port of Squeak to VSTa. In preparation for that, > I've done an implementation of select(), and have that working as of > yesterday evening. It looks like a server which supports select() will need > to add around 50 lines of code, plus I had to implement a "selfs" server to > manage all the common state. The good news is that the underlying message > model required no changes, so select() required no kernel modifications, and > will work over distributed messaging just fine. Viva microkernels! > personally I would prefer a port of Berlin to VSTa instead, as it seems to be a very promising windowing system that is language independent and extensible. (http://www.berlin-consortium.org) It is at the moment in a very early state and a lot of other stuff would need to be ported first, (Mesa, libGGI, OmniORB). That's just my opinion but check it out anyway, I think it seems to have a lot better architecture than Squeak. > I'm still looking for a good graphics library to control video hardware. > When I port Squeak, it's easy enough to support one of the base SVGA modes > (I'll just copy the code from my MGR port). But it'd be nice to support the > extended resolution (and hardware blit support) of modern video cards. I > was told a while ago that libsvga was dead, but I seem to see a lot of > activity with respect to it on the Linux lists. It's the closes thing, > philosophically, to what I'd like to use. Can anybody with a deeper > understanding give me some guidance? > wouldn't it be nice to code graphics servers that provide a bitblt file like in plan 9? I could try to code a vga one if you others think it's a good idea. But should the protocol then be the same as in plan 9? I think that it would be better to put the font support in some sort of library. And the plan 9 bitblt protocol doesn't seem to be able to adjust to multihead systems very well, if one is designed now it's best to include support for that from ground up. The best way to accomplish that would probaly be to have some sort of display manager server that takes control of all the bitblt files and then gives one out to the applications. I'm from the Amiga community and I think that it should include an amiga style screen switcher instead of unix style one. for you that doesn't know how it works on amiga. The virtual screens are put in a list and applications can open new ones and close their screens and there is always the "default screen", instead of the unix way where it is a fixed number and can neither be increased or decreased by applications. but that might be something for the window system to take care of, but I think it would be nice to have it on the virtual consoles so that you just start with one console and then if you want new ones you type "newcons" or something like that and then when they exit they close their screens. And also the amiga switches between the screen by shifting to the next one in the list with one key combination and switching to the first one with one key combination. And all screens can have different resolutions. > Thanks, > Andy Valencia > /Erik From daemon Fri Mar 10 01:57:05 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id BAA05118 for vsta-xplod; Fri, 10 Mar 2000 01:57:05 GMT Received: from malasada.lava.net (malasada.lava.net [199.222.42.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id BAA05099 for ; Fri, 10 Mar 2000 01:57:01 GMT Received: from localhost (1853 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Thu, 9 Mar 2000 23:13:32 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Dec-7) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: Re: VSTa update To: erik@jpl.nu (Erik Dalen) Date: Thu, 9 Mar 2000 23:13:31 -1000 (HST) Cc: vsta@zendo.com In-Reply-To: from "Erik Dalen" at Mar 10, 0 09:07:13 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > And the plan 9 bitblt protocol doesn't seem to be able to adjust to > multihead systems very well, if one is designed now it's best to include > support for that from ground up. The best way to accomplish that would From what I read about QNX and photon, it sounds like they had a very nice way of handling this. You have this display space and graphics events are sent through the display space as messages. The displays are then just regions in this space. Graphical events that happen to intersect the displays area of interest are clipped to the region and passed to the display. In this way you can have any number of displays attached to your session by just putting them into the graphical of your session. You could have them overlapping (in which case some events would show up in both displays), next to each other, or seperated. Or you could have two graphical displays showing data from seperate graphical spaces. In this model you can easily do things like slip a remote viewer over your displays area to allow someone else to see what you see, or just over a particular window. You could display an entire window on one display while it is partially displayed on another display, but slipping the display's region directly in front of the window in question. etc.. It seems like a very powerful abstraction. > /Erik Tim N. From daemon Fri Mar 10 07:43:22 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA05544 for vsta-xplod; Fri, 10 Mar 2000 07:43:22 GMT Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA05525 for ; Fri, 10 Mar 2000 07:43:17 GMT Received: from cr983598-a.poco1.bc.wave.home.com ([24.113.125.239]) by mail.rdc2.bc.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <20000310145952.RNXU20542.mail.rdc2.bc.home.com@cr983598-a.poco1.bc.wave.home.com>; Fri, 10 Mar 2000 06:59:52 -0800 From: Vince Hodges MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14537.4197.55262.780364@cr983598-a.poco1.bc.wave.home.com> Date: Fri, 10 Mar 2000 07:10:29 -0800 (PST ) To: vandys@cisco.com Cc: vsta@zendo.com Subject: VSTa update In-Reply-To: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> References: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) >>>>> "Andy Valencia" == Andy Valencia writes: Andy Valencia> I'm still looking for a good graphics library to Andy Valencia> control video hardware. When I port Squeak, it's Andy Valencia> easy enough to support one of the base SVGA modes Andy Valencia> (I'll just copy the code from my MGR port). But Andy Valencia> it'd be nice to support the extended resolution Andy Valencia> (and hardware blit support) of modern video cards. Andy Valencia> I was told a while ago that libsvga was dead, but I Andy Valencia> seem to see a lot of activity with respect to it on Andy Valencia> the Linux lists. It's the closes thing, Andy Valencia> philosophically, to what I'd like to use. Can Andy Valencia> anybody with a deeper understanding give me some Andy Valencia> guidance? Hi Andy, According to the svgalib home page, http://www.svgalib.org/ it's not dead yet and probably not for some time. http://microwindows.censoft.com/ is a low level graphics lib and windowing toolkit that is small and has been ported to a number of platforms. svgalib can be used as a graphics driver. Alternative windowing systems (just FYI). http://yax.netpedia.net/ http://personal.eunet.fi/pp/wisio/ http://dinx.sourceforge.net/ And then there's always the Linux kernel frame buffer code to look at. Hope that helps in some small way. -- Vince Hodges "Beware geeks bearing diffs" vhodges@home.com http://members.home.com/vhodges/ From daemon Fri Mar 10 15:36:35 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id PAA06534 for vsta-xplod; Fri, 10 Mar 2000 15:36:35 GMT Received: from mozart.chat.net (qmailr@adsl-216-103-193-237.dsl.snfc21.pacbell.net [216.103.193.237]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id PAA06515 for ; Fri, 10 Mar 2000 15:36:29 GMT Received: (qmail 19862 invoked by uid 120); 10 Mar 2000 23:08:54 -0000 Date: Fri, 10 Mar 2000 15:08:54 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: VSTa update Message-ID: <20000310150854.N11267@mozart.chat.net> Mail-Followup-To: vsta@zendo.com References: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> On Thu, Mar 09, 2000 at 09:02:30AM -0800, Andy Valencia wrote: > I'm still looking for a good graphics library to control video hardware. svgalib and LinuxGGI seem the two most appropriate. www.ggi-project.org If you can make GGI work, it would have many advantages, including: - it supports svgalib emulation - there is an X-GGI port of X-Windows to GGI - it supports more advanced hardware acceleration features such as hardware accelerated 2d blits - It has a "proper" video driver model I looked into it a while back and thought that the kernel portion of LinuxGGI would fit nicely into a VSTa server. (it basically arbitrates access to the video hardware so applications don't need root/sys.sys access to control the screen) The biggest drawback of GGI (IMO) is that it's not part of the Linux mainstream yet. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Fri Mar 10 17:40:14 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA06822 for vsta-xplod; Fri, 10 Mar 2000 17:40:14 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA06816 for ; Fri, 10 Mar 2000 17:40:08 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA19391; Fri, 10 Mar 2000 16:56:13 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id QAA01084; Fri, 10 Mar 2000 16:56:12 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200003110056.QAA01084@vandys-pc.vandys.cisco.com> To: David Jeske cc: vsta@zendo.com Subject: Re: VSTa update In-reply-to: Your message of "Fri, 10 Mar 2000 15:08:54 PST." <20000310150854.N11267@mozart.chat.net> Reply-to: vandys@cisco.com Date: Fri, 10 Mar 2000 16:56:11 -0800 From: Andy Valencia [David Jeske writes:] >I looked into it a while back and thought that the kernel portion of >LinuxGGI would fit nicely into a VSTa server. (it basically arbitrates >access to the video hardware so applications don't need root/sys.sys >access to control the screen) The problem I had was that I couldn't find any graphics hardware support in it; it appeared to depend on the Linux kernel FB support. And *that* stuff looked pretty deeply embedded in the kernel. To the extent that svgalib looked much easier to adopt. Has this changed? Andy From daemon Fri Mar 10 21:47:44 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA07110 for vsta-xplod; Fri, 10 Mar 2000 21:47:44 GMT Received: from mozart.chat.net (qmailr@adsl-216-103-193-237.dsl.snfc21.pacbell.net [216.103.193.237]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id VAA07091 for ; Fri, 10 Mar 2000 21:47:24 GMT Received: (qmail 20617 invoked by uid 120); 11 Mar 2000 05:19:43 -0000 Date: Fri, 10 Mar 2000 21:19:43 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: VSTa update Message-ID: <20000310211943.O11267@mozart.chat.net> Mail-Followup-To: vsta@zendo.com References: <20000310150854.N11267@mozart.chat.net> <200003110056.QAA01084@vandys-pc.vandys.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200003110056.QAA01084@vandys-pc.vandys.cisco.com> On Fri, Mar 10, 2000 at 04:56:11PM -0800, Andy Valencia wrote: > [David Jeske writes:] > >I looked into it a while back and thought that the kernel portion of > >LinuxGGI would fit nicely into a VSTa server. (it basically arbitrates > >access to the video hardware so applications don't need root/sys.sys > >access to control the screen) > > The problem I had was that I couldn't find any graphics hardware support in > it; it appeared to depend on the Linux kernel FB support. And *that* stuff > looked pretty deeply embedded in the kernel. To the extent that svgalib > looked much easier to adopt. Has this changed? Now that I looked deeper at what they have, it does not seem far enough along to be consider a "big-win" IMO. -- Given that, however... I don't understand what you are referring to exactly. The Linux kernel FB support is just support for basic text modes. The biggest thing the Linux kernel FB stuff does is provide an API for telling user-level software to "let go" of the hardware and restore it to a known state. That's how switching virtual consoles with X works... The single biggest goal of GGI is to provide _one_ place where hardware specific drivers live, in GGI. In 1998 they released a sample implementation that had hardware support for a number of graphics cards. They now have a new implementation based on what they learned which unfortunatly only has dumb framebuffer support for four types of hardware (VGA, S3 ViRGE, Matrox G200/G400, Permidia). Acceleration support is non-existant. FYI: Here is a summary of where I understand code to live in GGI and non-GGI Linux setups. 1. non-GGI Text modes: linux kernel svgalib: card-specific userspace library X-windows: card-specific xwindows executable 2. GGI Text modes: card-specific in-kernel GGI driver svgalib: card-specific in-kernel GGI driver + svgalib-compatible userspace library X-windows: card-specific in-kernel GGI driver + generic Xggi X server -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Sat Mar 11 11:29:12 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id LAA00361 for vsta-xplod; Sat, 11 Mar 2000 11:29:12 GMT Received: from nickel.cix.co.uk (nickel.compulink.co.uk [194.153.0.18]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id LAA00342 for ; Sat, 11 Mar 2000 11:29:01 GMT Received: from RUDD.cix.co.uk (rudd.compulink.co.uk [194.153.16.14]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id TAA17943; Sat, 11 Mar 2000 19:05:25 GMT X-Envelope-From: jback@cix.co.uk From: Julian Back MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14538.38910.578000.644764@gargle.gargle.HOWL> Date: Sat, 11 Mar 2000 19:01:18 +0000 (GMT) To: vsta@zendo.com Subject: VSTa update In-Reply-To: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> References: <200003091702.JAA00489@vandys-pc.vandys.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Andy Valencia writes: > I'm still thinking about a port of Squeak to VSTa. In preparation for that, This sounds great, I'm also a Squeak fan. I'd like to see something better than the VGA support in the MGR port as I've never been able to get that working with my graphics card (Matrox Millenium II) and I suspect it also won't work with other modern graphics cards. AFAIK SVGALIB is the best way to go for this. Julian From daemon Sat Mar 11 12:52:02 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id MAA00484 for vsta-xplod; Sat, 11 Mar 2000 12:52:02 GMT Received: from Lain.ChaoticDreams.ORG (orion.jimco-fwt.com [207.136.36.232]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id MAA00465 for ; Sat, 11 Mar 2000 12:51:57 GMT Received: (from major@localhost) by Lain.ChaoticDreams.ORG (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id OAA21976 for vsta@zendo.com; Sat, 11 Mar 2000 14:28:54 -0600 Date: Sat, 11 Mar 2000 14:28:54 -0600 From: Major To: vsta@zendo.com Subject: Re: VSTa update Message-ID: <20000311142854.A21946@jimco-fwt.com> Mail-Followup-To: Major , vsta@zendo.com References: <20000310150854.N11267@mozart.chat.net> <200003110056.QAA01084@vandys-pc.vandys.cisco.com> <20000310211943.O11267@mozart.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000310211943.O11267@mozart.chat.net>; from jeske@chat.net on Fri, Mar 10, 2000 at 09:19:43PM -0800 Organization: Chaotic Dreams Development I think you have a minor misunderstanding of the FB support. The Linux kernel text attribute support is not the same as the framebuffer. The Kernel level framebuffer is a full graphics driver (non-acceperated) to a graphical device .. it has very little to do with text support. When your running a "text console" in FB, you actually running "emulated text" .. or rather .. rendered text. With framebuffer there is very little need for the svgalib at all. Acceleration of the device can still be done via user land interfaces. Perhaps a quote from the kernel's docs on the framebuffer can describe this better then my tired mind can. ---- The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn't need to know anything about the low-level (hardware register) stuff. The device is accessed through special device nodes, usually located in the /dev directory, i.e. /dev/fb*. --- Part of the design flaws with the old ggi was basicly it attempted to shuv a nasty chunk of bloat into kernel land. The newly revised ggi family breaks it down into the KGI (framebuffer patches) and the libggi .. where libggi is capable of locating the best "interface" for the job. It will attempt KGI, FB, X, svgalib .. (I think in that order but I havn't beat on it in so long I forget). Anyway .. the linux kernel FB is an abstract interface to a graphics adapter that allows for the userland application to supply it's own acceleration. Thusly a new svgalib, or libggi, or X11 need supply the graphical acceleration for the FB device. Linux FB is not a textmode thing at all. On Fri, Mar 10, 2000 at 09:19:43PM -0800, David Jeske wrote: > On Fri, Mar 10, 2000 at 04:56:11PM -0800, Andy Valencia wrote: > > [David Jeske writes:] > > >I looked into it a while back and thought that the kernel portion of > > >LinuxGGI would fit nicely into a VSTa server. (it basically arbitrates > > >access to the video hardware so applications don't need root/sys.sys > > >access to control the screen) > > > > The problem I had was that I couldn't find any graphics hardware support in > > it; it appeared to depend on the Linux kernel FB support. And *that* stuff > > looked pretty deeply embedded in the kernel. To the extent that svgalib > > looked much easier to adopt. Has this changed? > > Now that I looked deeper at what they have, it does not seem far > enough along to be consider a "big-win" IMO. > > -- > > Given that, however... > > I don't understand what you are referring to exactly. The Linux kernel > FB support is just support for basic text modes. The biggest thing the > Linux kernel FB stuff does is provide an API for telling user-level > software to "let go" of the hardware and restore it to a known > state. That's how switching virtual consoles with X works... > > The single biggest goal of GGI is to provide _one_ place where > hardware specific drivers live, in GGI. In 1998 they released a sample > implementation that had hardware support for a number of graphics > cards. They now have a new implementation based on what they learned > which unfortunatly only has dumb framebuffer support for four types of > hardware (VGA, S3 ViRGE, Matrox G200/G400, Permidia). Acceleration > support is non-existant. > > FYI: Here is a summary of where I understand code to live in GGI and > non-GGI Linux setups. > > 1. non-GGI > > Text modes: linux kernel > svgalib: card-specific userspace library > X-windows: card-specific xwindows executable > > 2. GGI > > Text modes: card-specific in-kernel GGI driver > svgalib: card-specific in-kernel GGI driver + > svgalib-compatible userspace library > X-windows: card-specific in-kernel GGI driver + > generic Xggi X server > > > -- > David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net > -- "That is precisely what common sense is for, to be jarred into uncommon sense." ++ Eric Temple Bell, Mathmatics: Queen of the Sciences Mark Ferrell : Major'Trips' Lead Programmer : Chaotic Dreams Development Team URL : http://www.planetquake.com/chaotic E-Mail : major@planetquake.com From daemon Sat Mar 11 21:44:38 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id VAA01074 for vsta-xplod; Sat, 11 Mar 2000 21:44:38 GMT Received: from mozart.chat.net (qmailr@adsl-216-103-193-237.dsl.snfc21.pacbell.net [216.103.193.237]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id VAA01055 for ; Sat, 11 Mar 2000 21:44:31 GMT Received: (qmail 24169 invoked by uid 120); 12 Mar 2000 05:37:05 -0000 Date: Sat, 11 Mar 2000 21:37:05 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: VSTa update Message-ID: <20000311213705.W11267@mozart.chat.net> Mail-Followup-To: vsta@zendo.com References: <20000310150854.N11267@mozart.chat.net> <200003110056.QAA01084@vandys-pc.vandys.cisco.com> <20000310211943.O11267@mozart.chat.net> <20000311142854.A21946@jimco-fwt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000311142854.A21946@jimco-fwt.com> I don't mean for this to degenerate into a "Linux graphics" conversation on the VSTa list.. however, there are some relevant pieces here. On Sat, Mar 11, 2000 at 02:28:54PM -0600, Major wrote: > Anyway .. the linux kernel FB is an abstract interface to a graphics adapter > that allows for the userland application to supply it's own acceleration. > Thusly a new svgalib, or libggi, or X11 need supply the graphical acceleration > for the FB device. Linux FB is not a textmode thing at all. I see. I was thinking of the older GGI stuff which had more complicated graphics drivers (fb + accel) in the kernel before Linux-/dev/fb existed. I'm very opposed to the "library which has hardware drivers in it" model, since any code which touches hardware directly can crash the machine pretty trivially. (I'm sure I can cause at least two or three PCI graphics cards to lock up the PCI bus completely with just a few MMIO writes.) IMO, the nicest part about the previous GGI (the part I presume you were calling bloat), is that it put the code which needed to be trusted (all the code which touched the graphics hardware) into a "trusted space", which in that case was the kernel. What they've done now (IMO) basically requires everything to go through X, so that X can be the trusted userland server with acceleration support. I like the idea of this code living in a trusted userspace graphics server (instead of kernel), but X is relatively annoying to configure and is not as modular as it should be. (i.e. you can't just install a binary graphics driver, and XF86Config is a pain). In addition, until Xfree4/DRI, there wasn't any way to get low-level access to hardware acceleration through X. I don't even know how well that stuff works, since it's only recently been released. In addition, with Xfree4/DRI, from what I understand, they are planning for the OpenGL libraries to directly touch the graphics hardware from your application. SGI spent years designing hardware which was "safe" enough to touch from userspace, and which had hardware virtualization. In the PC world, hardware will never be like this. The Windows-esq DirectX model is (IMO) better as it allows trusted drivers, untrusted applications, cheap software sharing (but not pure virtualization), and relatively fast access to the raw hardware acceleration features. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Thu Mar 23 16:39:52 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA01357 for vsta-xplod; Thu, 23 Mar 2000 16:39:52 GMT Received: from hestia.its.deakin.edu.au (hestia.its.deakin.edu.au [128.184.136.2]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA01338 for ; Thu, 23 Mar 2000 16:39:12 GMT Received: from deakin.edu.au (tuor.cm.deakin.edu.au [128.184.83.51]) by hestia.its.deakin.edu.au (8.10.0/8.10.0) with ESMTP id e2NNxBp27937 for ; Fri, 24 Mar 2000 10:59:15 +1100 (EST) Message-ID: <38DAAFC7.54D2A1A1@deakin.edu.au> Date: Fri, 24 Mar 2000 10:59:03 +1100 From: ESD X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: memory allocation under VSTa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I notice that mmap() munmap() are the primary calls from user space into the memory system. What is it that is happening with malloc() in servers such as DOS. Is the malloc() in userland a different one to the one in the kernel which is wrapped by MALLOC()? I can't seem to discover the mechanism that the server can actually get at this call. Is this the common kernel address space which is visible globally? How does all that work? Any feedback on this would be much appreciated. regard Eric esd@deakin.edu.au From daemon Mon Mar 27 14:25:34 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id OAA00753 for vsta-xplod; Mon, 27 Mar 2000 14:25:34 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id OAA00728; Mon, 27 Mar 2000 14:24:52 GMT Message-Id: <200003271424.OAA00728@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: David Yeske Cc: vsta@zendo.com Subject: Re: vsta In-reply-to: Your message of "Mon, 27 Mar 2000 13:57:32 PST." <20000327215732.17601.qmail@web112.yahoomail.com> Date: Mon, 27 Mar 2000 14:24:52 +0000 From: Andy Valencia [David Yeske writes:] >I was wondering if vsta is still being developed? Yup. In fact, there'll be a moderately major announcement on the list in mid-April. Side comment to the list: our server hardware had some problems, resulting in some disruption of the list. It's partially addressed now, but we may have to swap more hardware in the future. Andy Valencia From daemon Mon Mar 27 17:17:20 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA01117 for vsta-xplod; Mon, 27 Mar 2000 17:17:20 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.8.5/8.6.12) with SMTP id RAA01110 for ; Mon, 27 Mar 2000 17:17:14 GMT Message-Id: <200003271717.RAA01110@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: vsta@zendo.com Subject: VSTa 1.6.2 update Date: Mon, 27 Mar 2000 17:17:14 +0000 From: Andy Valencia Hello, VSTa interessees. Just a quick update on the doings on VSTa. I have svgalib ported, and just this afternoon got the "vgatest" program to run, correctly probe for my video chip, offer a (correct) list of modes, switch to different modes, do graphics, and switch back. My next step is to marry this with MGR, so that MGR can run against any supported svgalib frame buffer, using all those extended video modes. MGR is surprisingly nice, but I *was* getting a little tired of 640x480! One weird side note: after returning to text mode, my LCD display is generating a very high pitched whine. Anybody recognize this as a common symptom of video card programming? I still haven't been able to test native VSTa on a FAT-32 system; GNU GRUB 0.5.94 claims to have a rewritten FAT-32, but although they've pushed out source, they haven't provided binaries. My tool chain (on either VSTa or FreeBSD) can't hack their sources (looks like a bunch of 16-bit gas weirdness), so if somebody could cook up a stage1/stage2 for me, I'd be much obliged. Attached below is the feature list so far for 1.6.2. Comments are obviously welcome! Andy FAT-32 support. Fix race condition in parallel threads faulting same vaddr. Fix bug in execvp which would sometimes hose the last argument M_TIME is gone. RIP. Add select() emulation. select() is supported by ka9q/networking, MGR terminals, and the console(s). Fix bug in grep(1), which used the wrong value of O_RDONLY. Fix crash when fork()'ing while another thread is blocked in a msg_connect attempt. Fix hang when quitting MGR (had to hit a key on the terminal to actually let it exit). MGR's $HOME/mgr.rc file now works... example in /vsta/guest. Port of ctags. Cleaned up MGR's "resetwin" command. Implemented ephemeral threads to support alarm(), SIGCHLD, etc. See sched_op(). Implemented ANSI C atexit(). Low-level VSTa event handler API, handle_event() from Fix crash when m_to_sm() fails, but a segment cleanup is attempted anyway. DOS now maps "." to "_ has some stuff useful for porting Linux programs. From daemon Tue Mar 28 13:31:00 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id NAA02831 for vsta-xplod; Tue, 28 Mar 2000 13:31:00 GMT Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id NAA02811; Tue, 28 Mar 2000 13:30:27 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12a3GY-00033I-0B; Tue, 28 Mar 2000 21:11:10 +0000 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA00790; Tue, 28 Mar 2000 22:00:54 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <38E11D68.5D2091AB@humbug.demon.co.uk> Date: Tue, 28 Mar 2000 22:00:24 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia , vsta@zendo.com Subject: Re: VSTa 1.6.2 update References: <200003271717.RAA01110@bodhi.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, Andy Valencia wrote: > > One weird side note: after returning to text mode, my LCD display is > generating a very high pitched whine. Anybody recognize this as a common > symptom of video card programming? This sounds suspiciously like svgalib is not restoring some of the scan timings correctly. LCD's can be a bit of a problem in this regard - text mode may be working, but possibly more by luck than anything else :-( Have you tried the same thing but with a CRT? Sometimes the timing variance shows up as a shift or sizing change in the display (strangely I found that the cheaper CRTs were best for observing this as they did less to try and compensate). When I was playing with graphics code under VSTa a while back I ran into quite a few problems with my laptop where the svgalib code was not restoring a couple of registers correctly - the code worked OK on a CRT but not on the LCD (I've also had the reverse being true). In the end I found that the XFree86 code was generally more thorough - I suspect because it gets used by a lot more people. Regards, Dave From daemon Tue Mar 28 17:57:35 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id RAA03176 for vsta-xplod; Tue, 28 Mar 2000 17:57:35 GMT Received: from ns1.usxc.net (ns1.usxc.net [216.47.224.66]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id RAA03157 for ; Tue, 28 Mar 2000 17:57:16 GMT Received: from debian ([216.47.231.242]) by ns1.usxc.net (Netscape Messaging Server 3.6) with ESMTP id AAA4F97 for ; Tue, 28 Mar 2000 20:38:03 -0500 Received: from usxchange.net (really [127.0.0.1]) by usxchange.net via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Tue, 28 Mar 2000 19:37:59 -0600 (CST) Sender: erdost@usxc.net Message-ID: <38E15E75.7357E0C5@usxchange.net> Date: Wed, 29 Mar 2000 01:37:57 +0000 From: "Thomas J. Erdos" Reply-To: erdost@usxchange.net X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Re: VSTa 1.6.2 update References: <200003271717.RAA01110@bodhi.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Valencia wrote: > > I still haven't been able to test native VSTa on a FAT-32 system; GNU GRUB > 0.5.94 claims to have a rewritten FAT-32, but although they've pushed out > source, they haven't provided binaries. My tool chain (on either VSTa or > FreeBSD) can't hack their sources (looks like a bunch of 16-bit gas > weirdness), so if somebody could cook up a stage1/stage2 for me, I'd be > much obliged. > They are in the incoming directory. I just compiled them but didn't try if they work. I also put fat_stage1_5 and ffs_stage1_5 if you have any use for them. If there's any problem just mail back and I'm going to try to install them and see where the problem is. Thomas From daemon Fri Mar 31 16:37:48 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA08424 for vsta-xplod; Fri, 31 Mar 2000 16:37:48 GMT Received: from columbia1-mail-router1.netops.gte.com (columbia1-smrt1.gtei.net [192.239.19.9]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA08405 for ; Fri, 31 Mar 2000 16:37:38 GMT Received: from meson.sys.gtei.net (meson.sys.gtei.net [4.2.32.45]) by columbia1-mail-router1.netops.gte.com (8.9.3/8.9.3) with ESMTP id TAA27990 for ; Fri, 31 Mar 2000 19:18:37 -0500 (EST) Date: Fri, 31 Mar 2000 19:18:33 -0500 (EST) From: Brett McCoy X-Sender: bmccoy@meson.sys.gtei.net To: vsta@zendo.com Subject: vsta under vmware Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone succeeded in running vsta under vmware? I'm having problems getting grub to boot from a floppy (either real floppy or an image file). It just prints SJSJSJSJSJSJ and so on forever. I'm using the grub files from the 162 vsta distro. I haven't tried the latest and greatest grub yet (I'm going to try that tonight). I was just curious if anyone has made it work and if they have any hints or tips. For anyone who doesn't know about vmware, check out www.vmware.com. It's not free, but at $99 it's not too far off and is great for working on test kernels (ie. Linux 2.3.x series). I thought it would be really nice for playing around with vsta. ++Brett; From daemon Fri Mar 31 18:01:11 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA08530 for vsta-xplod; Fri, 31 Mar 2000 18:01:11 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA08524 for ; Fri, 31 Mar 2000 18:01:03 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA18328; Fri, 31 Mar 2000 17:41:32 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id RAA01101; Fri, 31 Mar 2000 17:41:31 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200004010141.RAA01101@vandys-pc.vandys.cisco.com> To: Brett McCoy cc: vsta@zendo.com Subject: Re: vsta under vmware In-reply-to: Your message of "Fri, 31 Mar 2000 19:18:33 EST." Reply-to: vandys@cisco.com Date: Fri, 31 Mar 2000 17:41:30 -0800 From: Andy Valencia [Brett McCoy writes:] >I'm having problems getting grub to boot from a floppy (either real floppy >or an image file). It just prints SJSJSJSJSJSJ and so on forever. >I'm using the grub files from the 162 vsta distro. I haven't tried the >latest and greatest grub yet (I'm going to try that tonight). I had trouble with older GRUB's on my laptop's USB floppy. The newer ones from project GNU's GRUB work were OK. >For anyone who doesn't know about vmware, check out www.vmware.com. It's >not free, but at $99 it's not too far off and is great for working on test >kernels (ie. Linux 2.3.x series). I thought it would be really nice for >playing around with vsta. Although Bochs is free, and you get source code. :-> (But I've seen VMWare demos, and it *is* a much faster emulator.) Andy From daemon Fri Mar 31 18:26:13 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA08622 for vsta-xplod; Fri, 31 Mar 2000 18:26:13 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA08613 for ; Fri, 31 Mar 2000 18:24:54 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA19123; Fri, 31 Mar 2000 18:05:23 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id SAA01280; Fri, 31 Mar 2000 18:05:22 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200004010205.SAA01280@vandys-pc.vandys.cisco.com> To: Brett McCoy cc: vsta@zendo.com Subject: Re: vsta under vmware In-reply-to: Your message of "Fri, 31 Mar 2000 20:59:30 EST." Reply-to: vandys@cisco.com Date: Fri, 31 Mar 2000 18:05:22 -0800 From: Andy Valencia [Brett McCoy writes:] >I'm having problems with bochs. It keeps crashing with: > bochs: panic, PIC: write to port 20h = 02 >I decided to give vmware a try rather than figure out why bochs isn't >working. I think I had to deal with this when I brought up VSTa under Bochs. The Bochs source dump on our FTP server has this; basically, it's OK for the PIC to ignore this I/O port write. There's one other (in the IDE emulation, if I recollect) which is the same kind of thing: safe to change the code to ignore the operation. Andy From daemon Fri Mar 31 18:19:03 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id SAA08605 for vsta-xplod; Fri, 31 Mar 2000 18:19:03 GMT Received: from columbia1-mail-router1.netops.gte.com (columbia1-smrt1.gtei.net [192.239.19.9]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id SAA08586 for ; Fri, 31 Mar 2000 18:18:33 GMT Received: from meson.sys.gtei.net (meson.sys.gtei.net [4.2.32.45]) by columbia1-mail-router1.netops.gte.com (8.9.3/8.9.3) with ESMTP id UAA01630; Fri, 31 Mar 2000 20:59:30 -0500 (EST) Date: Fri, 31 Mar 2000 20:59:30 -0500 (EST) From: Brett McCoy X-Sender: bmccoy@meson.sys.gtei.net To: Andy Valencia cc: vsta@zendo.com Subject: Re: vsta under vmware In-Reply-To: <200004010141.RAA01101@vandys-pc.vandys.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 31 Mar 2000, Andy Valencia wrote: >I had trouble with older GRUB's on my laptop's USB floppy. The newer ones >from project GNU's GRUB work were OK. I just downloaded the 0.5.93.1 and it seems to be working. >Although Bochs is free, and you get source code. :-> Yeah, I've been playing with it also. >(But I've seen VMWare demos, and it *is* a much faster emulator.) It doesn't actually emulate every instruction. It'll actually run most of the code directly. So, it can run stuff at very nearly machine speed. I'm having problems with bochs. It keeps crashing with: bochs: panic, PIC: write to port 20h = 02 I decided to give vmware a try rather than figure out why bochs isn't working. ++Brett; From daemon Fri Mar 31 19:05:23 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id TAA08682 for vsta-xplod; Fri, 31 Mar 2000 19:05:23 GMT Received: from columbia1-mail-router1.netops.gte.com (columbia1-smrt1.gtei.net [192.239.19.9]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id TAA08663 for ; Fri, 31 Mar 2000 19:05:07 GMT Received: from meson.sys.gtei.net (meson.sys.gtei.net [4.2.32.45]) by columbia1-mail-router1.netops.gte.com (8.9.3/8.9.3) with ESMTP id VAA03421; Fri, 31 Mar 2000 21:45:50 -0500 (EST) Date: Fri, 31 Mar 2000 21:45:49 -0500 (EST) From: Brett McCoy X-Sender: bmccoy@meson.sys.gtei.net To: Andy Valencia cc: vsta@zendo.com Subject: Re: vsta under vmware In-Reply-To: <200004010205.SAA01280@vandys-pc.vandys.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 31 Mar 2000, Andy Valencia wrote: >>I'm having problems with bochs. It keeps crashing with: >> bochs: panic, PIC: write to port 20h = 02 >>I decided to give vmware a try rather than figure out why bochs isn't >>working. > >I think I had to deal with this when I brought up VSTa under Bochs. The >Bochs source dump on our FTP server has this; basically, it's OK for the PIC >to ignore this I/O port write. There's one other (in the IDE emulation, if >I recollect) which is the same kind of thing: safe to change the code to >ignore the operation. Yup, changing the bx_panic to printf in iodev/pic.cc makes it work. The patch is: *** pic.cc 2000/04/01 02:31:42 1.1 --- pic.cc 2000/04/01 02:36:16 *************** *** 294,300 **** break; default: ! bx_panic("PIC: write to port 20h = %02x\n", value); } /* switch (value) */ break; --- 294,300 ---- break; default: ! bx_printf("PIC: write to port 20h = %02x\n", value); } /* switch (value) */ break; *************** *** 426,432 **** break; default: ! bx_panic("PIC: write to port A0h = %02x\n", value); } /* switch (value) */ break; --- 426,432 ---- break; default: ! printf("PIC: write to port A0h = %02x\n", value); } /* switch (value) */ break; From daemon Fri Mar 31 22:57:15 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id WAA08917 for vsta-xplod; Fri, 31 Mar 2000 22:57:15 GMT Received: from columbia1-mail-router1.netops.gte.com (columbia1-smrt1.gtei.net [192.239.19.9]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id WAA08898 for ; Fri, 31 Mar 2000 22:57:08 GMT Received: from meson.sys.gtei.net (meson.sys.gtei.net [4.2.32.45]) by columbia1-mail-router1.netops.gte.com (8.9.3/8.9.3) with ESMTP id BAA11062 for ; Sat, 1 Apr 2000 01:38:09 -0500 (EST) Date: Sat, 1 Apr 2000 01:38:08 -0500 (EST) From: Brett McCoy X-Sender: bmccoy@meson.sys.gtei.net To: vsta@zendo.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to boot vsta 1.6.2 under vmware. I'm using the latest grub image on a real floppy and entering the following on the command line: root= (hd0,0) kernel= /vsta/boot/vsta module= /vsta/boot/cons module= /vsta/boot/namer module= /vsta/boot/wd d0:readp module= /vsta/boot/dos -d //disk/wd:wd0_dos0 -n fs/root module= /vsta/boot/init boot Everything is happy and grub is able to read all of the files okay. But, it crashes with "Boot process 3 dies". A 'btr' doesn't give anything that seems useful to me. I can't cut and paste it, but it's pretty much: _trace _do_cmd _dbg_main _dbg_enter _do_exit _sendev _check_events _trap called from _trap_common As far as I can tell the 'dos' driver is failing. But I'm not sure how to get any diagnostics to determine what's causing it to die. (hd0,0) is a bootable disk image and currently has dos installed on it and I am able to boot it fine, so I don't think it's a problem with a corrupt disk or partition table. Grub sees it fine also and has no problem traversing the directory tree. Any hints for where to start looking? ++Brett; From daemon Sat Apr 1 07:37:30 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA11789 for vsta-xplod; Sat, 1 Apr 2000 07:37:30 GMT Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA11783 for ; Sat, 1 Apr 2000 07:37:23 GMT Received: from vandys-pc.vandys.cisco.com (vandy-frame.cisco.com [171.70.231.17]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA03423; Sat, 1 Apr 2000 07:17:53 -0800 (PST) Received: from vandys-pc.vandys.cisco.com (localhost.vandys.cisco.com [127.0.0.1]) by vandys-pc.vandys.cisco.com (8.9.1/8.9.1) with ESMTP id HAA00291; Sat, 1 Apr 2000 07:17:52 -0800 (PST) (envelope-from vandys@vandys-pc.vandys.cisco.com) Message-Id: <200004011517.HAA00291@vandys-pc.vandys.cisco.com> To: Brett McCoy cc: vsta@zendo.com In-reply-to: Your message of "Sat, 01 Apr 2000 01:38:08 EST." Reply-to: vandys@cisco.com Date: Sat, 01 Apr 2000 07:17:51 -0800 From: Andy Valencia [Brett McCoy writes:] >Everything is happy and grub is able to read all of the files okay. But, >it crashes with "Boot process 3 dies". >... >_do_exit >_sendev >_check_events >As far as I can tell the 'dos' driver is failing. But I'm not sure how to >get any diagnostics to determine what's causing it to die. Usually PID 3 is namer. Since namer doesn't need anything external (he's basically a RAM-based filesystem) this may indicate that your modules didn't get loaded in intact, or something to that effect. A "tf" (in the kernel debugger) should tell you the trap frame which sent the process into the kernel. From the backtrace, I'm guessing it's a SEGV or somesuch. It'll also tell you the program counter, and give you an idea of where in the process it croaked. Finally, you can OR in 0x80000000 with the PC value, and do "di " to look at the faulting instruction. >(hd0,0) is a bootable disk image and currently has dos installed on it and >I am able to boot it fine, so I don't think it's a problem with a corrupt >disk or partition table. Grub sees it fine also and has no problem >traversing the directory tree. Yeah, probably a corrupt image of the namer executable (unlikely), or else it got corrupted while being loaded. Those would be my first guesses, but figuring out why the program croaked will provide more clues. Andy From daemon Mon Apr 3 16:07:49 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA02785 for vsta-xplod; Mon, 3 Apr 2000 16:07:49 GMT Received: from massnet1.hexcom.net (massnet1.hexcom.net [216.234.97.100]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id QAA02766 for ; Mon, 3 Apr 2000 16:07:29 GMT Received: from massnet1.net (216-234-98-5.as5300-1.det2.hexcom.net [216.234.98.5]) by massnet1.hexcom.net (8.9.3/8.9.3) with ESMTP id TAA21767 for ; Mon, 3 Apr 2000 19:49:09 -0400 (EDT) Message-ID: <38E92DF9.C1C6BB30@massnet1.net> Date: Mon, 03 Apr 2000 19:49:14 -0400 From: Joe Blask X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: File systems. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy: While you're working on filesystem support for VSTa, please consider checking out the Reiser FS at http://devlinux.com/projects/reiserfs/ , if you haven't already. Thanks, ==Joe B.== From daemon Sun Apr 23 02:02:57 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id CAA17701 for vsta-xplod; Sun, 23 Apr 2000 02:02:57 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id CAA17682 for ; Sun, 23 Apr 2000 02:02:50 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id <22JMY6VF>; Sun, 23 Apr 2000 17:53:13 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB7061C@GERNT002> From: "Dines, Eric" To: "'vandys@cisco.com'" Cc: "'vsta@zendo.com'" Subject: ltr() from locore.h seems a bit wierd with gcc Date: Sun, 23 Apr 2000 17:51:27 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain I notice that in locore.h * ltr() * Load the task register */ inline extern void ltr(uint tr_base) { __asm__ __volatile__( "ltr %%eax\n\t" "jmp 1f\n" but other functions like lidt() put parenthesis around %%eax like __asm__ __volatile__( "lidt (%%eax)\n\t" I have been tinkering around with a later version of gcc, and it throws up an error when it compiles/assembles this segment. Strangely gcc doesn't like it without parenthesis, but my little app. fails when it runs when compiled with parenthesis. I had a look at the assembly code when compiled -S, and it has ltr %eax jmp 1f error message says "unknown i386 operands" If the offending code is removed and compiled, it seems to run OK. Any suggestions anyone? cheers Eric ------------------------------------------------------------------------- From daemon Sun Apr 23 16:58:28 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA18717 for vsta-xplod; Sun, 23 Apr 2000 16:58:28 GMT Received: (from root@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id QAA18696; Sun, 23 Apr 2000 16:58:25 GMT Date: Sun, 23 Apr 2000 16:58:25 GMT From: John Meacham To: "'vsta@zendo.com'" Subject: Re: ltr() from locore.h seems a bit wierd with gcc Message-ID: <20000423114215.E11154@synergy.caltech.edu> Mail-Followup-To: "'vsta@zendo.com'" References: <3FC96A0BD509D411930500062950DFB7061C@GERNT002> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3FC96A0BD509D411930500062950DFB7061C@GERNT002>; from Eric.Dines@iluka.com on Sun, Apr 23, 2000 at 05:51:27PM +0800 shouldnt it be ltr %%ax? the task register is loaded with a pointer into the GDT which containes a special entry for the current task state segment... gdt entries are indexed by 16 bit values not 32... at least that is what i use in my code.. (not VSTa) which seems to compile fine under newest egcs(gcc). this has always been one of my pet peeves with documentation for intel CPUs, it never really says how to get tasking mode set up... they describe in detail how to switch between tasks and what a task state segment should contain but not how one should use ltr and stick in these things initially, it took a bit of experementation for me until i figured out the right way to do it.. ah well.. (this was before i had all sorts of linux and VSTa and whatnot code to look at..) John On Sun, Apr 23, 2000 at 05:51:27PM +0800, Dines, Eric wrote: > "ltr %%eax\n\t" > I had a look at the assembly code when compiled -S, and it has > > ltr %eax > jmp 1f > error message says "unknown i386 operands" > > Any suggestions anyone? -- -------------------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net California Institute of Technology, Student. -------------------------------------------------------------- From daemon Mon Apr 24 08:15:15 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.8.5/8.6.12) id HAA20319 for vsta-xplod; Mon, 24 Apr 2000 07:04:57 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.8.5/8.6.12) with ESMTP id HAA20300 for ; Mon, 24 Apr 2000 07:04:51 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id <22JMY71S>; Mon, 24 Apr 2000 22:55:19 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB7061F@GERNT002> From: "Dines, Eric" To: "'John Meacham '" , "''vsta@zendo.com' '" Subject: RE: ltr() from locore.h seems a bit wierd with gcc Date: Mon, 24 Apr 2000 22:53:35 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" You're absolutely right...insofar as it's working is concerned. Compiled and ran like a charm.... I wonder how VSTa is doing it with the self compile? cheers Eric shouldnt it be ltr %%ax? the task register is loaded with a pointer into the GDT which containes a special entry for the current task state segment... gdt entries are indexed by 16 bit values not 32... at least that is what i use in my code.. (not VSTa) which seems to compile fine under newest egcs(gcc). On Sun, Apr 23, 2000 at 05:51:27PM +0800, Dines, Eric wrote: > "ltr %%eax\n\t" > I had a look at the assembly code when compiled -S, and it has > > ltr %eax > jmp 1f > error message says "unknown i386 operands" > > Any suggestions anyone? -- -------------------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net California Institute of Technology, Student. -------------------------------------------------------------- ------------------------------------------------------------------------- From daemon Sun May 14 03:42:54 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4E3gsc24521 for vsta-xplod; Sun, 14 May 2000 03:42:54 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4E3fK724502 for ; Sun, 14 May 2000 03:41:21 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id NAA00575 for ; Sun, 14 May 2000 13:27:03 +0200 Date: Sun, 14 May 2000 13:27:03 +0200 (CEST) From: Erik Dalen To: vsta@zendo.com Subject: Announcement? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What's happening? Wasn't there going to be an Announcement going to be made on this list in April? What is the future of VSTa? I'm sorry I haven't been able to code anything on it but I will probably be able to do some coding for VSTa in about 2 months. It's not fair complaining that nothing is happening when I'm not doing anything myself, but why isn't anything happening? /Erik From daemon Mon May 15 10:13:56 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4FADuU26711 for vsta-xplod; Mon, 15 May 2000 10:13:56 GMT Received: from vandys-pc.zendo.com (dialup-209.245.172.221.Seattle1.Level3.net [209.245.172.221]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4FADo726701 for ; Mon, 15 May 2000 10:13:50 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id KAA00275 for ; Mon, 15 May 2000 10:57:57 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005151757.KAA00275@vandys-pc.zendo.com> To: vsta@zendo.com Subject: VSTa news Date: Mon, 15 May 2000 10:57:57 -0700 From: Andy Valencia Hello, VSTa interessees. It gives me great pleasure to announce some changes on the VSTa home front. Because of the unprecedented valuations of Internet companies, and my timely employment at Cisco Systems, I have recently resigned my position at Cisco in order to pursue "personal interests". For me, this will entail some market gardening, and--as you might guess--VSTa hacking. So after a long slumber, my plan is for VSTa to reawaken with a full-time owner again. For those of you who asked if the current stock market gyrations impacted me--the short answer is no. I have been pursuing a strategy of diversification over the last several years, and while my investments have perhaps not done as well as the hottest startups, they have done OK, and continue to do OK through this market downturn. So you will not need to wonder if I will have to stop working on VSTa to take up a job at the local burger joint! In addition to the progress I sent to the list recently, I've been busy adapting MGR's "Sun Portable" blit driver to the 256-color VGA modes under svgalib. I should probably suspend this to provide an update to all of you, although I'm pretty close to having it work (currently I'm putting in the 64k bank switching support). It's been slower than usual because (1) I'm still a little stale, and (2) I don't have much experience with PC graphics cards. But it's getting there. Regards, Andy Valencia From daemon Mon May 15 18:56:01 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4FIu1v27402 for vsta-xplod; Mon, 15 May 2000 18:56:01 GMT Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4FIts727382; Mon, 15 May 2000 18:55:55 GMT Received: from ariel.kotelna.sk (ariel.paradise.net.nz [203.96.155.69]) by deborah.paradise.net.nz (8.10.0/8.10.0) with ESMTP id e4G2e4602881; Tue, 16 May 2000 14:40:05 +1200 Received: by ariel.kotelna.sk (Postfix, from userid 1000) id 4D3251E6; Tue, 16 May 2000 14:37:35 +1200 (NZST) Date: Tue, 16 May 2000 14:37:34 +1200 From: Martin Lucina To: Andy Valencia Cc: vsta@zendo.com Subject: Re: VSTa news Message-ID: <20000516143734.B55143@kotelna.sk> Mail-Followup-To: Andy Valencia , vsta@zendo.com References: <200005151757.KAA00275@vandys-pc.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005151757.KAA00275@vandys-pc.zendo.com>; from vandys@zendo.com on Mon, May 15, 2000 at 10:57:57AM -0700 Sender: mato@ariel.kotelna.sk Hello All, vandys@zendo.com said: > It gives me great pleasure to announce some changes on the VSTa home front. > Because of the unprecedented valuations of Internet companies, and my timely > employment at Cisco Systems, I have recently resigned my position at Cisco > in order to pursue "personal interests". For me, this will entail some > market gardening, and--as you might guess--VSTa hacking. So after a long > slumber, my plan is for VSTa to reawaken with a full-time owner again. Great! I look forward to many great undertakings. I unfortunately have not been active on the VSTa front for ages now so I wont make any promises. However I would like to ask if you are planning to work on any driver/network stack glue libraries that would allow us to pull drivers and TCP/IP out of *BSD? This is still something I would really like to do, but in the mean time anyone else interested in doing some hacking, go to it! I think this would be a most worthwhile project for someone wanting to get involved. BTW. Recalling our discussions ages ago on whether to use Linux or BSD code, I (having now spent some time hacking drivers on Linux) would definitely go for BSD. After having to stare at other peoples code trying to understand it, I have come to very much appreaciate such things as comments and clean design, which I have not seen much of in Linux. :-( > In addition to the progress I sent to the list recently, I've been busy > adapting MGR's "Sun Portable" blit driver to the 256-color VGA modes under > svgalib. I should probably suspend this to provide an update to all of you, > although I'm pretty close to having it work (currently I'm putting in the > 64k bank switching support). It's been slower than usual because (1) I'm > still a little stale, and (2) I don't have much experience with PC graphics > cards. But it's getting there. Makes me think we should persuade QNX to free up Photon. Not that they would ever do it of course, but it would suit our purposes nicely. Cheers Martin -- Martin Lucina http://www.kotelna.sk/mato/ Wellington, New Zealand I've always been mad I know I've been mad like the most of us are Pretty hard to explain why you're a madman even if you're not mad From daemon Mon May 15 23:17:13 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4FNHDx27658 for vsta-xplod; Mon, 15 May 2000 23:17:13 GMT Received: from mail.rdc1.sfba.home.com (imail@ha1.rdc1.sfba.home.com [24.0.0.66]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4FNH8727638 for ; Mon, 15 May 2000 23:17:08 GMT Received: from nersc.gov ([24.9.226.34]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000516070128.DLJU21643.mail.rdc1.sfba.home.com@nersc.gov> for ; Tue, 16 May 2000 00:01:28 -0700 Sender: atwong Message-ID: <3920F4CD.E85722FD@nersc.gov> Date: Tue, 16 May 2000 00:12:13 -0700 From: Adrian Wong Organization: NERSC X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: vsta@zendo.com Subject: Clustering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I'm a relative newbie to VSTa. I've been reading the source to get some background. My interest in VSTa is in the potential for transparent clustering, especially in desigining for clustering from the ground-up. I have a couple questions before I dive into the deep end: 1. What are the current thoughts on clustering? Is it too premature to start thinking about this? 2. Am I right that none of the clients make any assumption about the services being in the same address space? (Since all transactions use message-passing). 3. Does external (not in the same address space) message passing implementation belong inside the kernel or in user space? 4. Would port numbers be unique cluster-wide? How do you "discover" the services "out there". My apologies if this all sounds a little naive. I will have access to VI Architecture network cards (Giganet), and would be interesting to see if remote services could be implemented within VSTa. thanks Adrian From daemon Tue May 16 07:20:40 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4G7Kee28397 for vsta-xplod; Tue, 16 May 2000 07:20:40 GMT Received: from vandys-pc.zendo.com (dialup-63.214.10.44.Seattle1.Level3.net [63.214.10.44]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4G7Ka728390; Tue, 16 May 2000 07:20:36 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00579; Tue, 16 May 2000 08:04:44 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005161504.IAA00579@vandys-pc.zendo.com> To: Adrian Wong cc: vsta@zendo.com Subject: Re: Clustering In-reply-to: Your message of "Tue, 16 May 2000 00:12:13 PDT." <3920F4CD.E85722FD@nersc.gov> Date: Tue, 16 May 2000 08:04:44 -0700 From: Andy Valencia [Adrian Wong writes:] > 1. What are the current thoughts on clustering? Is it too > premature to start thinking about this? There's some stuff in the mail archives on this. I got transparent kernel messaging going; see vsta/src/srv/ka9q/cmds/proxyd.c and related ka9q source files. > 2. Am I right that none of the clients make any assumption > about the services being in the same address space? (Since > all transactions use message-passing). Correct. > 3. Does external (not in the same address space) message > passing implementation belong inside the kernel or in > user space? I put it outside. Mostly because I wanted to use TCP/IP for the transport, and it was already outside. And no, I don't think TCP/IP should move into the (micro)kernel! > 4. Would port numbers be unique cluster-wide? How do you > "discover" the services "out there". If what you're talking about is sharing a single TCP/IP stack (so that all the machines appear behind a single IP address), then this is kind of a different path from the one I chose. It's also a lot like what QNX chose to do. They used their own transport over the physical MAC, and then any machine could mount the TCP/IP stack from a single machine running TCP/IP (which was, basically, a gateway). By splitting the cluster messaging from TCP/IP, the two were kept distinct. The downside was that once the network grew beyond a single physical span, you had to bridge these MAC messages across all the spans. So they've headed in the direction of using IP, but then you have to structure your IP so that you can have more than one stack active at once. >My apologies if this all sounds a little naive. I will have access >to VI Architecture network cards (Giganet), and would be interesting to >see if remote services could be implemented within VSTa. Remove services--sure. But split horizon networking is extra work. Might be interesting. The other interesting aspect which comes to my mind is all the microkernel services which are *not* message based. Process creation, for instance. It'd be nice to find a way to move more of its raw services to messages, so that most of what can be done on one machine could be done just as well from a remote machine. QNX got this right. Interestingly, some of this was dropped from their newer Neutrino OS. At least in early releases (I haven't been keeping track lately). Regards, Andy Valencia From daemon Tue May 16 09:26:59 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4G9QxU28631 for vsta-xplod; Tue, 16 May 2000 09:26:59 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4G9QT728611 for ; Tue, 16 May 2000 09:26:29 GMT Message-id: Date: Tue, 16 May 2000 11:55:56 -0400 Subject: Re(2): VSTa news To: vsta@zendo.com From: Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) References: <200005151757.KAA00275@vandys-pc.zendo.com> <20000516143734.B55143@kotelna.sk> In-Reply-To: <20000516143734.B55143@kotelna.sk> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit mato@kotelna.sk writes: > >Great! I look forward to many great undertakings. I unfortunately have not >been active on the VSTa front for ages now so I wont make any promises. >However I would like to ask if you are planning to work on any >driver/network stack glue libraries that would allow us to pull drivers >and >TCP/IP out of *BSD? This is still something I would really like to do, but >in the mean time anyone else interested in doing some hacking, go to it! I >think this would be a most worthwhile project for someone wanting to get >involved. I would like to take a look at the xkernel (http://www.cs.arizona.edu/xkernel/ ). This is a protocol framework that includes many modularized components taken from the BSD code, including TCP/IP. The protocols may be implemented asynchronously or synchronously using in-process cooperative microthreading. Another VSTa-ish protocol framework is netgraph (recently integrated into FreeBSD). It's a much simpler design, using asynchronous-only components, running in a single address space (the kernel, but it could be run anywhere). It provides PPP as well as a host of other more arcane protocols that can be assembled into any configuration at run time. One thing that I think would benefit VSTa would be a way to abstract the message passing functionality so that the focus can be placed on writing components without commiting to a server/process. For example, TCP and IP may be seperate components (as they are in xkernel), but the system could load them into the same address space as one process rather than two. Similarly, if you are running a single filesystem on a single drive (with both the driver and the fs running as the same user), the system may well load the fs code and the driver code into the same process, saving a layer of unnecessary message-passing overhead. The idea is that the code would remain the same whether the processes are shared or not. That way, the system can figure out the most efficient way to link the components together at run time. Of course, if the user wants to do something strange, like run the driver on one machine and the fs on another, it can always drop back to old method and use the message passing syscalls. From daemon Fri May 19 11:16:22 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4JBGMv04260 for vsta-xplod; Fri, 19 May 2000 11:16:22 GMT Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4JBGI704240; Fri, 19 May 2000 11:16:18 GMT Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA10077; Fri, 19 May 2000 12:00:24 -0700 (PDT) Received: from nersc.gov (fangg.lbl.gov [128.3.1.103]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA10070; Fri, 19 May 2000 12:00:24 -0700 (PDT) Sender: atwong@lbl.gov Message-ID: <39258F47.51A2388D@nersc.gov> Date: Fri, 19 May 2000 12:00:23 -0700 From: Adrian Wong Organization: NERSC X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia CC: vsta@zendo.com Subject: Re: Clustering References: <200005161504.IAA00579@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Valencia wrote: > > [Adrian Wong writes:] > > > 1. What are the current thoughts on clustering? Is it too > > premature to start thinking about this? > > There's some stuff in the mail archives on this. I got transparent kernel > messaging going; see vsta/src/srv/ka9q/cmds/proxyd.c and related ka9q source > files. Thanks for pointing me in the right direction on this. Actually I found src/srv/ka9q/vsta.c and src/srv/ka9c/vsta_srv.c most informative. I very much like the design that underlies the source. It provides a mapping from ports to TCP/IP sockets with no mods to the microkernel. I suppose the microkernel acts as the switchboard and the user-space daemon does the job of repackaging messages for a different protocol. > > > 4. Would port numbers be unique cluster-wide? How do you > > "discover" the services "out there". > > If what you're talking about is sharing a single TCP/IP stack (so that all > the machines appear behind a single IP address), then this is kind of a > different path from the one I chose. Actually, I wasnt even thinking of a heavyweight transport such as TCP/IP. But rather some future (vaporware) such as InfiniBand or VI Architecture. So here are my thoughts on the mechanism: 1. Start an cluster service, mount point /sysnet. Daemon takes the single argument "address:port" of the cluster-wide master daemon. Connect to master daemon and obtain info of cluster network, available services etc. "ls /sysnet" does what you expect - list the cluster status. 2. For each desired service, spawn a thread, open the port and register the mount point as if it were local, "/junk". For each incoming message, establish network connection to remote service, repackage message and send. 3. On the server side, for each exported service, the cluster daemon opens a network endpoint and listens for incoming connections. Incoming messages are forwarded to the local service msg port from a spawned thread. 4. The master daemon keeps the registry of participating nodes, the map of services to addresses, resolves name conflicts, etc. It also could handle failover. So at a high level, the cluster daemon really just maps local ports to remote ports and provides the necessary transport between the two. The advantage is that no changes are required to existing services so long as no assumptions are made about the locality of the messages and the senders. In this scenario, only the ports and network endpoints that are being listened on are open. All other connections are made "just-in-time". Obviously there is a case to be made for open file descriptors and having a permanent connection for the lifetime of the file descriptor. > > The other interesting aspect which comes to my mind is all the microkernel > services which are *not* message based. Process creation, for instance. > It'd be nice to find a way to move more of its raw services to messages, so > that most of what can be done on one machine could be done just as well from > a remote machine. QNX got this right. Interestingly, some of this was > dropped from their newer Neutrino OS. At least in early releases (I haven't > been keeping track lately). > I like the way Chorus handles remote processes with a control thread and control port for asynchronous messages (aka signals) for each process. That seems to retain the POSIX semantics for processes. That being said, it is not clear to me what it means to "fork" a remote process in the POSIX sense. "exec" I can get my head around. Adrian From daemon Sun May 21 21:13:26 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4LLDQp10589 for vsta-xplod; Sun, 21 May 2000 21:13:26 GMT Received: from vandys-pc.zendo.com (dialup-209.245.164.129.Seattle1.Level3.net [209.245.164.129]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4LLDK710582 for ; Sun, 21 May 2000 21:13:21 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id VAA01102 for ; Sun, 21 May 2000 21:57:42 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005220457.VAA01102@vandys-pc.zendo.com> To: vsta@zendo.com Subject: VSTa 1.6.3 available Date: Sun, 21 May 2000 21:57:42 -0700 From: Andy Valencia I'm happy to announce the availability of VSTa 1.6.3 at: ftp://ftp.vsta.org/vsta/vsta_163 I got bogged down a bit on the home stretch because I wanted to marry svgalib to MGR to get the 8-bit higher resolutions (I mostly hack underneath MGR, and 640x480 is a little cramped). The best step ended up being pulling the "colorport" SVGA driver from the newer Linux MGR, tearing out the VGA chip code, wiring in calls to svgalib, and then back-porting this to the VSTa MGR server. At the last minute I found that the ATI Rage code in svgalib had a bug; I had to hunt it down and fix it, and then report it back to the main svgalib developers. Can you imagine resolving a similar sort of problem while developing for a Windoze product? (shiver) Attached is the final feature list for 1.6.3. The most immediate thing to shoot for in 1.6.4 is LBA support; there's just too many large disks out there which can't be addressed (reasonably) any other way. I'm also curious to hear about how well the new FAT-32 code handles your filesystems! Note that at some point in the near future, we should switch exclusively to GNU's version of GRUB. I've left that out for the time being. But I've tested with their versions, and it works OK. If you find problems with somewhat esoteric boot devices (like USB floppy), you might want to try GNU's. Messages may be sent to the list here, or you can query me in private about anything wonderful or strange in this release. Enjoy! Andy Valencia vandys@zendo.com vandys@vsta.org >FAT-32 support. >Fix race condition in parallel threads faulting same vaddr. >Fix bug in execvp which would sometimes hose the last argument >M_TIME is gone. RIP. >Add select() emulation. select() is supported by ka9q/networking, > MGR terminals, and the console(s). >Fix bug in grep(1), which used the wrong value of O_RDONLY. >Fix crash when fork()'ing while another thread is blocked in > a msg_connect attempt. >Fix hang when quitting MGR (had to hit a key on the terminal to > actually let it exit). >MGR's $HOME/mgr.rc file now works... example in /vsta/guest. >Port of ctags. >Cleaned up MGR's "resetwin" command. >Implemented ephemeral threads to support alarm(), SIGCHLD, ABC, etc. > See sched_op(). >Implemented ANSI C atexit(). >Low-level VSTa event handler API, handle_event() from >Fix crash when m_to_sm() fails, but a segment cleanup is attempted anyway. >DOS now maps "." to "_ rh.rc to _rhrc, mgr.rc to _mgrrc. _exrc for vim remains the same. >Re-org of makefile structure; creation of global makefile.all. >Move a bunch of binary ports to a new vsta/src/bin/ports subdir. >Create a vsta/src/include, which holds the RCS-managed versions. > The "make install" phase copies header files to their > place in vsta/include. >POSIX signal emulation. This is all the signal set handling stuff > beyond the basic signal() API (which has existed for a while). >User and system CPU times of getrusage() are now filled in. >clock_t and clock() are now supported. >A has some stuff useful for porting Linux programs. >testsh wouldn't wait and retry to connect with the console. In some > scenarios, this would put it in an endless silent tight loop. >Added a fionread() to to provide the ioctl FIONREAD function. >Ported zmodem rz/sz. Not working exactly right just yet.... >Ported svgalib and jpeg6b. Got some of the svgalib demo apps working. >Ported PD m4 from FreeBSD. >Ported the 8-bit color driver from mgr-0.69 into the VSTa MGR port. > Adapted it to use svgalib. Got high res working with MGR. >Added BSD's err/warn API's. >Added true/false/whoami commands. From daemon Mon May 22 00:33:46 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4M0Xko10942 for vsta-xplod; Mon, 22 May 2000 00:33:46 GMT Received: from mta3.263.net ([202.96.44.47]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4M0XX710922 for ; Mon, 22 May 2000 00:33:34 GMT Received: by mta3.263.net (Postfix, from userid 60001) id 24F581C5E2094; Mon, 22 May 2000 15:53:57 +0800 (CST) MIME-Version: 1.0 Message-Id: <3928E795.17097@mta5> Date: Mon, 22 May 2000 15:53:57 +0800 (CST) From: "guo lin" To: vsta@zendo.com Subject: gcc X-Priority: 3 hello,every one: Now we are researching VSTA and want to make some progress on it.Unfortunately, the gcc we downloaded doesn't work. We are working under DOS,sometimes ender UNIX and even the simlpest C program the gcc won't assemble. It always shows "NO ENTRY".Maybe it is something wrong with the file system.And when we use other gcc, the object code cannot be run correctly. Lin Guo 00,5,22 _____________________________________________ Ê׶¼ÔÚÏß--ÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net @263.netÖйú×î´óµÄÔÚÏßÓÊ¾Ö http://freemail.263.net From daemon Tue May 23 12:47:57 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4NClv814297 for vsta-xplod; Tue, 23 May 2000 12:47:57 GMT Received: from vandys-pc.zendo.com (dialup-209.245.166.36.Seattle1.Level3.net [209.245.166.36]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4NClq714289 for ; Tue, 23 May 2000 12:47:53 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA01962 for ; Tue, 23 May 2000 13:32:23 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005232032.NAA01962@vandys-pc.zendo.com> To: vsta@zendo.com Subject: MGR binaries Date: Tue, 23 May 2000 13:32:23 -0700 From: Andy Valencia Note to those of you who (bravely) are going to try the newer MGR. In a fit of timidity, I didn't put the latest/greatest binary in /vsta/mgr/bin. So run it directly from the development directory: /vsta/mgr/src/mgr/mgr. Enjoy! Andy From daemon Tue May 23 17:45:17 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4NHjHJ14704 for vsta-xplod; Tue, 23 May 2000 17:45:17 GMT Received: from vandys-pc.zendo.com (dialup-63.214.15.238.Seattle1.Level3.net [63.214.15.238]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4NHjD714697 for ; Tue, 23 May 2000 17:45:14 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id SAA00467 for ; Tue, 23 May 2000 18:29:34 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005240129.SAA00467@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Question about LBA on PC's Date: Tue, 23 May 2000 18:29:34 -0700 From: Andy Valencia So I see how I can configure an I/O using LBA addressing--there's a new bit in the command, and then a new encoding which goes into the sector/cylinder/track values. But what I *don't* see is how I tell that a controller supports LBA, and/or that a given disk (or partition) is addressed that way? Can somebody in the know give me a URL to something which can give me the big picture? Thanks, Andy Valencia From daemon Tue May 23 18:56:12 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4NIuCI14813 for vsta-xplod; Tue, 23 May 2000 18:56:12 GMT Received: from synergy.caltech.edu (lloyd-110.caltech.edu [131.215.89.110]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4NIu8714793 for ; Tue, 23 May 2000 18:56:08 GMT Received: (from john@localhost) by synergy.caltech.edu (8.8.7/8.8.7) id OAA01686 for vsta@zendo.com; Tue, 23 May 2000 14:05:10 -0700 Date: Tue, 23 May 2000 14:05:09 -0700 From: John Meacham To: vsta@zendo.com Subject: Re: Question about LBA on PC's Message-ID: <20000523140507.B1591@synergy.caltech.edu> Mail-Followup-To: vsta@zendo.com References: <200005240129.SAA00467@vandys-pc.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005240129.SAA00467@vandys-pc.zendo.com>; from vandys@zendo.com on Tue, May 23, 2000 at 06:29:34PM -0700 what you want is the ATA-3 Specification, it can be gotten at http://magic.hurrah.com/~sabre/os/H2Buses/ata3-r6.zip it is in some ms format so you will have to convert it somehow. in general the site http://magic.hurrah.com/~sabre/os/ has pretty much any info one might need to write hardware support for an os. to answer your question specifically, you can grab the configuration info from the drive and it will have a bit set which indicated whether LBA mode is supported, you then turn on LBA mode in one of the control registers and just use it. works like a charm. incidentally i have written disk code which has the exact opposite problem from vsta, it only works with LBA drives :) John -- -------------------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net California Institute of Technology, Student. -------------------------------------------------------------- From daemon Sat May 27 12:57:04 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4RCv4O23845 for vsta-xplod; Sat, 27 May 2000 12:57:04 GMT Received: from vandys-pc.zendo.com (dialup-63.214.15.59.Seattle1.Level3.net [63.214.15.59]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4RCuw723837; Sat, 27 May 2000 12:56:59 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA00440; Sat, 27 May 2000 13:41:27 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005272041.NAA00440@vandys-pc.zendo.com> To: John Meacham cc: vsta@zendo.com Subject: Re: Question about LBA on PC's In-reply-to: Your message of "Tue, 23 May 2000 14:05:09 PDT." <20000523140507.B1591@synergy.caltech.edu> Date: Sat, 27 May 2000 13:41:27 -0700 From: Andy Valencia [John Meacham writes:] >in general the site http://magic.hurrah.com/~sabre/os/ has >pretty much any info one might need to write hardware support for an os. Thanks for the pointer. One thing which seems absent is PCMCIA stuff. Is there any comparable resource for dealing with PCMCIA hardware? I have a PCMCIA LAN card which I'd just love to use directly from VSTa. BTW, I ended up using the LBA-only "total size" field of the parameter block. I'm hoping that non-LBA controllers will leave it 0's. Thanks! Andy From daemon Sat May 27 18:32:50 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4RIWop24200 for vsta-xplod; Sat, 27 May 2000 18:32:50 GMT Received: from synergy.caltech.edu (lloyd-110.caltech.edu [131.215.89.110]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4RIWi724180 for ; Sat, 27 May 2000 18:32:45 GMT Received: (from john@localhost) by synergy.caltech.edu (8.8.7/8.8.7) id NAA03355 for vsta@zendo.com; Sat, 27 May 2000 13:42:34 -0700 Date: Sat, 27 May 2000 13:42:32 -0700 From: John Meacham To: vsta@zendo.com Subject: Re: Question about LBA on PC's Message-ID: <20000527134231.A3312@synergy.caltech.edu> Mail-Followup-To: vsta@zendo.com References: <20000523140507.B1591@synergy.caltech.edu> <200005272041.NAA00440@vandys-pc.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005272041.NAA00440@vandys-pc.zendo.com>; from vandys@zendo.com on Sat, May 27, 2000 at 01:41:27PM -0700 hmm.. it appears the LBA mode bit was taken out of the ATA-3 spec and LBA mode was made manditory (obviously since ATA-3 made it manditory all ATA-2 drives are now obsolete and need no longer be supported :) ). in any case for backwards compatability with older drives you just need to check bit 9 in word 49 of the device identification info... (it is marked obsolete in the ATA-3 spec.). the best free info i have found for PCMCIA is at http://pcmcia.sourceforge.org/specs/index.html you can also pay a whole lot of money to the pc-card consortium or whatever its called to get the actual specs but this is probably enough to put something together... hope this helps :) John -- -------------------------------------------------------------- John Meacham http://synergy.foo.net/~john/ john@foo.net California Institute of Technology, Student. -------------------------------------------------------------- From daemon Sun May 28 03:45:09 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4S3j9j25136 for vsta-xplod; Sun, 28 May 2000 03:45:09 GMT Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4S3j4725116; Sun, 28 May 2000 03:45:04 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12w1GW-00043F-0W; Sun, 28 May 2000 12:29:57 +0100 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id MAA05117; Sun, 28 May 2000 12:29:29 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <393102FA.9FED99A6@humbug.demon.co.uk> Date: Sun, 28 May 2000 12:28:58 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia CC: "vsta@zendo.com" Subject: Interrupt handling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, A long time back (must be about 5 or 6 years ago) I remember a discussion about interrupt handling, and in particular what would be appropriate for systems that used level triggered interrupts rather than edge triggered. The edge triggered case is easy since we just get an interrupt and we don't need to clear the cause down before we leave the ISR - thus making it easy to send the interrupt messages to device servers. I seem to remember that there may have been a few different solutions to the level triggerred case (one was some interpretted code handled within the kernel that a device server would be able to register when it initialized). I've been playing with another microcontroller families recently (Atmel AVRs) writting an LGPL'd embedded OS and have ended up with a similar sort of design to VSTa where I want to handle all interrupts within normally scheduled threads and hit on a slightly different solution - I need this because pulling a 1.5k packet out of an ethernet chip with an 8 bit micro can take serveral ms and I don't want to screw up my UART code. Rather than trying to clear the interrupt cause down in the ISR (which is what I started doing), my latest tack is to temporarily disable the interrupt within the interrupt management unit (effectively the PIC) which allows me to leave the ISR, but without upsetting the state of the interrupting device. My threads then re-enable the interrupt within the IMU once they've handled the interrupting event. Anyway, the question is: How general a mechanism is this? I know that this works for several micro families, but I don't know if there are any subtle gotcha's that would cause this to fail on other micros or interrupt units. Regards, Dave From daemon Sun May 28 08:35:28 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4S8ZSt25490 for vsta-xplod; Sun, 28 May 2000 08:35:28 GMT Received: from vandys-pc.zendo.com (dialup-209.244.108.41.Seattle1.Level3.net [209.244.108.41]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4S8ZI725483; Sun, 28 May 2000 08:35:18 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA00464; Sun, 28 May 2000 09:19:46 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005281619.JAA00464@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" Subject: Re: Interrupt handling In-reply-to: Your message of "Sun, 28 May 2000 12:28:58 BST." <393102FA.9FED99A6@humbug.demon.co.uk> Date: Sun, 28 May 2000 09:19:46 -0700 From: Andy Valencia [Dave Hudson writes:] >I've been playing with another microcontroller families recently (Atmel >AVRs) writting an LGPL'd embedded OS and have ended up with a similar >sort of design to VSTa where I want to handle all interrupts within >normally scheduled threads and hit on a slightly different solution - I >need this because pulling a 1.5k packet out of an ethernet chip with an >8 bit micro can take serveral ms and I don't want to screw up my UART >code. Rather than trying to clear the interrupt cause down in the ISR >(which is what I started doing), my latest tack is to temporarily >disable the interrupt within the interrupt management unit (effectively >the PIC) which allows me to leave the ISR, but without upsetting the >state of the interrupting device. My threads then re-enable the >interrupt within the IMU once they've handled the interrupting event. > >Anyway, the question is: How general a mechanism is this? I know that >this works for several micro families, but I don't know if there are any >subtle gotcha's that would cause this to fail on other micros or >interrupt units. This approach is OK for smaller scale systems. The underlying assumption is that interrupt granularity (to wit, masking) matches driver granularity. I've worked with a number of embedded systems where there are too many devices sharing the same CPU interrupt level. In some of these systems, there is a secondary interrupt controller which can mask individual sources. But then you're back to the same problem--in the kernel, before you return, being able to decode sources. In some cases, you can do this in a general way--the secondary interrupt decode logic can be read to determine source. In others, you have to go query each specific kind of device to find the "culprit". And then you're right back to the problem of device specific code needing to run before you can return from kernel mode. So yes, your approach is a nice middle ground for the middle ground of level triggered interrupts where each CPU general level corresponds to a particular device. This would usually work on PC's, but of course one generally has edge triggered interrupts anyway so it isn't needed. Andy Valencia From daemon Sun May 28 13:50:21 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4SDoL326033 for vsta-xplod; Sun, 28 May 2000 13:50:21 GMT Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4SDoF726013; Sun, 28 May 2000 13:50:15 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 12wAiD-000O99-0C; Sun, 28 May 2000 21:35:09 +0000 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA06546; Sun, 28 May 2000 22:34:39 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <393190CF.8E185BAF@humbug.demon.co.uk> Date: Sun, 28 May 2000 22:34:07 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia , "vsta@zendo.com" Subject: Re: Interrupt handling References: <200005281619.JAA00464@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, Andy Valencia wrote: > > This approach is OK for smaller scale systems. The underlying assumption is > that interrupt granularity (to wit, masking) matches driver granularity. > I've worked with a number of embedded systems where there are too many > devices sharing the same CPU interrupt level. In some of these systems, > there is a secondary interrupt controller which can mask individual sources. > But then you're back to the same problem--in the kernel, before you return, > being able to decode sources. In some cases, you can do this in a general > way--the secondary interrupt decode logic can be read to determine source. > In others, you have to go query each specific kind of device to find the > "culprit". And then you're right back to the problem of device specific > code needing to run before you can return from kernel mode. I had another thought about this case too (after I sent the original note)... FWIW I know about the sharing problem having supported 8 16550-style UARTs on a single interrupt line with a fast 8051 last year :-/ Back to the point though... when interrupts are shared, the general solution must be something like disabling the interrupt channel on the ICU and then hitting all of device servers attached to the interrupt source with an interrupt message. The choice must then be to allow the first of these that finds an interrupt pending to re-enable the channel on the ICU. If another has a pending interrupt we'd simply re-enter the ISR when we "iret" and try again (the joys of level triggering :-)). Now arguably this solution adds some overhead for queuing the interrupt messages to the device servers, but then again this is already accepted to a large extent in the design anyway. Another variant on this theme might hit each server in turn with an interrupt message and expect the server to reply with an indication of whether it handled the interrupt or not. If it didn't then the kernel could hit the next server with the interrupt message; if it did then the kernel could re-enable the interrupt channel. Of course one very useful optimization under these circumstances would be some form of priority queueing of messages (e.g. possibly allowing the interrupt messages to be made more important than some others). BTW I thought that the only edge triggered PC interrupts were on the ISA bus (and even then it generally seems to be the PIC that's doing the edge triggering - the 4 Ethernet cards I've looked at in the last 2 weeks all hold the interrupt line high until the cause of the interrupt is either masked within the Ethernet chipset or is ack'd). Regards, Dave From daemon Mon May 29 07:47:16 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4T7lGQ27436 for vsta-xplod; Mon, 29 May 2000 07:47:16 GMT Received: from vandys-pc.zendo.com (dialup-209.245.162.216.Seattle1.Level3.net [209.245.162.216]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4T7lA727429; Mon, 29 May 2000 07:47:11 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00308; Mon, 29 May 2000 08:31:39 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005291531.IAA00308@vandys-pc.zendo.com> To: vax cc: vsta@zendo.com Subject: Re: 1.6.3 Compilation problem In-reply-to: Your message of "Mon, 29 May 2000 01:14:28 PDT." Date: Mon, 29 May 2000 08:31:39 -0700 From: Andy Valencia [vax writes:] >I'm trying to compile 1.6.3 and it tells me i need assym.h(i think thats >the one) but it's no where to be found, can anyone help meout in getting >it, so i can try it out. assym.h is used only in building the kernel. See vsta/src/os/make/makefile for the rule to build it (by running the "genassym" program). it's a way to import values from C source into assembler. >for the windowing system of svgalib and ggi use >svgalib it's more solid, and i don't like ggi. Of course, you don't really need to rebuild the kernel if you just want to play with svgalib/MGR. The supplied binaries will work fine. But if there's a problem with building from source, I'm very interested in finding and fixing the problem. Andy Valencia From daemon Mon May 29 08:12:18 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4T8CIp27484 for vsta-xplod; Mon, 29 May 2000 08:12:18 GMT Received: from vandys-pc.zendo.com (dialup-209.245.162.216.Seattle1.Level3.net [209.245.162.216]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4T8CC727477; Mon, 29 May 2000 08:12:12 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00412; Mon, 29 May 2000 08:56:42 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005291556.IAA00412@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" Subject: Re: Interrupt handling In-reply-to: Your message of "Sun, 28 May 2000 22:34:07 BST." <393190CF.8E185BAF@humbug.demon.co.uk> Date: Mon, 29 May 2000 08:56:41 -0700 From: Andy Valencia [Dave Hudson writes:] >FWIW I know about the sharing problem having supported 8 16550-style >UARTs on a single interrupt line with a fast 8051 last year :-/ But that's *homogeneous* sharing. Heterogeneous sharing is when it gets hairy. >Back to the point though... when interrupts are shared, the general >solution must be something like disabling the interrupt channel on the >ICU and then hitting all of device servers attached to the interrupt >source with an interrupt message. OK for homogeneous, not so OK for heterogeneous. >Now arguably this solution adds some overhead for queuing the interrupt >messages to the device servers, but then again this is already accepted >to a large extent in the design anyway. Not at all. A little front-end (i.e., in the machine ISR) demuxing can both identify the interrupting device, mask it at that device, and set the device's server process runnable. The savings in overhead as compared to polling numerous server processes is immense. Note that, coming freshly off Cisco, I'm used to environments where relatively modest CPU's handle a million interrupts per second. So my approach to scaling for interrupts tend to be a little extreme. >Of course one very useful optimization under these circumstances would >be some form of priority queueing of messages (e.g. possibly allowing >the interrupt messages to be made more important than some others). I looked into this, and I thought a lot about this based on our discussions (so very long ago) about problems you were having with priority inversion in the RS-232 server. But as you've probably noticed, I found that it's much cleaner (and keeps the message path streamlined) to use more than one queue rather than encode priority into the IPC. >BTW I thought that the only edge triggered PC interrupts were on the ISA >bus (and even then it generally seems to be the PIC that's doing the >edge triggering - the 4 Ethernet cards I've looked at in the last 2 >weeks all hold the interrupt line high until the cause of the interrupt >is either masked within the Ethernet chipset or is ack'd). PCI also has it as a standard interrupt mode. Also, very high end buses all do it this way, because as your bus scales up, it becomes more and more like a very fast network. Split transactions become the norm, and having interrupts look like events rather than conditions falls out pretty naturally. Andy Valencia From daemon Mon May 29 10:26:34 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4TAQYT27659 for vsta-xplod; Mon, 29 May 2000 10:26:34 GMT Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4TAQU727639; Mon, 29 May 2000 10:26:31 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 12wU0c-00093j-0X; Mon, 29 May 2000 19:11:27 +0100 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id TAA08759; Mon, 29 May 2000 19:06:44 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <3932B195.1CFF55B3@humbug.demon.co.uk> Date: Mon, 29 May 2000 19:06:13 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia CC: "vsta@zendo.com" Subject: Re: Interrupt handling References: <200005291556.IAA00412@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy Andy Valencia wrote: > > [Dave Hudson writes:] > > >FWIW I know about the sharing problem having supported 8 16550-style > >UARTs on a single interrupt line with a fast 8051 last year :-/ > > But that's *homogeneous* sharing. Heterogeneous sharing is when it gets > hairy. I think I must be being particularly slow at the moment because I can't really see why this should be the case - each UART had it's own interrupt line, just logically OR'd to all of the others. Under the circumstances that wouldn't appear to be any different to 8 completely different types of device all hanging from the same interrupt line? > >Now arguably this solution adds some overhead for queuing the interrupt > >messages to the device servers, but then again this is already accepted > >to a large extent in the design anyway. > > Not at all. A little front-end (i.e., in the machine ISR) demuxing can both > identify the interrupting device, mask it at that device, and set the > device's server process runnable. The savings in overhead as compared to > polling numerous server processes is immense. > > Note that, coming freshly off Cisco, I'm used to environments where > relatively modest CPU's handle a million interrupts per second. So my > approach to scaling for interrupts tend to be a little extreme. OK - point taken (I don't think I've really ever worried about more than 20k interrupts per second to date) We don't have this with VSTa of course - or have you got VSTa/RT waiting for release? :-) > I looked into this, and I thought a lot about this based on our discussions > (so very long ago) about problems you were having with priority inversion in > the RS-232 server. But as you've probably noticed, I found that it's much > cleaner (and keeps the message path streamlined) to use more than one queue > rather than encode priority into the IPC. Hmm - I must admit that this is the same sort of approach I've taken with the 8-bit stuff, but then again I've not been trying to do everything with messages (I'm using shared memory and condition variables so that I can sleep on one or more event, or wake all of my sleepers up together). > PCI also has it as a standard interrupt mode. Also, very high end buses all > do it this way, because as your bus scales up, it becomes more and more like > a very fast network. Split transactions become the norm, and having > interrupts look like events rather than conditions falls out pretty > naturally. I assume that under these circumstances the interrupt units that handle these events must keep track of the number of events or queue them in a stack (unlike the PC's ISA PIC) - otherwise there must be some really nasty race conditions waiting to happen :-/ BTW as something of an aside - have you thought about implementing support for VNC (either as a client or service). I just have a suspicion that it would be quite nice to run VSTa as an xterm into a Unix system or take over Windows PCs. Another thought is that it would make it easier to use and develop VSTa for anyone who doesn't have space for two sets of monitors, keyboards and mice. Regards, Dave From daemon Mon May 29 13:53:45 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4TDrjd27919 for vsta-xplod; Mon, 29 May 2000 13:53:45 GMT Received: from vandys-pc.zendo.com (dialup-209.245.169.72.Seattle1.Level3.net [209.245.169.72]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4TDqG727911; Mon, 29 May 2000 13:52:17 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA00405; Mon, 29 May 2000 14:36:46 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005292136.OAA00405@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" Subject: Re: Interrupt handling In-reply-to: Your message of "Mon, 29 May 2000 19:06:13 BST." <3932B195.1CFF55B3@humbug.demon.co.uk> Date: Mon, 29 May 2000 14:36:46 -0700 From: Andy Valencia [Dave Hudson writes:] >BTW as something of an aside - have you thought about implementing >support for VNC (either as a client or service). I just have a >suspicion that it would be quite nice to run VSTa as an xterm into a >Unix system or take over Windows PCs. Another thought is that it would >make it easier to use and develop VSTa for anyone who doesn't have space >for two sets of monitors, keyboards and mice. Never heard of it before, but just had a look. My previous approach to this problem was getting VSTa booting on the Bochs x86 emulator. :-> Anyway, the protocol doesn't seem too complex, but it begs the question of a GUI display server which can (conveniently) convert display updates into rectangle changes. For the server side, I guess that'd be MGR. For the client side, I'm guessing the Linux svgalib port of the VNC client would be the easiest. Andy From daemon Mon May 29 14:55:13 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4TEtD628022 for vsta-xplod; Mon, 29 May 2000 14:55:13 GMT Received: from vandys-pc.zendo.com (dialup-63.214.11.160.Seattle1.Level3.net [63.214.11.160]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4TEtA728015 for ; Mon, 29 May 2000 14:55:11 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id PAA00548 for ; Mon, 29 May 2000 15:39:41 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200005292239.PAA00548@vandys-pc.zendo.com> To: vsta@zendo.com Subject: FAT-32 and IDE LBA Date: Mon, 29 May 2000 15:39:41 -0700 From: Andy Valencia In ftp://ftp.vsta.org/vsta/pickup/1.6.3/ are the files wd.tz and dos.tz. The former is a snapshot of the IDE driver with LBA support, as well as a fix for > 2 gigabyte file offsets in support of larger disks. The latter is the DOS server with a number of fixes to the FAT-32 support. Both are the usual gzip'ed tar of the source directories. With these, I have a Sony VAIO laptop running very happily with VSTa alongside Windoze 98. The svgalib support for the NeoMagic chip is even letting me run MGR in 800x600 mode. Those of you who have had trouble getting VSTa to live on more modern Microsoft environments may want to give it a try. Enjoy! Andy From daemon Wed May 31 04:28:24 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e4V4SOA01321 for vsta-xplod; Wed, 31 May 2000 04:28:24 GMT Received: from fcgateway2.mcps.k12.md.us ([205.222.0.94]) by zendo.com (8.10.1/8.10.1) with ESMTP id e4V4SF701301 for ; Wed, 31 May 2000 04:28:16 GMT Message-id: Date: Wed, 31 May 2000 08:11:28 -0400 Subject: Re(2): Interrupt handling To: dave@humbug.demon.co.uk Cc: vsta@zendo.com From: "Eric Jacobs" References: <200005291556.IAA00412@vandys-pc.zendo.com> <3932B195.1CFF55B3@humbug.demon.co.uk> In-Reply-To: <3932B195.1CFF55B3@humbug.demon.co.uk> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit dave@humbug.demon.co.uk writes: > >BTW as something of an aside - have you thought about implementing >support for VNC (either as a client or service). I just have a >suspicion that it would be quite nice to run VSTa as an xterm into a >Unix system or take over Windows PCs. Another thought is that it would >make it easier to use and develop VSTa for anyone who doesn't have space >for two sets of monitors, keyboards and mice. You might want to have a look at the Microwindows project (http://www.microwindows.org). It can link into svgalib as a backend. There's a port in-progress of the VNC viewer in the source distribution. The X-socket-like stuff could probably be made to use VSTa messaging, although I haven't looked into it. Microwindows has X-like and Win32 like API's, and there's even a port of the FLTK widget set in development. From daemon Sun Jun 4 15:05:26 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e54F5Qg11999 for vsta-xplod; Sun, 4 Jun 2000 15:05:26 GMT Received: from nickel.cix.co.uk (nickel.compulink.co.uk [194.153.0.18]) by zendo.com (8.10.1/8.10.1) with ESMTP id e54F5K711979 for ; Sun, 4 Jun 2000 15:05:21 GMT Received: from RUDD.cix.co.uk (rudd.compulink.co.uk [194.153.16.14]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id XAA11887; Sun, 4 Jun 2000 23:50:27 +0100 (BST) X-Envelope-From: jback@cix.co.uk From: Julian Back MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14650.56624.264000.170202@gargle.gargle.HOWL> Date: Sun, 4 Jun 2000 23:50:24 +0100 (BST) To: vsta@zendo.com Subject: Re: FAT-32 and IDE LBA In-Reply-To: <200005292239.PAA00548@vandys-pc.zendo.com> References: <200005292239.PAA00548@vandys-pc.zendo.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid I've been inspired by the recent developments in VSTa to give it another try. I've downloaded the latest vsta.tz and the new wd.tz and dos.tz and installed it all under \vsta on my C: drive which is FAT32. I've also downloaded and compiled the latest GRUB, compiled it on Linux and installed it on a floppy. When I try and boot VSTa I now get: syslog: wd (pid 5) info: unit 0: 3337.8M - LBA init: can't find root, sleeping init: can't find root, sleeping syslog: dos (pid 7) error unable to open //disk/wd:wd0_dos0 It then drops into the debugger. I'm not sure how I can debug this as I don't have a working VSTa to recompile anything. Can I cross compile from Linux? Julian From daemon Sun Jun 4 16:32:37 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e54GWb912101 for vsta-xplod; Sun, 4 Jun 2000 16:32:37 GMT Received: from vandys-pc.zendo.com (dialup-209.245.161.186.Seattle1.Level3.net [209.245.161.186]) by zendo.com (8.10.1/8.10.1) with ESMTP id e54GWW712094; Sun, 4 Jun 2000 16:32:32 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id RAA00545; Sun, 4 Jun 2000 17:17:13 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200006050017.RAA00545@vandys-pc.zendo.com> To: Julian Back cc: vsta@zendo.com Subject: Re: FAT-32 and IDE LBA In-reply-to: Your message of "Sun, 04 Jun 2000 23:50:24 BST." <14650.56624.264000.170202@gargle.gargle.HOWL> Date: Sun, 04 Jun 2000 17:17:13 -0700 From: Andy Valencia [Julian Back writes:] >syslog: wd (pid 5) info: unit 0: 3337.8M - LBA >init: can't find root, sleeping >init: can't find root, sleeping >syslog: dos (pid 7) error unable to open //disk/wd:wd0_dos0 >It then drops into the debugger. >I'm not sure how I can debug this as I don't have a working VSTa to >recompile anything. Can I cross compile from Linux? My guess would be that your partition type is unknown. Could you try "wd0_p0" instead? Unknown types just are given "raw" ascending partition numbers. Andy Valencia From daemon Mon Jun 5 12:36:03 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e55Ca3913912 for vsta-xplod; Mon, 5 Jun 2000 12:36:03 GMT Received: from nickel.cix.co.uk (nickel.compulink.co.uk [194.153.0.18]) by zendo.com (8.10.1/8.10.1) with ESMTP id e55CZx713892 for ; Mon, 5 Jun 2000 12:36:00 GMT Received: from RUDD.cix.co.uk (rudd.compulink.co.uk [194.153.16.14]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id VAA07856; Mon, 5 Jun 2000 21:21:09 +0100 (BST) X-Envelope-From: jback@cix.co.uk From: Julian Back MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14652.2991.618000.848501@gargle.gargle.HOWL> Date: Mon, 5 Jun 2000 21:21:03 +0100 (BST) To: vsta@zendo.com Subject: Re: FAT-32 and IDE LBA In-Reply-To: <200006050017.RAA00545@vandys-pc.zendo.com> References: <14650.56624.264000.170202@gargle.gargle.HOWL> <200006050017.RAA00545@vandys-pc.zendo.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Andy Valencia writes: > My guess would be that your partition type is unknown. Could you try > "wd0_p0" instead? Unknown types just are given "raw" ascending partition > numbers. Thanks, that solved the problem. I'll try MGR next.... Julian From daemon Mon Jun 5 12:33:56 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e55CXue13884 for vsta-xplod; Mon, 5 Jun 2000 12:33:56 GMT Received: from nickel.cix.co.uk (nickel.compulink.co.uk [194.153.0.18]) by zendo.com (8.10.1/8.10.1) with ESMTP id e55CXp713864 for ; Mon, 5 Jun 2000 12:33:51 GMT Received: from RUDD.cix.co.uk (rudd.compulink.co.uk [194.153.16.14]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id VAA07190; Mon, 5 Jun 2000 21:19:00 +0100 (BST) X-Envelope-From: jback@cix.co.uk From: Julian Back MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14652.2862.272000.792425@gargle.gargle.HOWL> Date: Mon, 5 Jun 2000 21:18:54 +0100 (BST) To: vsta@zendo.com Subject: Re: FAT-32 and IDE LBA In-Reply-To: <200006050017.RAA00545@vandys-pc.zendo.com> References: <14650.56624.264000.170202@gargle.gargle.HOWL> <200006050017.RAA00545@vandys-pc.zendo.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Andy Valencia writes: > My guess would be that your partition type is unknown. Could you try > "wd0_p0" instead? Unknown types just are given "raw" ascending partition > numbers. Thanks, that has solved the problem. BTW the partition type is 0xb. I'll try MGR now... Julian From daemon Wed Jun 7 18:42:10 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e57IgAS18700 for vsta-xplod; Wed, 7 Jun 2000 18:42:10 GMT Received: from kotol.kotelna.sk (qmailr@[158.195.19.11]) by zendo.com (8.10.1/8.10.1) with SMTP id e57Ig4718680 for ; Wed, 7 Jun 2000 18:42:05 GMT Received: (qmail 7280 invoked by uid 1000); 8 Jun 2000 02:27:28 -0000 Date: Thu, 8 Jun 2000 04:27:28 +0200 From: Martin Lucina To: vsta@zendo.com Subject: Open Source Plan 9 Release Message-ID: <20000608042728.C7182@kotelna.sk> Mail-Followup-To: vsta@zendo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Bell Labs has released Plan 9 under an Open Source license. The relevant URLs are here http://plan9.bell-labs.com/plan9dist/ and here http://www.bell-labs.com/news/2000/june/7/2.html It is interesting to note that they only supply binaries for x86, but several other architectures have code in the tree. I wonder if I can get it running on my Alpha. -- Martin Lucina http://www.kotelna.sk/mato/ Wellington, New Zealand I've always been mad I know I've been mad like the most of us are Pretty hard to explain why you're a madman even if you're not mad From daemon Wed Jun 7 20:40:07 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e57Ke7p18833 for vsta-xplod; Wed, 7 Jun 2000 20:40:07 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by zendo.com (8.10.1/8.10.1) with ESMTP id e57Ke4718813 for ; Wed, 7 Jun 2000 20:40:04 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id GAA22566; Thu, 8 Jun 2000 06:27:47 +0200 Date: Thu, 8 Jun 2000 06:27:42 +0200 (CEST) From: Erik Dalen To: Martin Lucina cc: vsta@zendo.com Subject: Re: Open Source Plan 9 Release In-Reply-To: <20000608042728.C7182@kotelna.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What will happen with VSTa now? I mean after all the making of VSTa was motivated by the fact that plan 9 wasn't open source. I suppose this could accelerate the development of VSTa a great deal. But we might have to start thinking about beaing more plan 9 compatible as a lot of people will probably start using plan 9 now and it would be really neat to have some compability with them. How much redoing would it require to start using the plan 9 file protocol instead of VSTa's for example? Perhaps a port of this new Rio GUI they're talking about could be nice. Or at least make graphics servers for VSTa that use the same graphics model/protocol (Porter-Duff compositing algebra?). That's something I would really like to see but I haven't read the license yet so I'm not quite sure of how much we're allowed to "steal". /Erik From daemon Thu Jun 8 07:30:20 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e587UKs19764 for vsta-xplod; Thu, 8 Jun 2000 07:30:20 GMT Received: from vandys-pc.zendo.com (dialup-209.245.169.153.Seattle1.Level3.net [209.245.169.153]) by zendo.com (8.10.1/8.10.1) with ESMTP id e587U0719754; Thu, 8 Jun 2000 07:30:00 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00331; Thu, 8 Jun 2000 08:14:45 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200006081514.IAA00331@vandys-pc.zendo.com> To: Erik Dalen cc: Martin Lucina , vsta@zendo.com Subject: Re: Open Source Plan 9 Release In-reply-to: Your message of "Thu, 08 Jun 2000 06:27:42 +0200." Date: Thu, 08 Jun 2000 08:14:45 -0700 From: Andy Valencia [Erik Dalen writes:] >What will happen with VSTa now? >I mean after all the making of VSTa was motivated by the fact that plan 9 >wasn't open source. That and an interest in microkernels. As far as I could tell from "the outside looking in", Plan 9 wasn't a microkernel. Now that (apparently) the source is available, I'll have to look and see what it's like on the inside. BTW, if anybody can scare up source (including x86), please post a pointer. I've just wandered into Lucent's web site, and I'm really not interested in having a boot floppy image stuffed down my modem line. Thanks, Andy From daemon Mon Jun 12 08:13:09 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e5C8D9x29068 for vsta-xplod; Mon, 12 Jun 2000 08:13:09 GMT Received: from vandys-pc.zendo.com (dialup-209.245.170.26.Seattle1.Level3.net [209.245.170.26]) by zendo.com (8.10.1/8.10.1) with ESMTP id e5C8D4729060 for ; Mon, 12 Jun 2000 08:13:05 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA01633 for ; Mon, 12 Jun 2000 08:58:03 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200006121558.IAA01633@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Long filenames in DOS server Date: Mon, 12 Jun 2000 08:58:03 -0700 From: Andy Valencia Just an FYI... I have gone ahead and started coding the long filename support for the DOS filesystem. So far I have directory listing and file lookup working. That leaves file creation/deletion (i.e., the part where I have to write my own VFAT sub-entries, rather than just access the existing ones). I'm also looking over the Plan 9 stuff. I'll write up some initial observations in the next week. Andy Valencia From daemon Sun Jul 16 14:05:48 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6GE5mt10288 for vsta-xplod; Sun, 16 Jul 2000 14:05:48 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by zendo.com (8.10.1/8.10.1) with ESMTP id e6GE5i710268 for ; Sun, 16 Jul 2000 14:05:44 GMT Received: from groundbreaker (modem_c [199.93.212.245]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id RAA01790 for ; Sun, 16 Jul 2000 17:52:20 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: Long filenames in DOS server Date: Sun, 16 Jul 2000 17:47:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006121558.IAA01633@vandys-pc.zendo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > I'm also looking over the Plan 9 stuff. I'll write up some initial > observations in the next week. Anyone have any comments? I couldn't get plan9 to run on my machines. From daemon Mon Jul 17 03:33:50 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6H3XoU11142 for vsta-xplod; Mon, 17 Jul 2000 03:33:50 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6H3Xh711122 for ; Mon, 17 Jul 2000 03:33:45 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id NAA17971; Mon, 17 Jul 2000 13:25:41 +0200 Date: Mon, 17 Jul 2000 13:25:41 +0200 (CEST) From: Erik Dalen To: Gavin Thomas Nicol cc: vsta@zendo.com Subject: RE: Long filenames in DOS server In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 16 Jul 2000, Gavin Thomas Nicol wrote: > > I'm also looking over the Plan 9 stuff. I'll write up some initial > > observations in the next week. > > Anyone have any comments? I couldn't get plan9 to run on my machines. > I didn't really like everything about the plan9 license so I didn't even bother installing it. But me and a couple of friends have done some coding. We did a bugfix to man and sometime soon a 3com etherlink III driver should be finished. Where should I send the man bugfix? I'll do some more coding later on, right now I'm just trying to get all the computers running. The project at the moment is to get a K5-200 into an old IBM server case running with the old custom power supply... /Erik From daemon Mon Jul 17 05:36:25 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6H5aPo11319 for vsta-xplod; Mon, 17 Jul 2000 05:36:25 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by zendo.com (8.10.1/8.10.1) with ESMTP id e6H5aL711299 for ; Mon, 17 Jul 2000 05:36:21 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id JAA22365 for ; Mon, 17 Jul 2000 09:23:00 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: Long filenames in DOS server Date: Mon, 17 Jul 2000 09:28:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > I didn't really like everything about the plan9 license so I didn't even > bother installing it. > > But me and a couple of friends have done some coding. We did a bugfix to > man and sometime soon a 3com etherlink III driver should be finished. > Where should I send the man bugfix? This is a good question. Perhaps we should have a CVS repository somewhere? How about hosting VSTa development on sourceforge? From daemon Mon Jul 17 08:01:27 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6H81RB11573 for vsta-xplod; Mon, 17 Jul 2000 08:01:27 GMT Received: from vandys-pc.zendo.com (dialup-209.245.174.72.Seattle1.Level3.net [209.245.174.72]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6H81I711566; Mon, 17 Jul 2000 08:01:19 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00330; Mon, 17 Jul 2000 08:47:06 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007171547.IAA00330@vandys-pc.zendo.com> To: Erik Dalen cc: Gavin Thomas Nicol , vsta@zendo.com Subject: Re: Long filenames in DOS server In-reply-to: Your message of "Mon, 17 Jul 2000 13:25:41 +0200." Date: Mon, 17 Jul 2000 08:47:05 -0700 From: Andy Valencia [Erik Dalen writes:] >But me and a couple of friends have done some coding. We did a bugfix to >man and sometime soon a 3com etherlink III driver should be finished. >Where should I send the man bugfix? You can send it directly to me, or if it's something which needs immediate attention of others, to the list. Please don't send huge patches to the list, though--if it's more than a couple screenfulls, a pointer to a patch file is better. Regards, Andy From daemon Mon Jul 17 13:59:46 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6HDxku12017 for vsta-xplod; Mon, 17 Jul 2000 13:59:46 GMT Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6HDxe711997 for ; Mon, 17 Jul 2000 13:59:40 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13EIj4-000C1U-0W; Mon, 17 Jul 2000 22:46:58 +0100 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA00906; Mon, 17 Jul 2000 22:45:48 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <39737E6D.4B472C0@humbug.demon.co.uk> Date: Mon, 17 Jul 2000 22:45:17 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: "vsta@zendo.com" CC: Gavin Thomas Nicol Subject: Random musings... (Was Re: Long filenames in DOS server) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Gavin Thomas Nicol wrote: > > This is a good question. Perhaps we should have a CVS repository somewhere? > How about hosting VSTa development on sourceforge? Sourceforge would be a pretty good bet, although an alternative might be just to run the sourceforge software on the current server? From what I can see, this would be pretty straightforward too (given that a server already exists). Personally I've already gone for sourceforge for my Liquorice project (it saves me a lot of irritation not having to do lots of admin work). The only downside I've seen is that late in the evening UK time (2300ish say) sourceforge sometimes goes a bit slow (must be the Aussies waking up - as if winning test matches wasn't enough now they're running away with all of the bandwidth ;-) well perhaps not...) FWIW I'm looking at doing some VSTa network hacking very soon as my code is headed in a lot of similar directions, and having I'll be interested to see how it's new TCP/IP stack works with VSTa (I now understand why Andy ported KA9Q and didn't start from scratch - although it is quite an interesting thing to do :-)). I'm going to have to have a good look at the server proxy code as I think this offers a lot of really useful possibilites to the code I'm doing (which is currently targetted at big 8 bit micros - 32 kBytes of RAM is lot!). Ideally I could use VSTa to perform a number of services for the AVR microcontrollers - effectively the same thing MS are after with Unversal plug and play but *much* simpler to implement and without MS-levels of overhead. The environments with which I'm interested typically have about 100 or so microcontrollers and I'm working on replacing the RS485 networking with Ethernet/IP/TCP. Has anyone any idea how well the KA9Q-derived network service will handle 100 connections? I've never tried this many before, but I'd hope it shouldn't be too much of a problem. [Aside: What I'm looking to do is use VSTa as a host for streamed data (each microcontroller sending at a slowish rate of say 1 kByte per minute) with each stream being compressed and stored in a parameter database (about 50:1 compression is possible - I've already been doing this for 2 years). As I'll now have a peer-to-peer network rather than RS485 I'd plan to provide another VSTa service that allows the microcontrollers to identify others with interesting characteristics (a registry of sorts). There are other browserish things that need doing too but I think they can wait for a while!] How easy would it be to extend the network server to implement a different transport layer? I like the idea of the IL transport that Plan 9 uses (although I must admit I've not looked at the code for it) as it sounds much cleaner as far as implementations on small targets go - TCP is a real nuissance. I also seem to remember Andy thinking about implementing a raw Ethernet protocol for remote-message-passing (as with QNX 4) - any more thoughts on this? Regards, Dave From daemon Tue Jul 18 08:56:43 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6I8uhQ13653 for vsta-xplod; Tue, 18 Jul 2000 08:56:43 GMT Received: from vandys-pc.zendo.com (dialup-63.214.11.142.Seattle1.Level3.net [63.214.11.142]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6I8ub713645; Tue, 18 Jul 2000 08:56:37 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA00387; Tue, 18 Jul 2000 09:42:26 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007181642.JAA00387@vandys-pc.zendo.com> To: "Gavin Thomas Nicol" cc: vsta@zendo.com Subject: Re: Long filenames in DOS server In-reply-to: Your message of "Sun, 16 Jul 2000 17:47:48 EDT." Date: Tue, 18 Jul 2000 09:42:26 -0700 From: Andy Valencia >> I'm also looking over the Plan 9 stuff. I'll write up some initial >> observations in the next week. >Anyone have any comments? I couldn't get plan9 to run on my machines. Ok... Note that most of my comments relate to the kernel itself. I ported their troff over to VSTa, and it runs *way* faster than groff; it's also written in C (coincidence? :->). I realy like having access to the original, lean implementations of all those classic UNIX commands! The VM system had all the smell of a crock when they first wrote their papers. If they've released their latest code, then it hasn't improved with age. In general, I'm surprised at the lack of workman-like coding in this kernel. The leaders were old hands, and I know for a fact that Ken Thompson is one of the best programmers in the industry. But the kernel code is in general sloppy, poorly commented, and inconsistent. My real complaint is that it's a warmed-over V7 kernel, except for the distributed aspects. But if you focus in on the distributed aspects, it gets choppy really quickly. Filesystem access is OK--but we've had that for a whole bunch of years now. The core of a distributed system is how you cause work to be done, but basically none of the process creation/setup is integrated into their distributed filesystem semantics. It has SMP--good. It kinda has the look of somebody's first SMP OS, though--bad. This matches up with their paper on SMP support, where they show how they attempted to code up an MP-safe algorithm, and failed. Both the VM system and the SMP support should probably be done over again, based on what they've learned. Plan 9 doesn't claim to be a microkernel, but it's pretty small as "regular" kernels go. Having the filesystem abstraction served by processes keeps the doors open for things to stay out of kernel space. IP has been both in and outside the kernel over time in Plan 9. Personally, I believe that if you have a filesystem served from within your kernel, you've missed the break of mechanism and policy. Kernels do mechanism; policy happens elsewhere. The Plan 9 kernel has tons of policy, security, and device cruft down in the kernel. Part of this is that although the kernel can do SMP, it can't do preemption of kernel code sequences. So anything which needs timely servicing goes in the kernel, which lengthens the code paths, which degrades latency, which causes more stuff to need to be put in the kernel. It's a slippery slope. I'd like to hear more about the license. My eyes glazed over part of the way down the license, and then I saw the GPL at the bottom. What have they slipped in that might be a problem? Thanks, Andy Valencia From daemon Tue Jul 18 08:58:34 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6I8wYL13662 for vsta-xplod; Tue, 18 Jul 2000 08:58:34 GMT Received: from vandys-pc.zendo.com (dialup-63.214.11.142.Seattle1.Level3.net [63.214.11.142]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6I8wT713655; Tue, 18 Jul 2000 08:58:30 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA00410; Tue, 18 Jul 2000 09:44:19 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007181644.JAA00410@vandys-pc.zendo.com> To: "Gavin Thomas Nicol" cc: vsta@zendo.com Subject: Re: Long filenames in DOS server In-reply-to: Your message of "Mon, 17 Jul 2000 09:28:33 PDT." Date: Tue, 18 Jul 2000 09:44:19 -0700 From: Andy Valencia ["Gavin Thomas Nicol" writes:] >This is a good question. Perhaps we should have a CVS repository somewhere? >How about hosting VSTa development on sourceforge? Yeah, SourceForge looks pretty nice. We're at 140 megabytes in the development tree, which hopefully wouldn't be a problem for them. I'll look into this. Andy From daemon Tue Jul 18 10:19:30 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6IAJUo13807 for vsta-xplod; Tue, 18 Jul 2000 10:19:30 GMT Received: from vandys-pc.zendo.com (dialup-209.245.161.8.Seattle1.Level3.net [209.245.161.8]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6IAJL713800; Tue, 18 Jul 2000 10:19:22 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id LAA00322; Tue, 18 Jul 2000 11:05:11 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007181805.LAA00322@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" , Gavin Thomas Nicol Subject: Re: Random musings... (Was Re: Long filenames in DOS server) In-reply-to: Your message of "Mon, 17 Jul 2000 22:45:17 BST." <39737E6D.4B472C0@humbug.demon.co.uk> Date: Tue, 18 Jul 2000 11:05:10 -0700 From: Andy Valencia [Dave Hudson writes:] >How easy would it be to extend the network server to implement a >different transport layer? I like the idea of the IL transport that >Plan 9 uses (although I must admit I've not looked at the code for it) >as it sounds much cleaner as far as implementations on small targets go >- TCP is a real nuissance. I also seem to remember Andy thinking about >implementing a raw Ethernet protocol for remote-message-passing (as with >QNX 4) - any more thoughts on this? Perhaps the easiest way would be to have a standard mount point (and it would still use TCP/IP if nothing was mounted at that name). So any server which could handle the needed messages could be used. I could then imagine a shim which could turn these into (raw) Ethernet messages--but it would have to handle things like MTU limitations (some sort of scatter and reassembly, I assume). Or it could be a teeny server which turned it into bytes out a UART. You get the idea. I'll convert the current C library shim (hard coded to IP) if this sounds useful to anybody. I'd prefer to do it in concert with somebody actually exercising an alternative transport. Andy From daemon Tue Jul 18 13:25:32 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6IDPW914108 for vsta-xplod; Tue, 18 Jul 2000 13:25:32 GMT Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6IDPS714088; Tue, 18 Jul 2000 13:25:28 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 13EefY-000LIU-0Y; Tue, 18 Jul 2000 22:12:49 +0100 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA02001; Tue, 18 Jul 2000 22:11:37 +0100 Sender: dave@humbug.demon.co.uk Message-ID: <3974C7EA.1FB79206@humbug.demon.co.uk> Date: Tue, 18 Jul 2000 22:11:06 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia CC: "vsta@zendo.com" Subject: Re: Random musings... (Was Re: Long filenames in DOS server) References: <200007181805.LAA00322@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, Andy Valencia wrote: > > Perhaps the easiest way would be to have a standard mount point (and it > would still use TCP/IP if nothing was mounted at that name). So any server > which could handle the needed messages could be used. I could then imagine > a shim which could turn these into (raw) Ethernet messages--but it would > have to handle things like MTU limitations (some sort of scatter and > reassembly, I assume). Or it could be a teeny server which turned it into > bytes out a UART. You get the idea. I would guess that scatter and reassembly shouldn't be too hard - as we're only interested in connections then perhaps something like what I believe IL does sounds OK (reliable packet delivery - rather than reliable byte streaming). I suspect that we could compress the network and transport layers down to something utterly trivial if there's no need for routing. Any thoughts on using Ethernet CRC-checking instead of protocol-level checksums too? I've just been reading about some Sun Ethernet cards not doing things quite right and this getting through with a UDP implementation that didn't checksum (I don't know the full details though - it was a h/w problem apparently), but this would help with speed if we think it's OK. If not, any thoughts on a prefered checksum? The teeny server idea sounds like it'd be SLIPish, although PPP ought to be a reasonable bet for comms over a UART (I've not done PPP yet though, but it only looks like a couple of days of work). SLIPish sounds more in keeping with the objective of course (lighter weight altogether). > I'll convert the current C library shim (hard coded to IP) if this sounds > useful to anybody. I'd prefer to do it in concert with somebody actually > exercising an alternative transport. Alternative transports I can do :-) I designed my code to support a rather generic view of ISO-layered comms stacks because I support so many peculiar embedded protocols to pay the bills, although I've not done an Ethernet based alternative yet. I'm on holiday from the end of the week, but as soon as I'm back I'll start designing something and run it past the list for comment. Regards, Dave From daemon Tue Jul 18 23:29:49 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6INTnt14880 for vsta-xplod; Tue, 18 Jul 2000 23:29:49 GMT Received: from gsyc.escet.urjc.es (root@gsyc.escet.urjc.es [212.128.1.45]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6INTi714860; Tue, 18 Jul 2000 23:29:44 GMT Received: from nautilus.dat.escet.urjc.es (IDENT:root@nautilus.dat.escet.urjc.es [212.128.1.37]) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA17661; Wed, 19 Jul 2000 09:16:07 +0200 Received: (from nemo@localhost) by nautilus.dat.escet.urjc.es (8.9.3/8.9.3) id JAA02230; Wed, 19 Jul 2000 09:28:34 +0100 From: "Fco. J. Ballesteros" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14709.26288.974744.573384@nautilus.dat.escet.urjc.es> Date: Wed, 19 Jul 2000 09:28:32 +0100 (WEST) To: vandys@zendo.com Cc: gtn@ebt.com, vsta@zendo.com Subject: Re: Long filenames in DOS server In-Reply-To: <200007181642.JAA00387@vandys-pc.zendo.com> References: <200007181642.JAA00387@vandys-pc.zendo.com> X-Mailer: VM 6.75 under Emacs 20.5.1 >>>>> "Andy" == Andy Valencia writes: Andy> the industry. But the kernel code is in general sloppy, Andy> poorly commented, and inconsistent. I'm surprised to hear that, becase I read it and looks very nice. Regarding comments, I found that most of the time, the code was clear and simple enough that comments were not necessary. For example, I had no problem to find out what routines should be used to service a driver I'm writting for Plan9 in my spare time. And there was no comment around the ones I needed. Just their names and their code make it obvious which ones and how should I use them. From daemon Thu Jul 20 12:56:56 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6KCuuN18121 for vsta-xplod; Thu, 20 Jul 2000 12:56:56 GMT Received: from vandys-pc.zendo.com (dialup-63.214.15.190.Seattle1.Level3.net [63.214.15.190]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6KCui718113; Thu, 20 Jul 2000 12:56:44 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA00264; Thu, 20 Jul 2000 13:42:36 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007202042.NAA00264@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" Subject: Re: Random musings... (Was Re: Long filenames in DOS server) In-reply-to: Your message of "Tue, 18 Jul 2000 22:11:06 BST." <3974C7EA.1FB79206@humbug.demon.co.uk> Date: Thu, 20 Jul 2000 13:42:36 -0700 From: Andy Valencia [Dave Hudson writes:] >Any thoughts on using Ethernet CRC-checking instead of protocol-level >checksums too? I've just been reading about some Sun Ethernet cards not >doing things quite right and this getting through with a UDP >implementation that didn't checksum (I don't know the full details >though - it was a h/w problem apparently), but this would help with >speed if we think it's OK. If not, any thoughts on a prefered checksum? If we run directly on top of the Ether transport, then I'd trust to the Ether CRC. IP's checksums were to catch end-to-end problems, across more than one hop. >The teeny server idea sounds like it'd be SLIPish, although PPP ought to >be a reasonable bet for comms over a UART (I've not done PPP yet though, >but it only looks like a couple of days of work). SLIPish sounds more >in keeping with the objective of course (lighter weight altogether). Yes, I'd avoid PPP with all of its baggage unless you need multi-protocol, or authentication, or one of the other amenitities. SLIP's stateless encap is otherwise much easier. Andy From daemon Wed Jul 26 09:18:32 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6Q9IWP03210 for vsta-xplod; Wed, 26 Jul 2000 09:18:32 GMT Received: from vandys-pc.zendo.com (dialup-209.245.174.82.Seattle1.Level3.net [209.245.174.82]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6Q9IRB03202 for ; Wed, 26 Jul 2000 09:18:28 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id KAA00478 for ; Wed, 26 Jul 2000 10:26:51 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007261726.KAA00478@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Status update Date: Wed, 26 Jul 2000 10:26:51 -0700 From: Andy Valencia Hi, folks. I have long filenames for the DOS filesystem fully working now. I've also generalized the shared library support to make it easier to add more system shared libraries, and I've converted libm to a shared library. regex and termcap to follow! I've fixed lots of other, old minor irritants in the process. I also ported a PDP-11 emulator, and can now run V7 UNIX under the emulator under VSTa. The juxtaposition of the two environments is very interesting! And since V7 UNIX is in many ways the root of UNIX's "essence", it's very powerful to be able to refer to the environment on demand, within a VSTa window. Since Plan 9's troff/nroff ported across just fine, I'll probably spend a little time converting the manual page system to standard -man format. Then maybe I'll push out a new version for anybody who wants to experiment. I think we'll all be glad to leave 8.3 filenames behind for good! Regards, Andy Valencia From daemon Thu Jul 27 06:30:51 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6R6Upk04848 for vsta-xplod; Thu, 27 Jul 2000 06:30:51 GMT Received: from vandys-pc.zendo.com ([63.214.13.179]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6R6UlB04841 for ; Thu, 27 Jul 2000 06:30:47 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id HAA00263; Thu, 27 Jul 2000 07:39:11 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200007271439.HAA00263@vandys-pc.zendo.com> To: mirian@cosmic.com (Mirian Crzig Lennox) cc: vsta@zendo.com Subject: Re: VSTa under a386 In-reply-to: Your message of "26 Jul 2000 16:34:27 EDT." <8lni0j$1g7$1@magrathea.cosmic.com> Date: Thu, 27 Jul 2000 07:39:11 -0700 From: Andy Valencia [mirian@cosmic.com (Mirian Crzig Lennox) writes:] >One thing I am looking into is possibly porting VSTa to run >under a386. From its webpage (http://a386.nocrew.org): > > a386 is a C programming library which provides a virtual machine. The > virtual machine is an abstraction of an Intel 386 running in protected > mode. Functions in the library corresponds to privileged instructions > of a CPU and access to hardware. The intended use for the library is > to serve as a minimal hardware abstraction layer for operating system > research. > >The benefit of a386 is that, with a simple recompile, it is possible to >run the same operating system kernel code either on the bare metal, or >as a process under a host operating system, providing a friendlier >environment to debug code and test new features. > >What I'm hung up on now is trying to cross-compile the VSTa kernel tree >under Linux. Has anyone ever tried this? It doesn't seem to be as >simple as merely running the make. It should very nearly be as simple as running make. You'll want to use a cross compiler (VSTa is a known target for the GNU tools), not your native (ELF) tool chain. Otherwise I can't think of anything major to get in your way. Andy Valencia From daemon Fri Jul 28 10:58:42 2000 Received: (from daemon@localhost) by zendo.com (8.10.1/8.10.1) id e6SAwgQ07209 for vsta-xplod; Fri, 28 Jul 2000 10:58:42 GMT Received: from cosmic.com (IDENT:root@[216.41.40.61]) by zendo.com (8.10.1/8.10.1) with ESMTP id e6SAwZB07189 for ; Fri, 28 Jul 2000 10:58:36 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id PAA17334 for vsta@zendo.com; Fri, 28 Jul 2000 15:09:47 -0400 From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: VSTa under a386 Date: 28 Jul 2000 15:09:46 -0400 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 23 Message-ID: <8lslpq$gth$1@magrathea.cosmic.com> References: <200007271439.HAA00263@vandys-pc.zendo.com> X-Trace: magrathea.cosmic.com 964811386 17330 216.41.40.61 (28 Jul 2000 19:09:46 GMT) X-Complaints-To: news@magrathea.cosmic.com To: vsta@zendo.com In article <200007271439.HAA00263@vandys-pc.zendo.com>, Andy Valencia wrote: >[mirian@cosmic.com (Mirian Crzig Lennox) writes:] > >It should very nearly be as simple as running make. You'll want to use a >cross compiler (VSTa is a known target for the GNU tools), not your native >(ELF) tool chain. Otherwise I can't think of anything major to get in your >way. The good news is that this is very close to the truth. I built i386-aout-vsta cross-compilers for gcc-2.7.2.3 and binutils-2.8.1 (the versions which come with VSTa 1.6.3) and it mostly works. Yay! However, it seems there are a few executables that the make builds and uses along the way which expect to be run under the VSTa OS, and which would have to be ported to Linux (or whatever host OS). The ones I've run into so far are mkshlib, genassym and dbsym. Also the makefiles need some minor tweaks so that the host compiler not the cross compiler builds those things. If this is considerd interesting to other people working on VSTa, I'll be happy to submit whatever changes I needed to make to get it working. --Mirian From daemon Tue Sep 5 23:35:14 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e85NZEg28759 for vsta-xplod; Tue, 5 Sep 2000 23:35:14 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e85NZ4R28739 for ; Tue, 5 Sep 2000 23:35:04 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id JAA10613 for ; Wed, 6 Sep 2000 09:47:17 +0200 Date: Wed, 6 Sep 2000 09:47:09 +0200 (CEST) From: Erik Dalen To: vsta@zendo.com Subject: fpu emulation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've been having a lot of problems getting my computers to work lately. The problem on some of them was probably because they were 486sx'es (without fpu). So I'm wondering how difficult task would it be to make an fpu emulation for VSTa? port the linux/BSD one? /Erik From daemon Wed Sep 6 06:49:19 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e866nJg29348 for vsta-xplod; Wed, 6 Sep 2000 06:49:19 GMT Received: from vandys-pc.zendo.com (dialup-63.214.13.233.Seattle1.Level3.net [63.214.13.233]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e866nBR29340; Wed, 6 Sep 2000 06:49:11 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id HAA00309; Wed, 6 Sep 2000 07:58:45 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009061458.HAA00309@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: fpu emulation In-reply-to: Your message of "Wed, 06 Sep 2000 09:47:09 +0200." Date: Wed, 06 Sep 2000 07:58:45 -0700 From: Andy Valencia [Erik Dalen writes:] >I've been having a lot of problems getting my computers to work lately. >The problem on some of them was probably because they were 486sx'es >(without fpu). So I'm wondering how difficult task would it be to make an >fpu emulation for VSTa? port the linux/BSD one? The interesting part is how to do it in a "microkernel" sort of way. It'd no doubt be easy enough to pull the FPU emulation from a monolithic kernel, and paste it into the VSTa kernel. But... ick. You'd have to review its design carefully anyway to handle the preemptive, SMP, and multi-threaded issues. But even then, why bloat a kernel which has avoided bloat for so long? So instead, the question is how to attach it to the FPU-using process's address space, and intercept math faults? In the latest release, the raw event handling system calls of VSTa have been wrapped in an event registry. POSIX signal emulation uses that, and it seems like a nice place for FPU emulation to attach, too. But to have this automatically present means that each process (at least each using floating point) has to "arm" this handler. A clever way of doing this without an impact on integer-only programs would be nice. I've always got about this far in my thinking, and then I look at how few SX chips are left in the world. :-> Andy Valencia From daemon Wed Sep 6 13:16:00 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e86DG0B29949 for vsta-xplod; Wed, 6 Sep 2000 13:16:00 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e86DFrR29929 for ; Wed, 6 Sep 2000 13:15:53 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.9.3/8.9.3) with ESMTP id XAA00830 for ; Wed, 6 Sep 2000 23:28:12 +0200 Date: Wed, 6 Sep 2000 23:28:12 +0200 (CEST) From: Erik Dalen To: vsta@zendo.com Subject: Re: fpu emulation In-Reply-To: <200009061458.HAA00309@vandys-pc.zendo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Sep 2000, Andy Valencia wrote: > The interesting part is how to do it in a "microkernel" sort of way. It'd > no doubt be easy enough to pull the FPU emulation from a monolithic kernel, > and paste it into the VSTa kernel. But... ick. You'd have to review its > design carefully anyway to handle the preemptive, SMP, and multi-threaded > issues. But even then, why bloat a kernel which has avoided bloat for so > long? > > So instead, the question is how to attach it to the FPU-using process's > address space, and intercept math faults? In the latest release, the raw > event handling system calls of VSTa have been wrapped in an event registry. > POSIX signal emulation uses that, and it seems like a nice place for FPU > emulation to attach, too. But to have this automatically present means that > each process (at least each using floating point) has to "arm" this handler. > A clever way of doing this without an impact on integer-only programs would > be nice. > > I've always got about this far in my thinking, and then I look at how few SX > chips are left in the world. :-> well, no doubt SX is a dying kind.. but as terminal I think a 486sx-50 would do just fine or perhaps a mc68030-33 without FPU... but still something like this might be needed in the future perhaps for MMX emulation on non-MMX processors (even thought I don't think that will ever be needed considering the small increase in speed mmx gives... but there is/will be similar extensions...) but btw, I also had problems with the newest release to start some like vi, emacs, less and more. I haven't checked if it will work on some a bit more recent computer, but will very soon. And when I tried to do anything in / (a FAT-16 filesystem mounted there) the dos driver died and said: rw.c/165: pack_error: null in extesion. all other directories on the fat drive works all right with long filenames and all (yippie) /Erik From daemon Thu Sep 7 07:04:45 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8774jD01352 for vsta-xplod; Thu, 7 Sep 2000 07:04:45 GMT Received: from tribble.eps.inso.com ([198.112.118.8]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8774dR01332 for ; Thu, 7 Sep 2000 07:04:40 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA26127 for ; Thu, 7 Sep 2000 11:15:59 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: fpu emulation Date: Thu, 7 Sep 2000 11:22:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > but still something like this might be needed in the future perhaps for > MMX emulation on non-MMX processors (even thought I don't think that will > ever be needed considering the small increase in speed mmx gives... but > there is/will be similar extensions...) How about something akin to VMWare... you could emulate the protected instructions. Maybe the right way would be to have a simple program (call it "fpuemu"?) that registered the handlers, and then forked and exec'd such that traps from the child were also caught? From daemon Thu Sep 7 07:21:21 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e877LLs01389 for vsta-xplod; Thu, 7 Sep 2000 07:21:21 GMT Received: from vandys-pc.zendo.com (dialup-63.214.12.27.Seattle1.Level3.net [63.214.12.27]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e877LER01382; Thu, 7 Sep 2000 07:21:15 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00314; Thu, 7 Sep 2000 08:30:50 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009071530.IAA00314@vandys-pc.zendo.com> To: "Gavin Thomas Nicol" cc: vsta@zendo.com Subject: Re: fpu emulation In-reply-to: Your message of "Thu, 07 Sep 2000 11:22:52 EDT." Date: Thu, 07 Sep 2000 08:30:50 -0700 From: Andy Valencia ["Gavin Thomas Nicol" writes:] >Maybe the right way would be to have a simple program (call it "fpuemu"?) >that registered the handlers, and then forked and exec'd such that traps >from the child were also caught? Taking this tack would be a nice step on the way to permitting full emulation of any arbitrary OS. The debugging hooks (ptrace()) would probably be an example of a subset of what would need to be intercepted. And since VSTa's ptrace() already parameterizes much of what kinds of events should be intercepted, it seems like it'd be pretty easy to extend it to permit, say, interception of certain classes of events. Nice! Andy From daemon Mon Sep 18 09:57:23 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8I9vNr21669 for vsta-xplod; Mon, 18 Sep 2000 09:57:23 GMT Received: from malasada.lava.net ([64.65.64.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8I9vHm21649 for ; Mon, 18 Sep 2000 09:57:17 GMT Received: from localhost (826 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Mon, 18 Sep 2000 08:18:57 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #1 built 2000-May-15) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: Re: fpu emulation/btw To: erik@jpl.nu (Erik Dalen) Date: Mon, 18 Sep 2000 08:18:57 -1000 (HST) Cc: vsta@zendo.com In-Reply-To: from "Erik Dalen" at Sep 6, 0 11:28:12 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > but btw, I also had problems with the newest release to start some > like vi, emacs, less and more. I haven't checked if it will work on some > a bit more recent computer, but will very soon. same here. After I rebuild the libs, it worked fine. Perhaps a problem loading the termcap shared lib? > /Erik Tim N. From daemon Tue Sep 19 03:03:41 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8J33fR23013 for vsta-xplod; Tue, 19 Sep 2000 03:03:41 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8J33am22993 for ; Tue, 19 Sep 2000 03:03:36 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id NAA16729 for ; Tue, 19 Sep 2000 13:25:10 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Tue Sep 19 13:25:00 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id NAA19733 for ; Tue, 19 Sep 2000 13:25:00 +0200 (CEST) To: vsta@zendo.com Subject: New to vsta X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Tue, 19 Sep 2000 13:24:59 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/19/2000 01:25:00 PM, Serialize complete at 09/19/2000 01:25:00 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8J33bm22994 Hello I'm really new to vsta. It looks very interesting. I had a look at some othere small OSses (minix, rtems), but found them too limited or not ready for to be used as a standalone OS (tools etc...) I wanted to ask the following: There is a gui called MGR (which I didn't get to compile under linux) for vsta. How do GUIs connect to VSTa. Is there something like a framebuffer interface? Can you tell me the smallest server, so that I can learn how the usermode servers communicate with the microkernel or with each other? Thanx -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Tue Sep 19 07:41:20 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8J7fKE23364 for vsta-xplod; Tue, 19 Sep 2000 07:41:20 GMT Received: from vandys-pc.zendo.com (dialup-209.245.175.45.Seattle1.Level3.net [209.245.175.45]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8J7f9m23357; Tue, 19 Sep 2000 07:41:10 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA00324; Tue, 19 Sep 2000 09:00:07 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009191600.JAA00324@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: New to vsta In-reply-to: Your message of "Tue, 19 Sep 2000 13:24:59 +0200." Date: Tue, 19 Sep 2000 09:00:07 -0700 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >There is a gui called MGR (which I didn't get to compile under linux) for >vsta. How do GUIs connect to VSTa. Is there something like a framebuffer >interface? Look in vsta/mgr/src/libbitblit/colorport and you'll see the bitblit driver which MGR uses to paint the screen. It actually accesses the hardware by way of the svgalib code (vsta/src/bin/ports/svgalib). >Can you tell me the smallest server, so that I can learn how the usermode >servers communicate with the microkernel or with each other? The semaphore server (vsta/src/srv/sema) is pretty simple. Also, I've attached some text I have floating around, written by Eric Jacobs. Regards, Andy Valencia ================================ In VSTa, a server is a process that creates one or more message ports and presumably receives on them every once in a while. Other than that, they're no different from any other process. They run as user code and can make any system calls that other processes can. They can be clients to other servers as well as being a server itself. For example, if you run vstafs on your hard disk, then vstafs is a client to wd and server to sh, ls, gcc, etc, whatever process is using that filesystem. In this way the process has two different "faces" to the operating system. Any process can behave this way. (What would you call 'em, servents? Or cliers?) Servers are also invoked just as you would other processes. If you decide you need to use the floppy drive in the middle of a session, just do: # fd & Don't forget the &, as otherwise you connect your terminal to fd, and fd doesn't interact on stdin or stdout. There's nothing saying it couldn't, however, as a matter of convention, servers run unattended and don't usually expect to talk to a human user. To be considered a server, a process creates a message port using the syscall msg_port(). There are basically two ways to call it: handle = msg_port(###, NULL); handle = msg_port(NULL, &portname); You would use the first syntax if you wanted to establish the server on a specific global port name, which you would specify as the first parameter. There are a couple of officially assigned port names in the VSTa headers. You can, of course, pick any number you like, but msg_port() will fail if that number is already taken. Mostly likely you'll want to use the second form. In this case, the system will pick a port number for you and store it in the variable whose address you pass in the second parameter. This is usually what you want. Then you can give that port number to other processes. That's the number they'll use to connect to your server. The VSTa standard service namer allows servers to associate their port numbers with text identifiers in a global, hierarchical namespace. So, for instance, programs can use //fs/root:a/b/c instead of //1025:a/b/c. The library function namer_register() can do the grudge work for you. Lookup helper functions are also included in the library. The value that's returned by msg_port is your process's private handle on to that message port. Don't pass this value to other processes; it has no meaning in their context. It is not the same as the global port name. Note that you can create multiple ports if you want to. The limit is defined in the kernel; I think it is set to 4 currently. Most servers will only need one message port. To handle messages that come in from clients, you would use the msg_receive syscall: struct msg m; x = msg_receive(handle, &m); This is a blocking call that waits for the next message to come in from any client (or potential client.) The message structure has the following fields: m_sender : an opaque number used to identify the client m_op : this is the operation code. It's either a number that the client gave in its msg_send() call, or a kernel-generated (and trusted) M_ system message. See below. m_arg : a single argument to go with the operation. m_arg1 : another argument for the operation. (Not usually used.) m_nseg : The number of data buffers that the client has sent. Usually only one, but clients can send up to four buffers in a single call. Servers should handle clients who send more than one buffer at a time. (There are library functions to help with this.) m_seg : An array of buffer definitions that the client sent. m_buf : A quick way to reference the first buffer. m_buflen : A quick way to reference the length of the first buffer. If msg_receive() returns a negative number, the receive operation was interrupted by an event while waiting for a client. Bit 31 of m_op, known as M_READ, has a special meaning. It is used to indicate the direction of data flow between the client and server. If clear, it means that the client is sending buffers to the server. If set, it means that the server is sending buffers to the client. It's the client's responsibility to get the value of M_READ right. The server will usually mask it out. If a client asks for FS_READ instead of FS_READ|M_READ, for example, the server will work just fine; however, the kernel will never transfer the buffers to the client. Once a msg_receive() has returned successfully, the client will be blocked waiting for some kind of response from the server. In general, the two possible responses (but see below) are msg_reply(), indicating success (you can pass an integer back, as the return value for msg_send()), and msg_err(), with which you can pass back an error string. Message operation codes that are at or below the predefined constant M_RESVD are reserved for the kernel; ordinary clients can't deliberately send them with msg_send(). The most important ones are the following: M_CONNECT : a client is trying to connect. The m_buf contains a trusted array of the user's permissions. In this case, you don't use msg_reply() to indicate success. You rather use msg_accept() instead. Errors are still reported with msg_err(). M_DISCONNECT: a client has disconnected. This message is a bit different in that it is asynchronous: no reply is necessary; the client is already gone. M_DUP : a client has requested a clone of this connection instance. Essentially, the client becomes two initially identical clients, each independent from then on. This is necessary for fork() as well as the clone() syscall. In general, servers should let their clients clone themselves. M_ABORT : the client is no longer requesting the operation. Happens when the client is interrupted (by event, for example) while they're waiting for the server to respond. You'll likely only need to do any processing for this message if you poll for messages in between the msg_receive() and the msg_reply()/msg_err() of a client operation (i.e., you're asynchronous). In that case, you need to clear the asynchronous request and msg_reply() to the M_ABORT. If you're not asynchronous, too late; you've already replied and your message has been thrown out. In this case, just msg_reply() to the M_ABORT. M_ISR : this message is sent by the kernel when a hardware interrupt has occurred that your server has requested. You must have enabled the IRQ in order to receive this message. Messages above M_RESVD are user messages. The most common ones are the filesystem messages: All devices: FS_STAT FS_WSTAT - these handle reading and writing of attributes Character special: (pipes, console, serial, TCP, etc.) above plus: FS_READ FS_WRITE Files: all above plus FS_SEEK FS_ABSREAD FS_ABSWRITE - optional, these two combine a seek and r/w operation Directories/file systems: all above except FS_WRITE and FS_ABSWRITE plus FS_OPEN FS_RENAME FS_REMOVE In the case of FS_OPEN, the client descends a level into the hierarchy. The client is then "inside" the file they opened. The other two manipulate the current directory, but don't change the client. FS_READ on a directory reads a list of names of items that may be FS_OPEN'ed. Any other messages can be defined; the messages numbers are not interpreted by the kernel at all. I would encourage the creation of additional classes of message operations if a server has actions that do not fit well into the already existing message codes. (Some VSTa servers, such as sema, insist on using the FS_ message codes even though they don't really make sense in what the server has to do.) Hopefully this will get you started. Also don't be afraid to look at the source of some of the VSTa servers. They're well commented. A couple of other things: message ports exist in a process-wide context; they aren't associated with any particular thread. Any thread may receive messages on any port. If two threads msg_receive on the same port at the same time, one will get the next message, the other will get the message after that. However, the most common use of threads in servers is to have one run the message loop while the others do client operations. From daemon Tue Sep 19 20:57:23 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8JKvNI00526 for vsta-xplod; Tue, 19 Sep 2000 20:57:23 GMT Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8JKvI900506 for ; Tue, 19 Sep 2000 20:57:18 GMT Received: from localhost (2119 bytes) by malasada.lava.net via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Tue, 19 Sep 2000 14:01:40 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #1 built 2000-May-15) Message-Id: From: newsham@lava.net (Tim Newsham) Subject: user configurability To: vsta@zendo.com Date: Tue, 19 Sep 2000 14:01:40 -1000 (HST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I was looking through some of the lib code the other day, and in particular the shared lib stuff, and it dawned on me that in some ways VSTa is not as configurable as it could (should?) be. Each user is free to set up their own mount table to customize their environment. Some items, though, are accessed through fixed port numbers and do not allow a user to replace them. In the case of the shared libraries, the loader requires that libs exist in /vsta/lib on the partition registered as fs/root in the namer. Further, the namer is gotten through the hardwired port "1". Many other services also use the fixed namer port for locating things. I was thinking that there may be situations where it would be desirable to set up a completely custom version of the root directory. In less extreme situations a user may wish to provide his own lib directory. In the first situation, it would be nice if one could set up their own custom namer, or perhaps use the existing namer to set up a sub-namespace to use. In the second situation, it would be nice if the loaders were able to traverse filesystems to search for the lib directory. How hard would it be for the loader to get access to the mount table that is passed across an exec? I dont imagine that the fs walking code would take up much more space. Perhaps it could even be put in the second stage loader, so that the first loader does not have to grow at all. It should also be quite easy to find the namer through a lib call that first tried to find the namer at a fixed path in the mount table, or perhaps through an env variable, and then fell back to using port 1 if that technique failed (for example, during the boot process). I guess the question is, are such changes warranted? Comments? Tim N. From daemon Tue Sep 19 22:06:25 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8JM6Po00737 for vsta-xplod; Tue, 19 Sep 2000 22:06:25 GMT Received: from vandys-pc.zendo.com (dialup-209.245.163.69.Seattle1.Level3.net [209.245.163.69]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8JM6H900730; Tue, 19 Sep 2000 22:06:18 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id XAA00609; Tue, 19 Sep 2000 23:27:39 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009200627.XAA00609@vandys-pc.zendo.com> To: newsham@lava.net (Tim Newsham) cc: vsta@zendo.com Subject: Re: user configurability In-reply-to: Your message of "Tue, 19 Sep 2000 14:01:40 -1000." Date: Tue, 19 Sep 2000 23:27:39 -0700 From: Andy Valencia [newsham@lava.net (Tim Newsham) writes:] >I was looking through some of the lib code the other day, >and in particular the shared lib stuff, and it dawned >on me that in some ways VSTa is not as configurable as >it could (should?) be. Each user is free to set up their >own mount table to customize their environment. Some >items, though, are accessed through fixed port numbers >and do not allow a user to replace them. In the case >of the shared libraries, the loader requires that libs >exist in /vsta/lib on the partition registered as fs/root >in the namer. Further, the namer is gotten through >the hardwired port "1". Many other services also use >the fixed namer port for locating things. I guess I always assumed the namer would be global, since for arbitrary parts of the system to "come together" there has to be something, somewhere, which operates in a common fashion. As for shared libraries, I absolutely agree that the system should be more open. However, note that the base (DLL style) shared libraries don't scale well. Coincidentally, I recently added (in the latest vsta/doc/todo) a note to add on PIC-style shared libraries for any libraries which don't fit into the basic system DLL set. But anyway, the reason DLL shared libraries load in two stages was so that the first level loader (in vsta/lib/ld.shl) could be switched from its current basic form to something more flexible. >I was thinking that there may be situations where it >would be desirable to set up a completely custom >version of the root directory. In less extreme situations >a user may wish to provide his own lib directory. >In the first situation, it would be nice if one could >set up their own custom namer, or perhaps use the >existing namer to set up a sub-namespace to use. In >the second situation, it would be nice if the loaders >were able to traverse filesystems to search for the >lib directory. I think it would be OK to come up with a way to insert a port renaming layer on top of the process context. I think it could be done within libc, although you'll have to add all the stuff needed to have it inherited across an exec(). Or again, to go back to the previous discussion, this could certainly be done within a virtualized OS environment! >How hard would it be for the loader to get access to >the mount table that is passed across an exec? I >dont imagine that the fs walking code would take up >much more space. Perhaps it could even be put in the >second stage loader, so that the first loader does not >have to grow at all. Since the mount table is in libc, and the loader is used to load libc, there's a teensy little problem.... :-> Yes, the loader could be taught to pick through the exec argument buffer area (which, of course, is where the mount table, among other state, comes across). But perhaps a nicer way to deal with this is a wstat extension to namer. Imagine a "prefix=/vandys" wstat operation to namer, which would cause it to start treating all path lookups from that client (and all clients cloned from that one--so all child processes would get the prefix too) as if they had an initial put on'em. So then you could set up your own namer mappings, and then activate a prefix to where you set them up, and then launch a shell (or whatever). That doesn't seem like it'd be too hard to implement, and it would let you virtualize the namer services to a certain extent. >It should also be quite easy to find the namer through >a lib call that first tried to find the namer at a fixed >path in the mount table, or perhaps through an env variable, >and then fell back to using port 1 if that technique failed >(for example, during the boot process). Again, since the namer is used to find and load the code which implements both mount tables and environment variables, you'll find yourself shoveling quite a lot of code into this library loading code to break this dependency. >I guess the question is, are such changes warranted? If you could fiddle the namer prefix, you can redirect any server access which uses a namer name. The one major thing which remains is the namer itself (at well known port 1). But if namer lets you redirect everything which comes to it, is it still necessary to also permit access to namer to be redirected? If this approach is sufficient, the good news is that you don't need much more than a little code added to namer. This is *way* easier than messing with the DLL bootstrap code! Andy Valencia From daemon Tue Sep 19 22:53:34 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8JMrYm00832 for vsta-xplod; Tue, 19 Sep 2000 22:53:34 GMT Received: from gate1.mn.man.de (gate1.mn.man.de [151.136.100.130]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8JMrU900812; Tue, 19 Sep 2000 22:53:30 GMT Received: (from root@localhost) by gate1.mn.man.de (8.9.0/8.9.0) id JAA25159; Wed, 20 Sep 2000 09:17:35 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate1.mn.man.de (1.0 SMTP-GW) with SMTP; Wed Sep 20 09:17:33 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id JAA05469; Wed, 20 Sep 2000 09:17:33 +0200 (CEST) To: Andy Valencia Cc: vsta@zendo.com Subject: Antwort: Re: New to vsta X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Wed, 20 Sep 2000 08:58:21 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/20/2000 09:17:33 AM, Serialize complete at 09/20/2000 09:17:33 AM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8JMrV900813 Thanks for these informations. It's bad, that there are people who say, that vsta seems to be dead. And even I saw a 1.64 Version, all the webpage and the changelogs etc. are just talking about 1.63 or 1.62. Is there a need for to update these pages, or is the project really dead? (I think such projects are never really dead.) I'm very stressed in the moment (we have a migration running on hp-ux servers), but I could think of helping to maintain the pages in my freetime a bit in the near future, if this would be possible. Often the first view on the project gives the kick. I was surprised, that there was (outdated) a port to MIPS system. I have a Windows CE Organizer from Compaq which possibly could run vsta. But I think my C knowledge is much too limited. No Assemlber at all. In the last time a had a look on the old Atari ST community and was surprised, that GEM is now open source. These days allthe OS and the GUI fit into 192 KB ROM. Wouldn't it be possible to write a VDI (graphics primitives) and a AES (Application Enviroment Services) Server for VSTa? Or port for example Microwindows, which also can run on top of SVGAlib?!? The good thing about GEM would be, that it brings a whole enviroment (printing, Metafiles etc.) with it. -------------------------------------------------------------------------------------------------------- Martin Döring, E-Mail: Martin_Doering@mn.man.de From daemon Wed Sep 20 07:21:09 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8K7L9Y01566 for vsta-xplod; Wed, 20 Sep 2000 07:21:09 GMT Received: from vandys-pc.zendo.com (dialup-209.245.161.25.Seattle1.Level3.net [209.245.161.25]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8K7L2901558; Wed, 20 Sep 2000 07:21:02 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00340; Wed, 20 Sep 2000 08:42:24 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009201542.IAA00340@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: Antwort: Re: New to vsta In-reply-to: Your message of "Wed, 20 Sep 2000 08:58:21 +0200." Date: Wed, 20 Sep 2000 08:42:24 -0700 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >It's bad, that there are people who say, that vsta seems to be dead. And >even I saw a 1.64 Version, all the webpage and the changelogs etc. are >just talking about 1.63 or 1.62. Is there a need for to update these >pages, or is the project really dead? (I think such projects are never >really dead.) Well, not dead, really. And 1.6.4 was put there in preparation for the 1.6.4 release, but what's sitting on the web site has a couple flaws, thus I hadn't switched anything over. >I'm very stressed in the moment (we have a migration running on hp-ux >servers), but I could think of helping to maintain the pages in my >freetime a bit in the near future, if this would be possible. Often the >first view on the project gives the kick. I'm certainly no wizard with WWW! If you wanted to webcopy the tree and then tune up the layout and content, we could probably set up some sort of periodic refresh of the web server's tree. >In the last time a had a look on the old Atari ST community and was >surprised, that GEM is now open source. These days allthe OS and the GUI >fit into 192 KB ROM. Wouldn't it be possible to write a VDI (graphics >primitives) and a AES (Application Enviroment Services) Server for VSTa? >Or port for example Microwindows, which also can run on top of SVGAlib?!? >The good thing about GEM would be, that it brings a whole enviroment >(printing, Metafiles etc.) with it. The more ported, the better. I'm very open to suggestions. And I'll be happy to fold anything ported into vsta/src/bin/ports and make it available through the distribution. Andy From daemon Wed Sep 20 09:53:31 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8K9rVD01853 for vsta-xplod; Wed, 20 Sep 2000 09:53:31 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8K9rP901820 for ; Wed, 20 Sep 2000 09:53:25 GMT Received: from groundbreaker (modem_a [199.93.212.243]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id OAA23040 for ; Wed, 20 Sep 2000 14:16:43 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: user configurability Date: Wed, 20 Sep 2000 14:17:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > I was thinking that there may be situations where it > would be desirable to set up a completely custom > version of the root directory. In less extreme situations > a user may wish to provide his own lib directory. > In the first situation, it would be nice if one could > set up their own custom namer, or perhaps use the > existing namer to set up a sub-namespace to use. In > the second situation, it would be nice if the loaders > were able to traverse filesystems to search for the > lib directory. Hmmm. This could be useful from a security perspectvie too... the objects that something could connect to would become a function of the locally scoped environment rather than a function of the global naming service. Perhaps the trick is to not rely upon the file system for resolving shared libraries, but to instead use the namer? That way any library could be overridden in the local namespace. That would kind of smell like COM, I know... From daemon Wed Sep 20 09:53:31 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8K9rVa01861 for vsta-xplod; Wed, 20 Sep 2000 09:53:31 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8K9rQ901822 for ; Wed, 20 Sep 2000 09:53:26 GMT Received: from groundbreaker (modem_a [199.93.212.243]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id OAA23043 for ; Wed, 20 Sep 2000 14:16:44 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: Antwort: Re: New to vsta Date: Wed, 20 Sep 2000 14:17:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009201542.IAA00340@vandys-pc.zendo.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > >The good thing about GEM would be, that it brings a whole enviroment > >(printing, Metafiles etc.) with it. I had a look through the GEM source... it'd be a bit of a challenge I think. From daemon Thu Sep 21 01:22:09 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8L1M9r02929 for vsta-xplod; Thu, 21 Sep 2000 01:22:09 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8L1M5902909 for ; Thu, 21 Sep 2000 01:22:05 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id LAA03341 for ; Thu, 21 Sep 2000 11:46:12 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Thu Sep 21 11:45:58 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id LAA07055 for ; Thu, 21 Sep 2000 11:45:58 +0200 (CEST) To: vsta@zendo.com Subject: grub configuration X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Thu, 21 Sep 2000 11:39:59 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/21/2000 11:45:58 AM, Serialize complete at 09/21/2000 11:45:58 AM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8L1M6902910 Hi! Yesterday in the evening I got vsta up and running the first time. I booted from floppy und used the first partition of my harddisk (fat16). I wrote all the kernel and module parameters directly in. There is a file "menu.lst" from grub which I copied to my HD to C:\boot\grub\menu.lst, but it was ignored. How can I use a menu, where I put in all the stuff? I found the dokumentation of grub very irritating for the beginner. The "new" Gnu Grub is not available in a production release. As I was on the console of vsta, I could use a few commands, but I recognized, that there are many differences between Linux/HP-UX/Minix and vsta. Especially the namer says nearly nothing to me and at first I have to come behind, how this works. It seems to be essential. ;-) After this I would like to make some experiments. I never wrote some kernel or lowlevel stuff before. I just adopted a DOS GUI-Lib (PAL for the HP-LX Palmtop) to X11, but just used X11 primitives. So - I would like to see a GUI on VSTA, but I'm not shure, if I have the knowledge to do it myself?!? I will see... -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Thu Sep 21 07:07:04 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8L774v03418 for vsta-xplod; Thu, 21 Sep 2000 07:07:04 GMT Received: from vandys-pc.zendo.com (dialup-209.245.165.19.Seattle1.Level3.net [209.245.165.19]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8L76x903411; Thu, 21 Sep 2000 07:06:59 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA01429; Thu, 21 Sep 2000 08:28:31 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009211528.IAA01429@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: grub configuration In-reply-to: Your message of "Thu, 21 Sep 2000 11:39:59 +0200." Date: Thu, 21 Sep 2000 08:28:31 -0700 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >Yesterday in the evening I got vsta up and running the first time. Congratulations! I know this isn't as easy as buying Windows 98 installed on your laptop. :-> >I booted from floppy und used the first partition of my harddisk (fat16). I >wrote all the kernel and module parameters directly in. There is a file >"menu.lst" from grub which I copied to my HD to C:\boot\grub\menu.lst, but >it was ignored. How can I use a menu, where I put in all the stuff? I >found the dokumentation of grub very irritating for the beginner. The >"new" Gnu Grub is not available in a production release. Yes, and I really don't know exactly how to go forward on this. Make our own GRUB documentation? Doesn't seem right. If any of you want to submit documentation improvements to the GRUB project, that'd be very welcome on this side. I assume they would use them! Anyway, the way menu.lst gets used depends on the level 2 boot loader. This should be located on your disk (usually in \boot\grub\stage2). When you use the "install=" command to create a bootable disk, it does a LILO-style record of the sector locations of the that file. I'm pretty sure that the menu.lst comes from the same place as the stage2. Does this mean you have to change the boot of your disk? No! You can do the install= onto a *floppy*, but with the stage2 coming from your hard disk. I've used this myself in cases where I didn't want to mess with the boot of (usually somebody else's) PC. This exact case is covered in the documentation. >As I was on the console of vsta, I could use a few commands, but I >recognized, that there are many differences between Linux/HP-UX/Minix and >vsta. Especially the namer says nearly nothing to me and at first I have >to come behind, how this works. It seems to be essential. ;-) You don't need to worry too much about things like namer right off the bat. Probably perusing the sample user accounts and then the header files in /vsta/include is a good way to start. >After this I would like to make some experiments. I never wrote some >kernel or lowlevel stuff before. I just adopted a DOS GUI-Lib (PAL for the >HP-LX Palmtop) to X11, but just used X11 primitives. So - I would like to >see a GUI on VSTA, but I'm not shure, if I have the knowledge to do it >myself?!? I will see... See svgalib (vsta/bin/ports/svgalib) for a decent way to get down to the low-level graphics layer. Higher level is MGR, but from a graphics perspective it's pretty limited. Regards, Andy From daemon Thu Sep 21 12:15:24 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LCFOg03939 for vsta-xplod; Thu, 21 Sep 2000 12:15:24 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8LCFJ903919 for ; Thu, 21 Sep 2000 12:15:19 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id QAA23662 for ; Thu, 21 Sep 2000 16:38:41 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: SourceForge Date: Thu, 21 Sep 2000 16:46:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009211528.IAA01429@vandys-pc.zendo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Any though of moving to sourceforge? Seems like it's make coordination a bit easier. From daemon Thu Sep 21 12:31:28 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LCVSe03978 for vsta-xplod; Thu, 21 Sep 2000 12:31:28 GMT Received: from vandys-pc.zendo.com (dialup-209.245.164.45.Seattle1.Level3.net [209.245.164.45]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8LCVK903970; Thu, 21 Sep 2000 12:31:21 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA00253; Thu, 21 Sep 2000 13:52:44 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009212052.NAA00253@vandys-pc.zendo.com> To: "Gavin Thomas Nicol" cc: vsta@zendo.com Subject: Re: SourceForge In-reply-to: Your message of "Thu, 21 Sep 2000 16:46:00 EDT." Date: Thu, 21 Sep 2000 13:52:43 -0700 From: Andy Valencia ["Gavin Thomas Nicol" writes:] >Any thought of moving to sourceforge? Seems like >it's make coordination a bit easier. Yes, quite a bit of thought--I even got a SourceForge project allocated. One trivial problem--ssh access for CVS. I just haven't had much luck finding a simple set of ssh source to compile for my (FreeBSD) development system. More fundamentally, it looks like a given project has no granularity with respect to who gets to modify what. I'm comfortable with neither having the whole thing open to any contribitor, nor with having to spin off a number of SourceForge projects (even if SF didn't mind). So I'm still thinking about vstafs/RCS source control, with distributed VSTa messaging to permit remote developers to directly control their parts of the tree. I'll need to have a 7/24 VSTa server running to permit this, but that doesn't seem like a big deal. Another key piece is the need for our lousy networking card coverage (still just NE2000) to improve. I foresee ISA slots becoming a novelty in the very near future. Andy From daemon Thu Sep 21 12:44:23 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LCiN204016 for vsta-xplod; Thu, 21 Sep 2000 12:44:23 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8LCiH903996 for ; Thu, 21 Sep 2000 12:44:17 GMT Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id RAA25172 for ; Thu, 21 Sep 2000 17:07:38 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: SourceForge Date: Thu, 21 Sep 2000 17:14:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009212052.NAA00253@vandys-pc.zendo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal > More fundamentally, it looks like a given project has no granularity with > respect to who gets to modify what. That's a pretty serious issue, but at least CVS gives rollback capabilities. From daemon Thu Sep 21 12:48:26 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LCmQM04050 for vsta-xplod; Thu, 21 Sep 2000 12:48:26 GMT Received: from darkstar.welcomehome.org (darkstar.welcomehome.org [192.203.188.2]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8LCmK904030; Thu, 21 Sep 2000 12:48:20 GMT Received: (from rob@localhost) by darkstar.welcomehome.org (8.10.1/8.10.1) id e8LLAKh07371; Thu, 21 Sep 2000 15:10:20 -0600 (MDT) Date: Thu, 21 Sep 2000 15:10:20 -0600 From: Rob Savoye To: Andy Valencia Cc: Gavin Thomas Nicol , vsta@zendo.com Subject: Re: SourceForge Message-ID: <20000921151020.D6850@welcomehome.org> References: <200009212052.NAA00253@vandys-pc.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009212052.NAA00253@vandys-pc.zendo.com>; from Andy Valencia on Thu, Sep 21, 2000 at 01:52:43PM -0700 On Thu, Sep 21, 2000 at 01:52:43PM -0700, Andy Valencia wrote: > One trivial problem--ssh access for CVS. I just haven't had much luck > finding a simple set of ssh source to compile for my (FreeBSD) development > system. Bummer. SSH even runs on WinDoze and MacOS. It should build for FreeBSD. > More fundamentally, it looks like a given project has no granularity with > respect to who gets to modify what. I'm comfortable with neither having the > whole thing open to any contribitor, nor with having to spin off a number of I work on 3 projects on SourceForge, and maintain two of them. You have total control over checkin CVS access, but everyone else gets read only access. You, as the maintainer should be the only one to modify things like the web site, releases, etc... Anyway, I like it. Even though I have my own CVS & web server, I still host my projects on SourceForge. > doesn't seem like a big deal. Another key piece is the need for our lousy > networking card coverage (still just NE2000) to improve. I foresee ISA I recently used OSKit's device driver wrappers, so my netbooting program can support all NICS supported by FreeBSD. You might want to check that idea (of writing wrappers) out. - rob - From daemon Thu Sep 21 13:01:34 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LD1Yl04109 for vsta-xplod; Thu, 21 Sep 2000 13:01:34 GMT Received: from verdi.nethelp.no ([158.36.41.162]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id e8LD1T904086 for ; Thu, 21 Sep 2000 13:01:29 GMT Received: (qmail 37290 invoked by uid 1001); 21 Sep 2000 21:25:42 +0000 (GMT) To: rob@welcomehome.org Cc: vandys@zendo.com, gtn@ebt.com, vsta@zendo.com Subject: Re: SourceForge From: sthaug@nethelp.no In-Reply-To: Your message of "Thu, 21 Sep 2000 15:10:20 -0600" References: <20000921151020.D6850@welcomehome.org> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 21 Sep 2000 23:25:42 +0200 Message-ID: <37288.969571542@verdi.nethelp.no> > > One trivial problem--ssh access for CVS. I just haven't had much luck > > finding a simple set of ssh source to compile for my (FreeBSD) development > > system. > > Bummer. SSH even runs on WinDoze and MacOS. It should build for FreeBSD. FreeBSD 4.1 has OpenSSH in the base system. For earlier versions I've been able to build ssh-1.2.27 (for instance) out of the box - and the ports version also works nicely. What kind of problem are you seeing? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From daemon Thu Sep 21 16:16:52 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8LGGqu04393 for vsta-xplod; Thu, 21 Sep 2000 16:16:52 GMT Received: from millbrae.frotz.net (anonymous@[63.202.162.162]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8LGGk904373; Thu, 21 Sep 2000 16:16:47 GMT Received: by millbrae.frotz.net (Postfix, from userid 1000) id 9ADA3255A2; Thu, 21 Sep 2000 17:32:19 -0700 (PDT) Date: Thu, 21 Sep 2000 17:32:19 -0700 From: "Brian J. Swetland" To: Andy Valencia Cc: vsta@zendo.com Subject: Re: SourceForge (pci ne2k) Message-ID: <20000921173219.A95035@frotz.net> References: <200009212052.NAA00253@vandys-pc.zendo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: <200009212052.NAA00253@vandys-pc.zendo.com>; from vandys@zendo.com on Thu, Sep 21, 2000 at 01:52:43PM -0700 Organization: Frotz Communications, Ltd. X-Mailer-Holy-War: Get Mutt, it bites! [Andy Valencia ] > ["Gavin Thomas Nicol" writes:] > > I'll need to have a 7/24 VSTa server running to permit this, but that > doesn't seem like a big deal. Another key piece is the need for our lousy > networking card coverage (still just NE2000) to improve. I foresee ISA > slots becoming a novelty in the very near future. PCI NE2K is pretty simple to do and the cards (while cheesy) are readily available for $10-12 or so. Here's a code snippet that scans through PCI space (works with VIA and Intel chipsets, probably some others) for NE2K's that I use for a netboot rom: http://www.openblt.org/blt/netboot/pci.c Brian -- Brian J. Swetland | "If I have hacked deeper than them, it is because swetland@frotz.net | I stand in their trenches." -- Graham Nelson From daemon Fri Sep 22 02:25:58 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8M2PwF05149 for vsta-xplod; Fri, 22 Sep 2000 02:25:58 GMT Received: from fw.softwell.se (IDENT:root@[193.15.236.45]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8M2Pc905129; Fri, 22 Sep 2000 02:25:41 GMT Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id MAA17182; Fri, 22 Sep 2000 12:49:39 +0200 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id MAA30301; Fri, 22 Sep 2000 12:49:31 +0200 Date: Fri, 22 Sep 2000 12:49:31 +0200 From: Bengt Kleberg Message-Id: <200009221049.MAA30301@trillian.softwell.se> To: rob@welcomehome.org, vandys@zendo.com Subject: Re: SourceForge Cc: gtn@ebt.com, vsta@zendo.com > SSH even runs on WinDoze and MacOS. It should build for FreeBSD. If you find that it suites your other needs you might wamt to look at OpenBSD. It has ssh in the default install. From daemon Fri Sep 22 06:40:19 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8M6eJ505489 for vsta-xplod; Fri, 22 Sep 2000 06:40:19 GMT Received: from cosmic.com ([216.41.40.61]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8M6dG905465 for ; Fri, 22 Sep 2000 06:39:22 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id KAA17160 for vsta@zendo.com; Fri, 22 Sep 2000 10:26:32 -0400 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: SourceForge Date: 22 Sep 2000 10:26:31 -0400 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 14 Message-ID: <8qfq6n$go3$1@trantor.cosmic.com> References: <200009212052.NAA00253@vandys-pc.zendo.com> X-Trace: trantor.cosmic.com 969632791 17156 10.10.10.1 (22 Sep 2000 14:26:31 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article <200009212052.NAA00253@vandys-pc.zendo.com>, Andy Valencia wrote: >One trivial problem--ssh access for CVS. I just haven't had much luck >finding a simple set of ssh source to compile for my (FreeBSD) development >system. What version of FreeBSD are you using? If you're using the latest (4.1), you don't need to compile anything, just select the crypto options in the install (I usually get everything but Kerberos). If you're not using 4.1, you should consider upgrading, it's nice. --Mirian From daemon Fri Sep 22 06:41:01 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8M6f1d05513 for vsta-xplod; Fri, 22 Sep 2000 06:41:01 GMT Received: from cosmic.com ([216.41.40.61]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8M6eT905493 for ; Fri, 22 Sep 2000 06:40:41 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id KAA17214 for vsta@zendo.com; Fri, 22 Sep 2000 10:34:13 -0400 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: SourceForge Date: 22 Sep 2000 10:34:12 -0400 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 13 Message-ID: <8qfql4$gpp$1@trantor.cosmic.com> References: <37288.969571542@verdi.nethelp.no> X-Trace: trantor.cosmic.com 969633252 17210 10.10.10.1 (22 Sep 2000 14:34:12 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article <37288.969571542@verdi.nethelp.no>, wrote: >FreeBSD 4.1 has OpenSSH in the base system. For earlier versions I've been >able to build ssh-1.2.27 (for instance) out of the box - and the ports >version also works nicely. What kind of problem are you seeing? Just a word of caution; I would stay away from ssh-1.2.27 when compiled with the RSAREF library. It's vulnerable to a buffer overflow exploit that can compromise your security. None of the version of OpenSSH, including the version which ships with FreeBSD 4.1, has this vulnerability. --Mirian From daemon Tue Sep 26 01:04:17 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8Q14Hi13599 for vsta-xplod; Tue, 26 Sep 2000 01:04:17 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8Q14B913579; Tue, 26 Sep 2000 01:04:12 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id LAA03486; Tue, 26 Sep 2000 11:28:34 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Tue Sep 26 11:28:18 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id LAA29115; Tue, 26 Sep 2000 11:28:18 +0200 (CEST) To: Andy Valencia Cc: vsta@zendo.com Subject: Re: Re: Web Site X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Tue, 26 Sep 2000 11:28:17 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/26/2000 11:28:18 AM, Serialize complete at 09/26/2000 11:28:18 AM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8Q14D913580 >I've Cc'ed Martin on this, since he has also expressed some interest. What >Martin and I had discussed was something as simple/dumb as a cron job on >www.vsta.org which would pull in a .tar.gz nightly (if it was present). >This lets the server continue to be a pretty nailed down environment. What would happen, if we bothe put a new (same) webpage on the server? -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Tue Sep 26 02:00:20 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8Q20KI13743 for vsta-xplod; Tue, 26 Sep 2000 02:00:20 GMT Received: from gate1.mn.man.de (gate1.mn.man.de [151.136.100.130]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8Q20D913723 for ; Tue, 26 Sep 2000 02:00:14 GMT Received: (from root@localhost) by gate1.mn.man.de (8.9.0/8.9.0) id MAA02778; Tue, 26 Sep 2000 12:24:20 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate1.mn.man.de (1.0 SMTP-GW) with SMTP; Tue Sep 26 12:24:18 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id MAA12313; Tue, 26 Sep 2000 12:24:17 +0200 (CEST) To: "Gavin Thomas Nicol" Cc: vsta@zendo.com Subject: Re: RE: Web Site X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Tue, 26 Sep 2000 12:24:16 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/26/2000 12:24:17 PM, Serialize complete at 09/26/2000 12:24:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8Q20F913724 >If you put a servlet environment and a relational database >on the server we could do dynamic delivery... but we don't >have to. For the moment, let's do it statically. Did you work with such systems? I found, that working with static pages can be very satisfying, if there is not a flood of information. Also I like it, if pages are not too much packed with gifs and such. If the website has a documentation character it could be good to keep it clean and clear - so people find , what they search for. This does not mean, that it needs to be ugly. What tools do you use for creating pages? -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Tue Sep 26 04:54:26 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8Q4sQq13954 for vsta-xplod; Tue, 26 Sep 2000 04:54:26 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8Q4sM913934 for ; Tue, 26 Sep 2000 04:54:22 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id PAA24229 for ; Tue, 26 Sep 2000 15:18:44 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Tue Sep 26 15:18:36 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id PAA24925 for ; Tue, 26 Sep 2000 15:18:36 +0200 (CEST) To: vsta@zendo.com Subject: Kernel and Usermode X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Tue, 26 Sep 2000 15:18:35 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/26/2000 03:18:36 PM, Serialize complete at 09/26/2000 03:18:36 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8Q4sN913935 If I have such a programm like MGR or any other graphics output I would need access to the video memory. How is this done, if all servers (modules) run in usermode (or don't they)? Do they have direct access to the hardware? Sorry, I had not had time to have a look on the svgalib code. :-( -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Wed Sep 27 15:57:30 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8RFvUC16402 for vsta-xplod; Wed, 27 Sep 2000 15:57:30 GMT Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8RFvP916382 for ; Wed, 27 Sep 2000 15:57:25 GMT Received: from endymion ([172.16.3.107]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id UAA09894; Wed, 27 Sep 2000 20:21:00 -0400 (EDT) From: "Gavin Thomas Nicol" To: Cc: Subject: RE: RE: Web Site Date: Wed, 27 Sep 2000 20:28:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Did you work with such systems? I design and build them... I like dynamic sites mostly because I hate worrying about hyperlink structures. I like to just add documents and have all the links on the site update themselves. I also like them because templating saves a lot of time and effort, and because you can reuse the information in different contexts. You can get some of the benefits if you do things in batch mode offline. From daemon Wed Sep 27 21:55:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e8RLtkT16861 for vsta-xplod; Wed, 27 Sep 2000 21:55:46 GMT Received: from gate1.mn.man.de (gate1.mn.man.de [151.136.100.130]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8RLte916841 for ; Wed, 27 Sep 2000 21:55:40 GMT Received: (from root@localhost) by gate1.mn.man.de (8.9.0/8.9.0) id IAA26247; Thu, 28 Sep 2000 08:20:05 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate1.mn.man.de (1.0 SMTP-GW) with SMTP; Thu Sep 28 08:19:51 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id IAA21068; Thu, 28 Sep 2000 08:19:50 +0200 (CEST) To: "Gavin Thomas Nicol" Cc: vsta@zendo.com Subject: RE: Web Site X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Thu, 28 Sep 2000 08:19:47 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 09/28/2000 08:19:50 AM, Serialize complete at 09/28/2000 08:19:50 AM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e8RLtf916842 >> Did you work with such systems? > >I design and build them... Hmpf... >I also like them because templating saves a lot of >time and effort, and because you can reuse the information >in different contexts. Yes, I know... I once wrote a website about concertina playing http://www.mucl.de/Home/mdoering/konzertina/ !!!OFFTOPIC!!! and I know, what you mean. On the other side I never had access to the webserver itself - so I just could do all these things offline. I also never used something like style sheets or templates, just some kind of "template webpage". I just concentrated on the content. The main thing, why I asked for to help was, that I thought we could make vsta much more popular, if we could make it easier for people to have a try. For example: The V2 OS developers created a bootloader for their OS, where you just start a single executable under DOS. This has the whole OS in it - that's quite easy! Possibly you should do more on the sites design - I could concentrate more on writing some howtos etc. Btw, do you have some tips (or tools) how to make this easier? I once tried out the docbook stuff and sgml tools, but found them too hard for the beginner and ery concentrated on the content - not on the design. Pages you get from it always look the same - everywhere. I would prefer some linux tools, even I ever worked (and want to) with wysiwyg editors, like netscape etc. -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Mon Oct 2 16:18:18 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e92GII300787 for vsta-xplod; Mon, 2 Oct 2000 16:18:18 GMT Received: from vandys-pc.zendo.com (dialup-209.245.162.34.Seattle1.Level3.net [209.245.162.34]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e92GHvd00780 for ; Mon, 2 Oct 2000 16:18:02 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id RAA00648 for ; Mon, 2 Oct 2000 17:42:03 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200010030042.RAA00648@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Status of VSTa web site Date: Mon, 02 Oct 2000 17:42:03 -0700 From: Andy Valencia Just an FYI... both FTP and HTTP are currently unavailable for VSTa, due to some crackers having moved in on the host machine. We're working on getting this cleaned up... HTTP will probably be back first, followed by FTP. It currently appears that we can keep mail going the whole time. Sorry for the inconvenience... it's really something of a shock for a net old-timer like myself to realize the extent of the deep, dark, slimy side to what goes on via the Internet. Oh, well. Andy Valencia From daemon Mon Oct 2 18:42:08 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e92Ig8600948 for vsta-xplod; Mon, 2 Oct 2000 18:42:08 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e92Ig2d00928 for ; Mon, 2 Oct 2000 18:42:02 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 11:20:09 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB71557BB@GERNT002> From: "Dines, Eric" To: "'vsta@zendo.com'" Subject: Grub under VMware for Linux Date: Tue, 3 Oct 2000 11:18:05 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I have just started using VMware for Linux, to try and simplify my development platform(s), but cannot get any of the versions of Grub to install on the virtual hard-disk. I keep getting a message "Stage1 Stage2 geom wrong" or something like that. Grub is 0.5.95, VMware is 2.02, Linux RH 6.2 I've got dos booting on it OK, and I can boot off a floppy with the kernel on the virtual disk, but I can't install it!!! I remember in the list that someone else go things going after a bit of trouble....Can you tell me how you did it please? Ironically the version that Andy packaged eons ago works fine on VMware for NT. regards Eric ------------------------------------------------------------------------- From daemon Tue Oct 3 09:33:56 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e939XuY09429 for vsta-xplod; Tue, 3 Oct 2000 09:33:56 GMT Received: from vandys-pc.zendo.com (dialup-209.244.110.228.Seattle1.Level3.net [209.244.110.228]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e939Xqd09422 for ; Tue, 3 Oct 2000 09:33:53 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id KAA06214 for ; Tue, 3 Oct 2000 10:58:26 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200010031758.KAA06214@vandys-pc.zendo.com> To: vsta@zendo.com Subject: VSTa resources are back Date: Tue, 03 Oct 2000 10:58:26 -0700 From: Andy Valencia Well, things went more smoothly than expected (both wu-ftpd and Apache are *very* slick these days!). WWW and FTP services should be back to normal, although file uploads to the FTP server are disabled (the kiddies use this to drop off warez to share with their friends). For the rare occasion this is needed, I can open up a suitable location. Andy From daemon Tue Oct 3 09:37:59 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e939bxd09465 for vsta-xplod; Tue, 3 Oct 2000 09:37:59 GMT Received: from vandys-pc.zendo.com (dialup-209.244.110.228.Seattle1.Level3.net [209.244.110.228]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e939brd09458; Tue, 3 Oct 2000 09:37:53 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id LAA06248; Tue, 3 Oct 2000 11:02:26 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200010031802.LAA06248@vandys-pc.zendo.com> To: "Dines, Eric" cc: "'vsta@zendo.com'" Subject: Re: Grub under VMware for Linux In-reply-to: Your message of "Tue, 03 Oct 2000 11:18:05 +0800." <3FC96A0BD509D411930500062950DFB71557BB@GERNT002> Date: Tue, 03 Oct 2000 11:02:26 -0700 From: Andy Valencia ["Dines, Eric" writes:] >I have just started using VMware for Linux, to try and simplify my >development platform(s), but cannot get any of the versions of Grub to >install on the virtual hard-disk. >I keep getting a message "Stage1 Stage2 geom wrong" or something like that. >Grub is 0.5.95, VMware is 2.02, Linux RH 6.2 >I've got dos booting on it OK, and I can boot off a floppy with the kernel >on the virtual disk, but I can't install it!!! This is probably an issue which the main grub development list would be interested in. All I can see concerning VMWare so far is: http://www.mail-archive.com/bug-grub@gnu.org/msg01954.html Which may very well be a related problem. Andy From daemon Mon Oct 23 02:50:25 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9N2oPw23422 for vsta-xplod; Mon, 23 Oct 2000 02:50:25 GMT Received: from gate2.mn.man.de ([151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9N2oKZ23402 for ; Mon, 23 Oct 2000 02:50:20 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id NAA17669 for ; Mon, 23 Oct 2000 13:20:36 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Mon Oct 23 13:20:31 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id NAA02854 for ; Mon, 23 Oct 2000 13:20:30 +0200 (CEST) To: vsta@zendo.com Subject: Errors with 1.6.4 X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Mon, 23 Oct 2000 13:20:28 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 10/23/2000 01:20:31 PM, Serialize complete at 10/23/2000 01:20:31 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e9N2oLZ23403 Andy wrote: >>>Well, not dead, really. And 1.6.4 was put there in preparation for the >>>1.6.4 release, but what's sitting on the web site has a couple flaws, >>thus I hadn't switched anything over. >>Hmmm... So should I switch back? To what version? I had some Problems. For >>example, if I'm in /vsta and go one directory up, I crash. > >Nothing like that is known. I've done a lot of work on the FAT support of >late, so you probably have found a bug. Can you tell me exactly what you >did? And exactly how it crashed? Now I'm back from my holidays and will have some tests again. One thing first: Does this mean, that 1.6.4 should work, or is it a very experimental version? I can remember, that I always got a message "perm" after nearly every command. This could have something to do with the fat support, or maybe I did set up something wrong. What should I send you to come behind, what's wrong? I just set up all the stuff the way it is described. The only thing could be, how I configured the servers from grub - the rest is just the zip file. Or possibly I exceeded some limits? I have a 15 GB harddisk with the first partition beeing a fat16 one. -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Mon Oct 23 23:15:23 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9NNFNu24966 for vsta-xplod; Mon, 23 Oct 2000 23:15:23 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9NNFIZ24946 for ; Mon, 23 Oct 2000 23:15:18 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id JAA25724 for ; Tue, 24 Oct 2000 09:45:36 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Tue Oct 24 09:45:29 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id JAA17792 for ; Tue, 24 Oct 2000 09:45:29 +0200 (CEST) To: vsta@zendo.com Subject: VSTA Version to start with? X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Tue, 24 Oct 2000 09:45:28 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 10/24/2000 09:45:28 AM, Serialize complete at 10/24/2000 09:45:28 AM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e9NNFJZ24947 Hi! With which version of vsta should I start with? 1.6.2? -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Thu Oct 26 11:09:55 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9QB9t129648 for vsta-xplod; Thu, 26 Oct 2000 11:09:55 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id e9QB9oZ29637; Thu, 26 Oct 2000 11:09:50 GMT Message-Id: <200010261109.e9QB9oZ29637@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: Errors with 1.6.4 In-reply-to: Your message of "Mon, 23 Oct 2000 13:20:28 +0200." Date: Thu, 26 Oct 2000 11:09:50 +0000 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >Now I'm back from my holidays and will have some tests again. One thing >first: >Does this mean, that 1.6.4 should work, or is it a very experimental >version? It should work pretty well--it's all I use for my own day-to-day work. I have one edge case of cluster numbering in a node (in \windows\temp, bleh) which I have to hunt down. But in general it's working quite well. >I can remember, that I always got a message "perm" after nearly every >command. >This could have something to do with the fat support, or maybe I did set >up something wrong. What should I send you to come behind, what's wrong? I >just set up all the stuff the way it is described. The only thing could >be, how I configured the servers from grub - the rest is just the zip >file. Or possibly I exceeded some limits? I have a 15 GB harddisk with the >first partition beeing a fat16 one. That's your exit status. If the command worked OK, I can't imagine what would cause its exit status to look funny. Andy From daemon Thu Oct 26 22:27:24 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9QMROj00513 for vsta-xplod; Thu, 26 Oct 2000 22:27:24 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9QMR5Z00493 for ; Thu, 26 Oct 2000 22:27:18 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.1/8.11.1) with ESMTP id e9R6vkv15750 for ; Fri, 27 Oct 2000 08:57:46 +0200 Date: Fri, 27 Oct 2000 08:57:45 +0200 (CEST) From: Erik Dalen To: vsta@zendo.com Subject: Re: Errors with 1.6.4 In-Reply-To: <200010261109.e9QB9oZ29637@bodhi.zendo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If all the programs say perm it could be because you don't have a fpu... /Erik On Thu, 26 Oct 2000, Andy Valencia wrote: > [Martin_Doering@mn.man.de writes:] > > >Now I'm back from my holidays and will have some tests again. One thing > >first: > >Does this mean, that 1.6.4 should work, or is it a very experimental > >version? > > It should work pretty well--it's all I use for my own day-to-day work. > I have one edge case of cluster numbering in a node (in \windows\temp, > bleh) which I have to hunt down. But in general it's working quite > well. > > >I can remember, that I always got a message "perm" after nearly every > >command. > >This could have something to do with the fat support, or maybe I did set > >up something wrong. What should I send you to come behind, what's wrong? I > >just set up all the stuff the way it is described. The only thing could > >be, how I configured the servers from grub - the rest is just the zip > >file. Or possibly I exceeded some limits? I have a 15 GB harddisk with the > >first partition beeing a fat16 one. > > That's your exit status. If the command worked OK, I can't imagine what > would cause its exit status to look funny. > > Andy > From daemon Fri Oct 27 01:55:19 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9R1tJk00782 for vsta-xplod; Fri, 27 Oct 2000 01:55:19 GMT Received: from gate1.mn.man.de (gate1.mn.man.de [151.136.100.130]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9R1tEZ00762 for ; Fri, 27 Oct 2000 01:55:15 GMT Received: (from root@localhost) by gate1.mn.man.de (8.9.0/8.9.0) id MAA28547 for ; Fri, 27 Oct 2000 12:25:42 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate1.mn.man.de (1.0 SMTP-GW) with SMTP; Fri Oct 27 12:25:41 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id MAA05906 for ; Fri, 27 Oct 2000 12:25:41 +0200 (CEST) To: vsta@zendo.com Subject: Antwort: Re: Errors with 1.6.4 X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Fri, 27 Oct 2000 12:25:35 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 10/27/2000 12:25:41 PM, Serialize complete at 10/27/2000 12:25:41 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e9R1tGZ00763 >If all the programs say perm it could be because you don't have a fpu... With 1.6.4 every command made an error perm and with 1.6.3 everything is fine (what does not mean, that I do understand everything ;-) I have an Pentium MMX 166 and did use the same GRUB disk (and so the settings) for both versions. So just the untarred vsta base was different. Additionally I used mgr (or tried to....). There are no shared libs, that could have been overwritten by additional software, am I right? Next week I can do a test again. -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Fri Oct 27 01:59:17 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9R1xHt00807 for vsta-xplod; Fri, 27 Oct 2000 01:59:17 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9R1xEZ00787 for ; Fri, 27 Oct 2000 01:59:14 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id MAA17178 for ; Fri, 27 Oct 2000 12:29:38 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Fri Oct 27 12:29:35 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id MAA07325 for ; Fri, 27 Oct 2000 12:29:35 +0200 (CEST) To: vsta@zendo.com Subject: Framebuffer Interface X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Fri, 27 Oct 2000 12:29:29 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 10/27/2000 12:29:35 PM, Serialize complete at 10/27/2000 12:29:35 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e9R1xFZ00788 Hi! There is a framebuffer interface for embedded systems called MicroFramebuffer or uFB. It is used for RTEMS in conjuction with Microwindows GUI. Did someone ever implement such a thing (or started to do so)? Could somebody give me some help, if I would try? The uFB is split in a generic and a driver part (for different cards or platforms or such). I had a look at the source, and it could be not too complicated to be implemented for vsta. The Linux FB implementation is much more complicated and bigger, as I was told. -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Fri Oct 27 02:29:22 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9R2TMJ00956 for vsta-xplod; Fri, 27 Oct 2000 02:29:22 GMT Received: from gate2.mn.man.de (gate2.mn.man.de [151.136.100.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9R2TIZ00936 for ; Fri, 27 Oct 2000 02:29:18 GMT Received: (from root@localhost) by gate2.mn.man.de (8.9.0/8.9.0) id MAA22529 for ; Fri, 27 Oct 2000 12:59:46 +0200 (CEST) From: Martin_Doering@mn.man.de Received: from mmas.mn.man.de(151.136.42.131) by gate2.mn.man.de (1.0 SMTP-GW) with SMTP; Fri Oct 27 12:59:33 2000 Received: from mmdomi04.mn.man.de (mmdomi04.mn.man.de [151.136.132.235]) by mmas.mn.man.de (8.9.0/8.7.3/mvh-man01) with ESMTP id MAA18521 for ; Fri, 27 Oct 2000 12:59:33 +0200 (CEST) To: vsta@zendo.com Subject: Developement / Editor X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Fri, 27 Oct 2000 12:59:27 +0200 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 10/27/2000 12:59:32 PM, Serialize complete at 10/27/2000 12:59:32 PM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id e9R2TJZ00937 Hi! If you do some developement on vsta - what editors/ides do you use? I'm familar with vi, but for the developing process I prefer editors like fte or such, where you can jump to errorlines, have syntax highlighting etc. Do you have some tips for me? I cannot use fte, because I have no linux console (it uses slang lib instead of curses) -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Fri Oct 27 06:39:21 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9R6dL101214 for vsta-xplod; Fri, 27 Oct 2000 06:39:21 GMT Received: from cosmic.com ([216.41.40.61]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9R6dCZ01194 for ; Fri, 27 Oct 2000 06:39:12 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id LAA08240 for vsta@zendo.com; Fri, 27 Oct 2000 11:07:59 -0400 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: Developement / Editor Date: 27 Oct 2000 11:07:59 -0400 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 15 Message-ID: <8tc5of$81e$1@trantor.cosmic.com> References: X-Trace: trantor.cosmic.com 972659279 8239 10.10.10.1 (27 Oct 2000 15:07:59 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article , wrote: >Hi! > >If you do some developement on vsta - what editors/ides do you use? >I'm familar with vi, but for the developing process I prefer editors like >fte or such, where you can jump to errorlines, have syntax highlighting >etc. VSTa has vim, which is essentially vi on steroids. It supports syntax highlighting, "jump to errorlines", multiple windows, automatic code formatting, a powerful scripting language and pretty much anything else that a programmer could want. It's Good Stuff[tm]. --Mirian From daemon Fri Oct 27 10:29:56 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9RATu001495 for vsta-xplod; Fri, 27 Oct 2000 10:29:56 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e9RATqZ01475 for ; Fri, 27 Oct 2000 10:29:52 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.1/8.11.1) with ESMTP id e9RJ0hG31119 for ; Fri, 27 Oct 2000 21:00:43 +0200 Date: Fri, 27 Oct 2000 21:00:43 +0200 (CEST) From: Erik Dalen To: vsta@zendo.com Subject: Re: Developement / Editor In-Reply-To: <8tc5of$81e$1@trantor.cosmic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII actually elvis which is the most common vi clone supports syntax highlighting and multiple windows and such. :) elvis forever, vim sucks! ;P nah, ok it's ok :) /Erik On 27 Oct 2000, Mirian Crzig Lennox wrote: > In article , > wrote: > >Hi! > > > >If you do some developement on vsta - what editors/ides do you use? > >I'm familar with vi, but for the developing process I prefer editors like > >fte or such, where you can jump to errorlines, have syntax highlighting > >etc. > > VSTa has vim, which is essentially vi on steroids. It supports syntax > highlighting, "jump to errorlines", multiple windows, automatic code > formatting, a powerful scripting language and pretty much anything else > that a programmer could want. It's Good Stuff[tm]. > > --Mirian > From daemon Fri Oct 27 20:08:45 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id e9RK8jH02455 for vsta-xplod; Fri, 27 Oct 2000 20:08:45 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id e9RK8eZ02443; Fri, 27 Oct 2000 20:08:40 GMT Message-Id: <200010272008.e9RK8eZ02443@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: Framebuffer Interface In-reply-to: Your message of "Fri, 27 Oct 2000 12:29:29 +0200." Date: Fri, 27 Oct 2000 20:08:40 +0000 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >There is a framebuffer interface for embedded systems called >MicroFramebuffer or uFB. It is used for RTEMS in conjuction with >Microwindows GUI. Did someone ever implement such a thing (or started to >do so)? Could somebody give me some help, if I would try? I'll always answer questions, but I just looked it over, and it seems like the only "real" graphic card support is FreeBE, which is pretty DOS specific. Andy why not just use svgalib, which is already ported? Andy From daemon Thu Nov 9 15:28:32 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eA9FSWw28475 for vsta-xplod; Thu, 9 Nov 2000 15:28:32 GMT Received: from nickel.cix.co.uk (nickel.compulink.co.uk [194.153.0.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eA9FSP428455 for ; Thu, 9 Nov 2000 15:28:25 GMT Received: from RUDD.cix.co.uk (rudd.compulink.co.uk [194.153.16.14]) by nickel.cix.co.uk (8.9.3+Sun/8.9.1) with SMTP id XAA25940; Thu, 9 Nov 2000 23:28:36 GMT X-Envelope-From: jback@rudd.cix.co.uk From: Julian Back MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14859.12691.8000.277516@gargle.gargle.HOWL> Date: Thu, 9 Nov 2000 23:21:54 +0000 (GMT) To: vsta@zendo.com Subject: problems with 1.64 X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid I've had some problems with VSTa 1.64: 1. All binaries (vi, emacs, less) that use termcap.a don't work in the vsta.tz archive. I've recompiled some of these using termcap.a from 1.62 and they work OK. I haven't managed to successfully download the 1.64 sources so I don't know whats wrong with the termcap library. 2. I've installed VSTa 1.64 on an IBM Thinkpad 240 laptop, on a FAT16 LBA drive (first primary partition). Files in the vsta directory seem OK but if I do "ls /" I get an error: syslog: dos (pid 7) emergency: Assertion failed rw.c/165: pack_name null in extension 3. I can't get MGR to run. I know my video card is OK as the vgatest program in graphics.tz runs OK and can display 800x600x256. Buit when I try to run mgr the screen goes blank and the restores with a "perm" error. Any clues? Thanks Julian Back From daemon Thu Nov 9 19:55:29 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eA9JtT028764 for vsta-xplod; Thu, 9 Nov 2000 19:55:29 GMT Received: from ms1.mcps.k12.md.us (ms1.mcps.k12.md.us [205.222.0.40]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eA9JtN428744 for ; Thu, 9 Nov 2000 19:55:26 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by ms1.mcps.k12.md.us (8.9.3/8.9.3) with ESMTP id XAA26482 for ; Thu, 9 Nov 2000 23:06:31 -0500 Message-id: Date: Thu, 09 Nov 2000 22:53:59 -0500 Subject: Re: problems with 1.64 To: vsta@zendo.com From: "Eric Jacobs" References: <14859.12691.8000.277516@gargle.gargle.HOWL> In-Reply-To: <14859.12691.8000.277516@gargle.gargle.HOWL> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit jback@rudd.cix.co.uk writes: >1. All binaries (vi, emacs, less) that use termcap.a don't work in the >vsta.tz archive. I've recompiled some of these using termcap.a from >1.62 and they work OK. I haven't managed to successfully download the >1.64 sources so I don't know whats wrong with the termcap library. I had the same problem and I was wondering the same thing. > >2. I've installed VSTa 1.64 on an IBM Thinkpad 240 laptop, on a FAT16 >LBA drive (first primary partition). Files in the vsta directory seem >OK but if I do "ls /" I get an error: > >syslog: dos (pid 7) emergency: Assertion failed rw.c/165: pack_name null >in extension Hmm... extension anomaly in the root dir. My guess is that it's the volume label which just uses the extension field as part of the label, if I recall. If it's padded with zeroes, that would cause the error. From daemon Thu Nov 9 22:29:32 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eA9MTWg09817 for vsta-xplod; Thu, 9 Nov 2000 22:29:32 GMT Received: from gate2.fw.mn.man.de ([151.136.100.172]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eA9MTR409797 for ; Thu, 9 Nov 2000 22:29:29 GMT Received: by gate2.fw.mn.man.de (8.9.3/8.9.3) id HAA05580 for vsta@zendo.com; Fri, 10 Nov 2000 07:29:51 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate2.fw.mn.man.de (MSCAN) id 2/gate2.fw.mn.man.de/smtp-gw/mscan; Fri Nov 10 07:29:51 2000 Subject: Re: Re: problems with 1.64 To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Fri, 10 Nov 2000 07:29:40 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 11/10/2000 07:29:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id eA9MTU409798 Again: I also have problems with 1.6.4, I don't have with 1.6.3. It seems to be in the filesystem code. I can't remember more, but also I can't get mgr running. Ich have a S3Virge/DX chipset and tried to force the VESA driver. Normally the config file for mrg is in /etc/vga/libvga.con. Is this compiled differently under vsta? If yes, why? Possibly the config file is not read, because of this? -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Fri Nov 10 07:04:08 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAA748D10544 for vsta-xplod; Fri, 10 Nov 2000 07:04:08 GMT Received: from ms1.mcps.k12.md.us (ms1.mcps.k12.md.us [205.222.0.40]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAA741410524 for ; Fri, 10 Nov 2000 07:04:03 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by ms1.mcps.k12.md.us (8.9.3/8.9.3) with ESMTP id KAA11298 for ; Fri, 10 Nov 2000 10:14:57 -0500 Message-id: Date: Fri, 10 Nov 2000 10:01:39 -0500 Subject: Re(2): Re: problems with 1.64 To: vsta@zendo.com From: "Eric Jacobs" References: In-Reply-To: MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Martin_Doering@mn.man.de writes: > >Normally the config file for mrg is in /etc/vga/libvga.con. Is this >compiled differently under vsta? If yes, why? Possibly the config file is >not read, because of this? The config file should be in /vsta/etc/libvga.config which used to show up as libvga.con with the old dos server. Now, with VFAT, it is necessary to name the file libvga.config because all characters are significant. From daemon Fri Nov 10 16:27:47 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAAGRlC11165 for vsta-xplod; Fri, 10 Nov 2000 16:27:47 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAAGRg411158; Fri, 10 Nov 2000 16:27:42 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id QAA00445; Fri, 10 Nov 2000 16:24:15 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011110024.QAA00445@vandys-pc.zendo.com> To: "Eric Jacobs" cc: vsta@zendo.com Subject: Re: problems with 1.64 In-reply-to: Your message of "Thu, 09 Nov 2000 22:53:59 EST." Date: Fri, 10 Nov 2000 16:24:15 -0800 From: Andy Valencia ["Eric Jacobs" writes:] >>1. All binaries (vi, emacs, less) that use termcap.a don't work in the >>vsta.tz archive. I've recompiled some of these using termcap.a from >>1.62 and they work OK. I haven't managed to successfully download the >>1.64 sources so I don't know whats wrong with the termcap library. >I had the same problem and I was wondering the same thing. termcap became a DLL in 1.6.4, so no doubt this is at the heart of things. That said, I haven't been able to reproduce this problem here on either of my test machines. If somebody could use gdb to plod through the execution and and tell me what I got wrong, I'd be happy to fix it. Or, if things were working well enough otherwise, put a VSTa machine on the net and let me telnet into it to debug the problem remotely. >>2. I've installed VSTa 1.64 on an IBM Thinkpad 240 laptop, on a FAT16 >>LBA drive (first primary partition). Files in the vsta directory seem >>OK but if I do "ls /" I get an error: >>syslog: dos (pid 7) emergency: Assertion failed rw.c/165: pack_name null >>in extension >Hmm... extension anomaly in the root dir. My guess is that >it's the volume label which just uses the extension field as >part of the label, if I recall. If it's padded with zeroes, that >would cause the error. Just another thought: I've found a /windows/temp subdir which causes me trouble... it's located way up high in a 4gig filesystem. Run another copy of "dos" under gdb on that filesystem (use -r to make sure you don't scribble on it) and break in dos_readdir(). Then step along until things go bad, and see if you can figure out where it got its data. Andy From daemon Fri Nov 10 16:30:40 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAAGUe611181 for vsta-xplod; Fri, 10 Nov 2000 16:30:40 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAAGUZ411174; Fri, 10 Nov 2000 16:30:36 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id QAA00478; Fri, 10 Nov 2000 16:27:08 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011110027.QAA00478@vandys-pc.zendo.com> To: Julian Back cc: vsta@zendo.com Subject: Re: problems with 1.64 In-reply-to: Your message of "Thu, 09 Nov 2000 23:21:54 GMT." <14859.12691.8000.277516@gargle.gargle.HOWL> Date: Fri, 10 Nov 2000 16:27:08 -0800 From: Andy Valencia [Julian Back writes:] >3. I can't get MGR to run. I know my video card is OK as the vgatest >program in graphics.tz runs OK and can display 800x600x256. Buit when >I try to run mgr the screen goes blank and the restores with a "perm" >error. Sounds like it caught a segv and cleaned itself up. I bet it's not your video card itself, but something else/tricky. If you have a second PC with a terminal program, turn on a shell for the serial port (ugh, actually, I think I recollect that IBM's have non-standard serial HW?) and run MGR from under gdb. Since it's handling its own signals, you'll need to step forward from main() until you see it barf. May have to re-run it several times to narrow down which part croaks. Hmmm... can anybody tell that I've become accustomed to using gdb? :-> Hard to believe I didn't have a port for the first several years of VSTa's life! Andy From daemon Mon Nov 13 00:42:58 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAD0gw216933 for vsta-xplod; Mon, 13 Nov 2000 00:42:58 GMT Received: from gate1.fw.mn.man.de (gate1.fw.mn.man.de [151.136.100.171]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAD0gpU16913 for ; Mon, 13 Nov 2000 00:42:52 GMT Received: by gate1.fw.mn.man.de (8.9.3/8.9.3) id JAA08503 for vsta@zendo.com; Mon, 13 Nov 2000 09:43:14 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate1.fw.mn.man.de (MSCAN) id 2/gate1.fw.mn.man.de/smtp-gw/mscan; Mon Nov 13 09:43:14 2000 Subject: svgalib configuration To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Mon, 13 Nov 2000 09:43:00 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 11/13/2000 09:43:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bodhi.zendo.com id eAD0gsU16914 About the mgr/svgalib configuration: >The config file should be in /vsta/etc/libvga.config >which used to show up as libvga.con with the old dos >server. Now, with VFAT, it is necessary to name the >file libvga.config because all characters are significant. Ohhh! I used the internal extractor of Servant Salamander (a file manager) which uses definatly long filenames! So is it wrong packed in the archive? So - then for shure my configuration can not work :-) -------------------------------------------------------------------------------------------------------- Martin Döring, Systemtechnik (IDT) MAN Nutzfahrzeuge AG Dachauerstraße 667 D-80995 München Tel.: +49(0)89 / 1580 - 1199 Fax: +49(0)89 / 1580 - 91-1199 E-Mail: Martin_Doering@mn.man.de From daemon Mon Nov 13 07:26:43 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAD7Qhh17480 for vsta-xplod; Mon, 13 Nov 2000 07:26:43 GMT Received: from ms1.mcps.k12.md.us (ms1.mcps.k12.md.us [205.222.0.40]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAD7QcU17460 for ; Mon, 13 Nov 2000 07:26:38 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by ms1.mcps.k12.md.us (8.9.3/8.9.3) with ESMTP id KAA06337 for ; Mon, 13 Nov 2000 10:37:11 -0500 Message-id: Date: Mon, 13 Nov 2000 10:19:51 -0500 Subject: Re(2): problems with 1.64 To: vsta@zendo.com From: "Eric Jacobs" References: <200011110024.QAA00445@vandys-pc.zendo.com> In-Reply-To: <200011110024.QAA00445@vandys-pc.zendo.com> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit vandys@zendo.com writes: >>>1. All binaries (vi, emacs, less) that use termcap.a don't work in the >>>vsta.tz archive. I've recompiled some of these using termcap.a from >>>1.62 and they work OK. I haven't managed to successfully download the >>>1.64 sources so I don't know whats wrong with the termcap library. >>I had the same problem and I was wondering the same thing. > >termcap became a DLL in 1.6.4, so no doubt this is at the heart of things. Ah hah! The clue! Well, then the problem is that there is no termcap.shl file in the binary distribution... you have to get the copy from the source tarball and copy it into /vsta/lib. From daemon Mon Nov 13 15:40:34 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eADFeYj18255 for vsta-xplod; Mon, 13 Nov 2000 15:40:34 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id eADFeUU18245; Mon, 13 Nov 2000 15:40:30 GMT Message-Id: <200011131540.eADFeUU18245@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: "Eric Jacobs" cc: vsta@zendo.com Subject: Re: Re(2): problems with 1.64 In-reply-to: Your message of "Mon, 13 Nov 2000 10:19:51 EST." Date: Mon, 13 Nov 2000 15:40:29 +0000 From: Andy Valencia ["Eric Jacobs" writes:] >Ah hah! The clue! Well, then the problem is that there is no termcap.shl >file in the binary distribution... you have to get the copy from the >source tarball and copy it into /vsta/lib. Doh! As well as libregex.shl and libm.shl. I've updated /vsta/mkdist.mk, and will push out something with these fixes once I get back off the road. Sorry, Andy From daemon Tue Nov 21 13:36:51 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eALDap503958 for vsta-xplod; Tue, 21 Nov 2000 13:36:51 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id eALDamU03949 for ; Tue, 21 Nov 2000 13:36:48 GMT Message-Id: <200011211336.eALDamU03949@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: vsta@zendo.com Subject: VSTa 1.6.5 available Date: Tue, 21 Nov 2000 13:36:47 +0000 From: Andy Valencia I've put 1.6.5 up on the FTP server (ftp://ftp.vsta.org/vsta/vsta_165) for your downloading enjoyment. In addition to the changes for 1.6.4: Added -o to MGR's "startup" command. Lets output be written to the named file. Added VFAT (long filename) support to DOS filesystem. Ported Plan 9's nroff/troff. Generalized system shared library support; converted libm, libregex, and libtermcap. Allow dumping of ranges of sectors in dumpsect. Accomodate various flavors of RCS directory names for rcsdo. Save quite a few cycles in its operation. Port of PDP-11 emulator; runs V7 UNIX under VSTa! Avoid gcc lame inline support; -O isn't needed any more to correctly get an inline compilation of getc/putc. Auto-flush stdout when read from an interactive stdin happens. Conversion of man pages to nroff -man format. Ported BSD's "units" command. vstafs, file/dir creation inherits protection of parent dir. less's help ('H' command) fixed. 1.6.5 includes: Added a little flexibility in use of MAP_FIXED. Port of GNU Smalltalk. Added realpath(), gettimeofday(). Added prototype for rename() to . Added rmap_grab() to the library routines. Fixed long-standing edge case bug when resource map is too fragmented. Added alias remove() mapping to unlink(). Added two new partition types to disk partition support. Added "xkeys" stat -w message to console server, so you can disable F and arrow key escape sequence generation (if you want). Default is they still generate their escape sequences. (But I hate'em, so my personal config has them shut off!) Fix memory leak in selfs server. Fix "make distribution" to include new DLL's in distribution. This manifested itself as any of your -ltermcap type programs dying when you tried to run them. Sorry! Implement inbuf/outbuf counts for console. fionread() now works there. Always let owner (UID) to chown operations on vstafs. Otherwise you can paint yourself into a corner, where you remove all abilities of all users to touch the file! Fix some more long-filename compilation errors. Have DLL loader ld.shl try the truncated 8.3 filename in addition to the full DLL name. This helps when the VSTa distribution was loaded via a utility which only supports 8.3 filenames. As always, send a note to vsta@zendo.com if/when you run into problems. Note that if you've been accessing your partition as wd0_p0, the two new supported partition types I mention for 1.6.5 may make your partition now appear as wd0_dos0. Andy Valencia From daemon Thu Nov 23 00:28:33 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAN0SXB06430 for vsta-xplod; Thu, 23 Nov 2000 00:28:33 GMT Received: from gate2.fw.mn.man.de (gate2.fw.mn.man.de [151.136.100.172]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAN0SSU06410 for ; Thu, 23 Nov 2000 00:28:28 GMT Received: (from root@localhost) by gate2.fw.mn.man.de (8.9.3/8.9.3) id JAA23350 for vsta@zendo.com; Thu, 23 Nov 2000 09:29:29 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate2.fw.mn.man.de (MSCAN) id 2/gate2.fw.mn.man.de/smtp-gw/mscan; Thu Nov 23 09:29:29 2000 Subject: VSTa 1.6.5 To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Thu, 23 Nov 2000 09:29:20 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 11/23/2000 09:29:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi! VSTa works - partitially for me. Again I have the following problem: If I go out (with "cd ..") of the /vsta directory, immediately I stop in the kernel debugger - in all cases. Is there any thing I can do, to get rid of this problem? For example make a vfs filesystem? I really would like to use a stable vsta. MGR is not running. The VESA support is not compiled in, and the "chipset=VGA" just gives a black screen. One interesting thing: If I choose a chipset, which does not correspondent with my card, I get a "perm" message on the console. I have a S3 Virge 3/dx card. It is scanned as S3, but the chipset works differently - I know this problem from different older XFree86 configuration attempts. This card is a bit problematic... So, If my card is not supported by svgalib, I have no chance to get some graphics running under VSTa today, right? How can I see, if my mouse works correctly? In Unix, there are devices, but in VSTa? Is there a possiblility (argument) to make the ls -l command show just one line per file? Is there a possibility to use keymaps on the console? And at all - my arrow keys do not work in vi. Is there something I have to configure? Sorry, for so many questions. The thing is, that I read all the architecture stuff and the other documentatiuon, but do not get it running successfully. But - yes - I would like to... :-( From daemon Thu Nov 23 06:47:10 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAN6lAK06945 for vsta-xplod; Thu, 23 Nov 2000 06:47:10 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAN6l4U06938; Thu, 23 Nov 2000 06:47:05 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id GAA14104; Thu, 23 Nov 2000 06:48:04 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011231448.GAA14104@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Thu, 23 Nov 2000 09:29:20 +0100." Date: Thu, 23 Nov 2000 06:48:04 -0800 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >VSTa works - partitially for me. Again I have the following problem: >If I go out (with "cd ..") of the /vsta directory, immediately I stop in >the kernel debugger - in all cases. Is there any thing I can do, to get rid >of this problem? For example make a vfs filesystem? I really would like to >use a stable vsta. What kind of message do you get (if any)? What's the running process? What values does "tf" report? That'd give me some idea of why it's croaking. Barring any bug, the DOS filesystem should handle your filesystem OK. Obviously, you've found a bug. Is your filesystem near 4 gigabytes in size? I just fixed a lingering bug in > 4G support (Microsoft filesystems tend to have less than 4G size, but that size doesn't include FAT tables and such, so you still need to support > 4G in your disk I/O... the next version of VSTa will support ~1 terabyte disks, taking care of the problem for the time being). >MGR is not running. The VESA support is not compiled in, and the >"chipset=VGA" just gives a black screen. One interesting thing: If I choose >a chipset, which does not correspondent with my card, I get a "perm" >message on the console. I have a S3 Virge 3/dx card. It is scanned as S3, >but the chipset works differently - I know this problem from different >older XFree86 configuration attempts. This card is a bit problematic... So, >If my card is not supported by svgalib, I have no chance to get some >graphics running under VSTa today, right? You could always link in the old VGA support (the libbitblit.a from vsta/mgr/src/libbitblit/linux instead of .../colorport. But there should also be a way to use the basic VGA modes from svgalib (unless svgalib had a bug, or I created one while porting it). >How can I see, if my mouse works correctly? In Unix, there are devices, but >in VSTa? In vsta/src/srv/mach/mouse there's a program "test.c". In that dir there's even a rule in the makefile to make "test". Then run it ./test and it'll track mouse events and show them to you. Assuming your mouse server got started OK. Note that for RS-232 mice, you have to have the RS-232 server running also ("/vsta/boot/rs232 com1 &", something like that). >Is there a possiblility (argument) to make the ls -l command show just one >line per file? Or just use "vls", which is Dave Hudson's port of GNU ls... it's rather nice, and much more like a "typical" ls. >Is there a possibility to use keymaps on the console? And at all - my arrow >keys do not work in vi. Is there something I have to configure? By default the console generates escape sequences... perhaps the termcap entry active in vim doesn't know about them? I never use such keys (I'm a touch typist, and you'd have to move your fingers off the home row) so haven't paid much attention! >Sorry, for so many questions. The thing is, that I read all the >architecture stuff and the other documentatiuon, but do not get it running >successfully. But - yes - I would like to... :-( Well, in theory there's no difference between theory and practice, but in practice there is. So yes, it's quite reasonable to want to get it running. Hope this helps. Regards, Andy Valencia From daemon Thu Nov 23 23:58:08 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eANNw8L08025 for vsta-xplod; Thu, 23 Nov 2000 23:58:08 GMT Received: from gate1.fw.mn.man.de (gate1.fw.mn.man.de [151.136.100.171]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eANNw0U08005 for ; Thu, 23 Nov 2000 23:58:00 GMT Received: by gate1.fw.mn.man.de (8.9.3/8.9.3) id IAA24771 for vsta@zendo.com; Fri, 24 Nov 2000 08:59:00 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate1.fw.mn.man.de (MSCAN) id 2/gate1.fw.mn.man.de/smtp-gw/mscan; Fri Nov 24 08:59:00 2000 Subject: My FS Problem To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Fri, 24 Nov 2000 08:58:51 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 11/24/2000 08:58:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi, Andy! Here is the error message from my filesystem problem. It says: syslog: dos (pid 7) emergency: Assertation failed rw.c/165: pack_name: null in extension In the kernel debugger I typed "tf" and got about 8-9 lines of which call did follow on which. I was to lazy to write this down. Is there a method to bring this on a disk or so? Possibly I could make a shot with my digital camera ;-) My first filesystem is about 2 Gb. I have a 15 Gb Disk, but for VSTa I just use the first partition. I think, it's fat16 (am not shure, but can check this later)??? A hint: I think, I did not get this problem in VSTa 1.6.3. If you want, I could make some tests (if you tell me which) or you could send me a changed server and I will test it, but I do not understand enough, to change it by myself. I also have no developement environment under VSTa set up (because it is not stable for me yet) Hope, I can help you to get rid of this bug and that I get it running. From daemon Fri Nov 24 08:41:57 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAO8fvk08681 for vsta-xplod; Fri, 24 Nov 2000 08:41:57 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAO8fpU08674; Fri, 24 Nov 2000 08:41:51 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA15659; Fri, 24 Nov 2000 08:42:57 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011241642.IAA15659@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: My FS Problem In-reply-to: Your message of "Fri, 24 Nov 2000 08:58:51 +0100." Date: Fri, 24 Nov 2000 08:42:57 -0800 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >Here is the error message from my filesystem problem. It says: >syslog: dos (pid 7) emergency: Assertation failed rw.c/165: >pack_name: null in extension Yes, so you have a filename in your root directory which is not a VFAT entry, and yet has non-ASCII characters in it. That shouldn't be legal, but if things otherwise look sane, you can just disable the ASSERT_DEBUG in pack_name in the DOS server, and it'll ignore the problem. >If you want, I could make some tests (if you tell me which) or you could >send me a changed server and I will test it, but I do not understand >enough, to change it by myself. I also have no developement environment >under VSTa set up (because it is not stable for me yet) Well, the reason that assert blows the DOS server away is that my philosophy (especially with filesystems) has been to do no harm. And when the DOS server sees an inexplicable directory entry, it can't be sure that any of its other actions are OK, either. I'm assuming you've scandisk'ed this filesystem from DOS/Windoze and it's clean? I can build a version without this assertion, but you should definitely run the filesystem with -r (read-only) until it seems like it's OK in general. And even then, of course, have backups! Andy From daemon Fri Nov 24 14:36:31 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAOEaVw09131 for vsta-xplod; Fri, 24 Nov 2000 14:36:31 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAOEaQU09111 for ; Fri, 24 Nov 2000 14:36:27 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.1/8.11.1) with ESMTP id eAOMcZd31760 for ; Fri, 24 Nov 2000 23:38:35 +0100 Date: Fri, 24 Nov 2000 23:38:35 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: Re: My FS Problem In-Reply-To: <200011241642.IAA15659@vandys-pc.zendo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have gotten exactly the same problem twice and it was on freshly formatted FAT disks. I had unly untared the vsta stuff onto them. maybe a fsck.fat (ala unix) would be good to fix this kind of stuff? /Erik On Fri, 24 Nov 2000, Andy Valencia wrote: > [Martin_Doering@mn.man.de writes:] > > >Here is the error message from my filesystem problem. It says: > >syslog: dos (pid 7) emergency: Assertation failed rw.c/165: > >pack_name: null in extension > > Yes, so you have a filename in your root directory which is not a VFAT > entry, and yet has non-ASCII characters in it. That shouldn't be legal, but > if things otherwise look sane, you can just disable the ASSERT_DEBUG in > pack_name in the DOS server, and it'll ignore the problem. > > >If you want, I could make some tests (if you tell me which) or you could > >send me a changed server and I will test it, but I do not understand > >enough, to change it by myself. I also have no developement environment > >under VSTa set up (because it is not stable for me yet) > > Well, the reason that assert blows the DOS server away is that my > philosophy (especially with filesystems) has been to do no harm. And when > the DOS server sees an inexplicable directory entry, it can't be sure that > any of its other actions are OK, either. I'm assuming you've scandisk'ed > this filesystem from DOS/Windoze and it's clean? > > I can build a version without this assertion, but you should definitely run > the filesystem with -r (read-only) until it seems like it's OK in general. > And even then, of course, have backups! > > Andy > From daemon Fri Nov 24 15:13:18 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAOFDID09178 for vsta-xplod; Fri, 24 Nov 2000 15:13:18 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAOFDEU09171; Fri, 24 Nov 2000 15:13:14 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id PAA16312; Fri, 24 Nov 2000 15:14:17 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011242314.PAA16312@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: My FS Problem In-reply-to: Your message of "Fri, 24 Nov 2000 23:38:35 +0100." Date: Fri, 24 Nov 2000 15:14:17 -0800 From: Andy Valencia [Erik Dalen writes:] >I have gotten exactly the same problem twice and it was on freshly >formatted FAT disks. I had unly untared the vsta stuff onto them. maybe a >fsck.fat (ala unix) would be good to fix this kind of stuff? First, if there's some legal directory entry format which has embedded nulls in a 8.3 directory entry, then all I need is a pointer to some doc which describes it. I haven't heard of it, and haven't run into it myself, but it could certainly be out there somewhere. If it's actually filesystem damage, I've always wimped out and used the Microdreck utility. Is there a FAT fsck available anywhere? Or could I get somebody (else) to write one? :-> The problem is that I just don't need it very often, thus it hasn't been written. If somebody can get it to reproduce on a small-ish disk, and they had the ability to "dd" the contents off, I'd be up for getting an entire disk image so I could debug it here (gzip it for me, of course). But please, no 2 gigabyte images! After having finished > 4G disk support, I'm back to working on the timeout support for select(). Thanks, Andy Valencia From daemon Fri Nov 24 21:02:16 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAOL2GR09798 for vsta-xplod; Fri, 24 Nov 2000 21:02:16 GMT Received: from hotmail.com (f178.law3.hotmail.com [209.185.241.178]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAOL2AU09778 for ; Fri, 24 Nov 2000 21:02:11 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 Nov 2000 21:03:19 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 25 Nov 2000 05:03:18 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Interesting behaviour Date: Sat, 25 Nov 2000 00:03:18 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Nov 2000 05:03:19.0096 (UTC) FILETIME=[06D6AB80:01C0569D] I'm experiencing some strange behaviour with VSTa running in Bochs. I made the necessary changes to allow it to boot, but now I can consistently crash the system just by typing 'cd /'. It throws me into the debugger with the following error message: 'syslog: dos (pid 7) emergency: Assertion failed rw.c/165: pack_name: null in extension Boot process 7 dies' If you really need it, I can type out what a 'trace' in the debugger produces, but I think it should be easily reproducible on another system. Previously, it also gave me errors when trying to use any absolute path name, but I haven't been able to reproduce it. I'm using the VSTa 1.6.5 release. Any help is much appreciated! Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sat Nov 25 03:43:19 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAP3hJc12580 for vsta-xplod; Sat, 25 Nov 2000 03:43:19 GMT Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAP3hCU12556; Sat, 25 Nov 2000 03:43:13 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 13zdkn-000F6k-0V; Sat, 25 Nov 2000 11:44:25 +0000 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id LAA00739; Sat, 25 Nov 2000 11:40:55 GMT Sender: dave@humbug.demon.co.uk Message-ID: <3A1FA527.CF9490CB@humbug.demon.co.uk> Date: Sat, 25 Nov 2000 11:40:23 +0000 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andy Valencia , "vsta@zendo.com" Subject: Re: My FS Problem References: <200011242314.PAA16312@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, Andy Valencia wrote: > > If it's actually filesystem damage, I've always wimped out and used the > Microdreck utility. Is there a FAT fsck available anywhere? Or could I get > somebody (else) to write one? :-> The problem is that I just don't need it > very often, thus it hasn't been written. Werner Almesberger (sp?) wrote one for Linux many years ago - I don't know the current state of play with it. It should show up as something like fsck.dos or dosfsck. I know that he hasn't been maintaining it recently though (rather like I've not done any of the work on mkdosfs recently), but if any of the Linux distis have done as much to his code as they did with mine then it should be a pretty good starting point. Regards, Dave From daemon Sat Nov 25 13:28:44 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAPDSiI13148 for vsta-xplod; Sat, 25 Nov 2000 13:28:44 GMT Received: from hotmail.com (f56.law3.hotmail.com [209.185.241.56]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAPDSdU13128 for ; Sat, 25 Nov 2000 13:28:39 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 25 Nov 2000 13:29:49 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 25 Nov 2000 21:29:49 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Sat, 25 Nov 2000 16:29:49 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Nov 2000 21:29:49.0534 (UTC) FILETIME=[D716BFE0:01C05726] Sorry for sending almost the exact same bug that had just reported by someone else. I didn't know about it. :-) >What kind of message do you get (if any)? What's the running process? >What >values does "tf" report? That'd give me some idea of why it's >croaking. As I reported in my earlier message, when it drops into the debugger, the following error is reported: syslog: dos (pid 7) emergency: Assertion failed rw.c/165: pack_name: null in extension Boot process 7 dies I then type 'tf' in the debugger and get the following: Trap type 255 err 0x0 eip 0x33:0x77bc eax 0x0 ebx 0xa5 ecx 0x6 edx 0x400002c00 esi 0x43cc edi 0x67a9 esp 0x2b:0x7ffffdb8 ebp 0x7ffffddc ef lags 0x206 I'm running VSTa in Bochs. I don't know if that changes anything, but since I'm getting the same error as the other fellow, it must be a common problem. Hope that helps! Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sun Nov 26 08:05:02 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQ852k14274 for vsta-xplod; Sun, 26 Nov 2000 08:05:02 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQ84vU14264; Sun, 26 Nov 2000 08:04:58 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA21756; Sun, 26 Nov 2000 08:06:10 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011261606.IAA21756@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Sat, 25 Nov 2000 16:29:49 EST." Date: Sun, 26 Nov 2000 08:06:10 -0800 From: Andy Valencia ["Sandro Magi" writes:] >I'm running VSTa in Bochs. I don't know if that changes anything, but since >I'm getting the same error as the other fellow, it must be a common problem. >Hope that helps! How big is your virtual disk? If you can reproduce this on something small enough for me to FTP down here, I can (finally!) take a look directly at this problem. Andy From daemon Sun Nov 26 08:33:30 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQ8XU414339 for vsta-xplod; Sun, 26 Nov 2000 08:33:30 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQ8XMU14330; Sun, 26 Nov 2000 08:33:22 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA21988; Sun, 26 Nov 2000 08:34:34 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011261634.IAA21988@vandys-pc.zendo.com> To: Dave Hudson cc: "vsta@zendo.com" Subject: Re: My FS Problem In-reply-to: Your message of "Sat, 25 Nov 2000 11:40:23 GMT." <3A1FA527.CF9490CB@humbug.demon.co.uk> Date: Sun, 26 Nov 2000 08:34:34 -0800 From: Andy Valencia [Dave Hudson writes:] >Werner Almesberger (sp?) wrote one for Linux many years ago - I don't >know the current state of play with it. It should show up as something >like fsck.dos or dosfsck. I know that he hasn't been maintaining it >recently though (rather like I've not done any of the work on mkdosfs >recently), but if any of the Linux distis have done as much to his code >as they did with mine then it should be a pretty good starting point. Found it, and it does indeed look pretty good (even a mkfs one, too). These'll make a nice addition, and are another step on the way to true independence from Micro-you-know-who. I'll put'em on my list, although anybody else is welcome to have a go at it first. Andy From daemon Sun Nov 26 10:39:51 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQAdp814534 for vsta-xplod; Sun, 26 Nov 2000 10:39:51 GMT Received: from hotmail.com ([209.185.241.169]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQAdlU14514 for ; Sun, 26 Nov 2000 10:39:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 10:41:00 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 26 Nov 2000 18:41:00 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Sun, 26 Nov 2000 13:41:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Nov 2000 18:41:00.0961 (UTC) FILETIME=[6C66E910:01C057D8] >How big is your virtual disk? If you can reproduce this on something small >enough for me to FTP down here, I can (finally!) take a look directly at >this problem. > >Andy Right now my main virtual disk is 483MB. I just created a 10MB disk image and tried it out; same problem. I put a compressed copy of the 10MB image on my server at: http://naasking.homeip.net/vsta/10M.gz It weighs in around 3MB. If you can't get through to the server right away, try again in a few minutes. The server is on DSL line and it has to reconnect to renew the ip every once and awhile. To be honest, I'm having trouble with the disk overall. Sometimes when I try 'tar zxvpf'ing things it fails with 'Broken Pipe' errors, when I try compiling/'make'ing it often fails with some strange error as well. Perhaps the method I used for setting up the disk/partition/filesystem is what's causing the problem. If you need a larger disk image to do anything useful, just let me know and I'll put up another one. Let me know how it turns out. :-) Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sun Nov 26 12:48:17 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQCmHM14767 for vsta-xplod; Sun, 26 Nov 2000 12:48:17 GMT Received: from hotmail.com (f10.law3.hotmail.com [209.185.241.10]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQCmEU14747 for ; Sun, 26 Nov 2000 12:48:14 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 12:49:28 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 26 Nov 2000 20:49:27 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Sun, 26 Nov 2000 15:49:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Nov 2000 20:49:28.0080 (UTC) FILETIME=[5E33F100:01C057EA] > >... I just created a 10MB disk image > >and tried it out; same problem. I put a compressed copy of the 10MB image >on > >my server at: > >http://naasking.homeip.net/vsta/10M.gz > >Thanks, got it. What geometry (cyl, heads, spt) did you use? > >Andy I used the numbers straight out of the Bochs documentation: cyl = 306, heads = 4, spt = 17 (for the 10MB image) _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sun Nov 26 13:05:33 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQD5X514829 for vsta-xplod; Sun, 26 Nov 2000 13:05:33 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQD5SU14822; Sun, 26 Nov 2000 13:05:28 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA22599; Sun, 26 Nov 2000 13:06:41 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011262106.NAA22599@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Sun, 26 Nov 2000 15:49:27 EST." Date: Sun, 26 Nov 2000 13:06:41 -0800 From: Andy Valencia Well, whatever. I booted from floppy and the rest of the disk image looks fine (including the failure). Now that I know it's sane, I'll load it as a file under VSTa and run a local DOS server. Thanks for your help! Andy From daemon Sun Nov 26 13:01:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQD1kH14812 for vsta-xplod; Sun, 26 Nov 2000 13:01:46 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQD1iU14805; Sun, 26 Nov 2000 13:01:44 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA22577; Sun, 26 Nov 2000 13:02:57 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011262102.NAA22577@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Sun, 26 Nov 2000 15:49:27 EST." Date: Sun, 26 Nov 2000 13:02:56 -0800 From: Andy Valencia ["Sandro Magi" writes:] >>Thanks, got it. What geometry (cyl, heads, spt) did you use? >I used the numbers straight out of the Bochs documentation: >cyl = 306, heads = 4, spt = 17 (for the 10MB image) Ok. Now... was this hard disk image bootable for you? Or did you use a floppy? Andy From daemon Sun Nov 26 13:11:10 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQDBAZ14875 for vsta-xplod; Sun, 26 Nov 2000 13:11:10 GMT Received: from hotmail.com (f263.law3.hotmail.com [209.185.240.40]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQDB7U14855 for ; Sun, 26 Nov 2000 13:11:07 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 13:12:20 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 26 Nov 2000 21:12:20 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Sun, 26 Nov 2000 16:12:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Nov 2000 21:12:20.0988 (UTC) FILETIME=[908513C0:01C057ED] > >>Thanks, got it. What geometry (cyl, heads, spt) did you use? > >I used the numbers straight out of the Bochs documentation: > >cyl = 306, heads = 4, spt = 17 (for the 10MB image) > >Ok. Now... was this hard disk image bootable for you? Or did you use a >floppy? > >Andy Oops! Sorry about that. I used the floppy image from the VSTa site which had the pre-loaded parameters for booting. http://www.vsta.org/Software/bochs/vsta.flp.gz Then I just typed, "./bochs boot:a &" , and selected "VSTa boot". The floppy boot is set for partition 3, but that partition doesn't exist. I just reset the root to hd(0,0), and booted. Sorry, I should have thought about the booting issue. Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sun Nov 26 14:47:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQElkj15018 for vsta-xplod; Sun, 26 Nov 2000 14:47:46 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQEleU15011; Sun, 26 Nov 2000 14:47:40 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA22857; Sun, 26 Nov 2000 14:48:53 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011262248.OAA22857@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Sun, 26 Nov 2000 13:41:00 EST." Date: Sun, 26 Nov 2000 14:48:53 -0800 From: Andy Valencia ["Sandro Magi" writes:] >http://naasking.homeip.net/vsta/10M.gz Many thanks. Attached below is the patch to fix this... it's a problem between the long filename support and a FAT-1[26] filesystem. I've also put a bugfixed DOS server on: ftp://ftp.vsta.org/vsta/pickup/dos.nullfix replace /vsta/boot/dos with that, and you should be in good shape! Nobody working on a FAT-32 filesystem should see this problem... but obviously there are plenty of older versions still around. Andy Valencia =================================================================== RCS file: RCS/stat.c retrieving revision 1.24 diff -C4 -r1.24 stat.c *** 1.24 2000/06/21 20:49:38 --- stat.c 2000/11/26 14:38:48 *************** *** 145,153 **** shortname(struct directory *d) { static char buf[14]; ! pack_name(d, buf); return(buf); } /* --- 145,160 ---- shortname(struct directory *d) { static char buf[14]; ! /* ! * NULL'ed out entry means root directory ! */ ! if (d->name[0] == '\0') { ! strcpy(buf, "/"); ! } else { ! pack_name(d, buf); ! } return(buf); } /* From daemon Sun Nov 26 18:10:47 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQIAlg15268 for vsta-xplod; Sun, 26 Nov 2000 18:10:47 GMT Received: from hotmail.com (f180.law3.hotmail.com [209.185.241.180]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQIAhU15248 for ; Sun, 26 Nov 2000 18:10:44 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 26 Nov 2000 18:11:57 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 27 Nov 2000 02:11:57 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Sun, 26 Nov 2000 21:11:57 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Nov 2000 02:11:57.0479 (UTC) FILETIME=[6B57EB70:01C05817] > >Thanks, that seemed to do work. I get another strange error the first >time I > >log in and try to "cd /". It's says: > >syslog: dos (pid 7) warning: year 1980 is less than 190! > >But nothing bad seems to happen. The system is still up and running and I > >can go about my business and it doesn't warn me again, just the first >time. > >Nah, that's OK. It's just a date/time stamp which is before the epoc in >VSTa's time encoding. I see. Ok then. :-) > >This seems like a good opportunity to gain some insight into the design >of > >VSTa, so I was wondering, isn't VSTa based on a microkernel? I see that >the > >filesystem runs as a user process, but isn't the kernel protected from >user > >space servers? If so, why was the dos server able to crash the kernel >like > >that? Does the system drop into the debugger as soon as an error occurs >in a > >critical process? Just curious. > >You're on the right track... when the kernel is compiled with DEBUG, when >a >boot server dies it pauses in the kernel debugger. If you had done "q", >the >kernel debugger would have returned, and the system would still have been >"up". Aaaaaahhhhhh... So the system hadn't really crashed, although it was left in a somewhat unusable state. >Of course, without its root filesystem, not much could be done! Or >if you compile the kernel without DEBUG, then the process would have simply >exit()'ed (and the system would still have been left without a root >filesystem). I see... it all makes sense now thanks. :-) > >Thanks for the help. :-) > >Thanks for giving me the needed information to debug the problem. > >Andy My pleasure. I hope I can help out quite a bit with this project. I've been hoping to get my hands dirty in something and this gave me a good opportunity, so I took it. I plan on going through the internals of VSTa and finding out how it all works. I'll admit that my C skills aren't phenomenal and haven't even been used in awhile, but I'm getting back into it. I look forward to being able to do something productive. :-) I have one more question. I try to run mgr, but bochs quits on me with a "bochs: panic, *** io read from vga port 3c8" in the bochs.out file. I'm pretty sure this is a limitation in the bochs vga emulation code, but I thought I'd ask anyway. Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Sun Nov 26 19:32:37 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAQJWb715379 for vsta-xplod; Sun, 26 Nov 2000 19:32:37 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAQJWYU15372; Sun, 26 Nov 2000 19:32:34 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id TAA23220; Sun, 26 Nov 2000 19:33:48 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011270333.TAA23220@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Sun, 26 Nov 2000 21:11:57 EST." Date: Sun, 26 Nov 2000 19:33:48 -0800 From: Andy Valencia ["Sandro Magi" writes:] >I have one more question. I try to run mgr, but bochs quits on me with a >"bochs: panic, *** io read from vga port 3c8" in the bochs.out file. I'm >pretty sure this is a limitation in the bochs vga emulation code, but I >thought I'd ask anyway. Most likely... Bochs is nicely written that way. When it sees some I/O device accessed in a way it doesn't understand, it logs a message about it and then aborts. Then you can hunt the message down in the source, and see if you can figure out how to enhance the emulation so it supports what you're doing. At some point, you'll most likely need to run VSTa on the bare hardware. But Bochs is really nice for getting started. Andy From daemon Mon Nov 27 07:48:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eAR7mkA16213 for vsta-xplod; Mon, 27 Nov 2000 07:48:46 GMT Received: from gate2.fw.mn.man.de (gate2.fw.mn.man.de [151.136.100.172]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eAR7meU16193 for ; Mon, 27 Nov 2000 07:48:41 GMT Received: by gate2.fw.mn.man.de (8.9.3/8.9.3) id QAA05122 for vsta@zendo.com; Mon, 27 Nov 2000 16:49:55 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate2.fw.mn.man.de (MSCAN) id 2/gate2.fw.mn.man.de/smtp-gw/mscan; Mon Nov 27 16:49:55 2000 Subject: Other Ports (Amiga/Mips) To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Mon, 27 Nov 2000 16:49:50 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 11/27/2000 04:49:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi! Are the older ports for Amiga/Mips or their sources in the standard source distribution, and if yes, where are they? And on which version of VSTa did they run? From daemon Mon Nov 27 13:50:05 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARDo5T16750 for vsta-xplod; Mon, 27 Nov 2000 13:50:05 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARDo1U16743; Mon, 27 Nov 2000 13:50:01 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA26130; Mon, 27 Nov 2000 13:51:17 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011272151.NAA26130@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: Other Ports (Amiga/Mips) In-reply-to: Your message of "Mon, 27 Nov 2000 16:49:50 +0100." Date: Mon, 27 Nov 2000 13:51:17 -0800 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >Are the older ports for Amiga/Mips or their sources in the standard source >distribution, and if yes, where are they? The Amiga port appears to be in vsta_152/amiga.tz. >And on which version of VSTa did they run? Well, something predating 1.5.2, probably. As for MIPS, I got that running ages ago and on a Cisco platform. I could probably extract the proprietary hardware stuff from the generic MIPS CPU support, but it'd take some work. What's it needed for? Andy From daemon Mon Nov 27 17:36:09 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARHa9a17103 for vsta-xplod; Mon, 27 Nov 2000 17:36:09 GMT Received: from hotmail.com (f94.law3.hotmail.com [209.185.241.94]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARHa6U17083 for ; Mon, 27 Nov 2000 17:36:06 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Nov 2000 17:37:22 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 28 Nov 2000 01:37:22 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: /dev ?? Date: Mon, 27 Nov 2000 20:37:22 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Nov 2000 01:37:22.0691 (UTC) FILETIME=[C1162530:01C058DB] What does '/dev' do in VSTa? I do a 'ls -l' and the output says 'dev: no entry'. I also tried 'vls -l' and that gave me 'perm' (which I believe is an error in VSTa right?). Everything else shows up fine, but /dev doesn't. Is /dev supposed to do something? Is it a device list/directory? _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Mon Nov 27 17:45:43 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARHjhV17137 for vsta-xplod; Mon, 27 Nov 2000 17:45:43 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARHjeU17130; Mon, 27 Nov 2000 17:45:41 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id RAA26548; Mon, 27 Nov 2000 17:46:57 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011280146.RAA26548@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: /dev ?? In-reply-to: Your message of "Mon, 27 Nov 2000 20:37:22 EST." Date: Mon, 27 Nov 2000 17:46:57 -0800 From: Andy Valencia ["Sandro Magi" writes:] >What does '/dev' do in VSTa? I do a 'ls -l' and the output says 'dev: no >entry'. I also tried 'vls -l' and that gave me 'perm' (which I believe is an >error in VSTa right?). Everything else shows up fine, but /dev doesn't. >Is /dev supposed to do something? Is it a device list/directory? Well, /dev is kinda-sorta a virtual directory. It wouldn't exist at all, except for /dev/null (most device servers aren't in the average user's filesystem namespace at all). If you do a "fstab" command, you'll see what's mounted in your process's filesystem namespace. You can "cat /dev/null" and get the expected result, but what does it mean if you mount something in a path which has "directory" entries which don't really exist? I wrestled with this early on, and you can look at the implementation of opendir/readdir for an idea of how I thought about this. But the shell, for instance, wants to stat() "/dev" before it'll chdir to it, and there's no similar emulation to fool it into thinking that there's a directory there. If somebody wanted to do some middle-weight hacking in the C library, that might be a useful enhancement. See open() in vsta/src/lib/open.c for where most of this would happen. BTW, try "echo /dev/*"... this is made possible by the opendir/readdir emulation of these pseudo-directories. *Some* of the logic is already present in the system. Regards, Andy Valencia From daemon Mon Nov 27 17:52:03 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARHq3b17157 for vsta-xplod; Mon, 27 Nov 2000 17:52:03 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARHpxU17150; Mon, 27 Nov 2000 17:51:59 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id RAA26568; Mon, 27 Nov 2000 17:53:16 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011280153.RAA26568@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de Cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Mon, 27 Nov 2000 11:04:07 +0100." Date: Mon, 27 Nov 2000 17:53:16 -0800 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >>Well, whatever. I booted from floppy and the rest of the disk image looks >>fine (including the failure). Now that I know it's sane, I'll load it as >>a file under VSTa and run a local DOS server. Thanks for your help! >You can do this? Cool! How do you do this? It's amazingly easy, seeing as all filesystems are just user programs anyway. If your disk image is named 10M, then you'd just do: cd /vsta/src/srv/dos ./dos -d 10M -n fs/tst & And then do: mount fs/tst /test (or whatever mount point you want) Now just "cd /test" and away you go. Of course, "gdb dos" and then running it under the debugger works well, too. Just use a second window (or screen, ALT-F[1234] are enabled by default, if you don't have MGR working yet) for the shell which cd's into the test filesystem. Note that the disk image had some leading stuff before the actual filesystem in question (17 sectors worth, if I recollect). So I had to do dd bs=512 skip=17 if=10M of=10M.new to trim off the leading sectors, and then I could work against the .new version. Andy Valencia From daemon Mon Nov 27 20:01:44 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARK1iq17294 for vsta-xplod; Mon, 27 Nov 2000 20:01:44 GMT Received: from hotmail.com (f18.law3.hotmail.com [209.185.241.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARK1gU17274 for ; Mon, 27 Nov 2000 20:01:42 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Nov 2000 20:02:59 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 28 Nov 2000 04:02:59 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Mon, 27 Nov 2000 23:02:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Nov 2000 04:02:59.0254 (UTC) FILETIME=[187BDD60:01C058F0] >Note that the disk image had some leading stuff before the actual >filesystem >in question (17 sectors worth, if I recollect). So I had to do > > dd bs=512 skip=17 if=10M of=10M.new > >to trim off the leading sectors, and then I could work against the >.new version. Working with disk images and bochs is kind of strange because bochs won't recognize any partitions when I tried to use a disk image that wasn't set the way I sent it to you. I'm pretty sure it's because it emulates a real computer and hence requires partitions and all for it's 'disks'. So what I had to do to create a useable image was boot into freedos using a preloaded freedos image, FDISK the main c:\ image and create a dos partition. I then had to FORMAT C: to create a dos filesystem. Otherwise the bootloader(GRUB) couldn't find a bootable partition. The 'mount' command in Linux provides functionality for skipping the x number of bytes that you stripped, so I could mount it directly. it's something like 'mount -o offset=8192 10M /mnt/10M'. The offset is calculated by the number of used sectors at the beginning of the image(ie. the number before the start of the partition), which in this case is 16. So 16*512(bytes/sectors) = 8192. Then I could load whatever I wanted onto the mounted image. The only thing I'm looking to do now is create a FAT32 partition or maybe even vstafs. Which brings me to a question which I haven't found answered anywhere in the documentation yet: what is the state of vstafs? is it useable? _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Mon Nov 27 21:15:25 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eARLFP417368 for vsta-xplod; Mon, 27 Nov 2000 21:15:25 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eARLEWU17358; Mon, 27 Nov 2000 21:14:32 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id VAA26860; Mon, 27 Nov 2000 21:15:49 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200011280515.VAA26860@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Mon, 27 Nov 2000 23:02:59 EST." Date: Mon, 27 Nov 2000 21:15:48 -0800 From: Andy Valencia ["Sandro Magi" writes:] >Working with disk images and bochs is kind of strange because bochs won't >recognize any partitions when I tried to use a disk image that wasn't set >the way I sent it to you. I'm pretty sure it's because it emulates a real >computer and hence requires partitions and all for it's 'disks'. Yes, it emulates all the way down to the sectors addressed from the IDE controller. >So what I had to do to create a useable image was boot into freedos using a >preloaded freedos image, FDISK the main c:\ image and create a dos >partition. I then had to FORMAT C: to create a dos filesystem. Otherwise the >bootloader(GRUB) couldn't find a bootable partition. I did pretty much the same thing, except using FreeBSD's fdisk (I had to hack it to operate on a plain file in the current directory). I think I used the mtools after that to create and populate the filesystem. >The 'mount' command in Linux provides functionality for skipping the x >number of bytes that you stripped, so I could mount it directly. it's >something like 'mount -o offset=8192 10M /mnt/10M'. The offset is calculated >by the number of used sectors at the beginning of the image(ie. the number >before the start of the partition), which in this case is 16. So >16*512(bytes/sectors) = 8192. Then I could load whatever I wanted onto the >mounted image. The only thing I'm looking to do now is create a FAT32 >partition or maybe even vstafs. The mtools can handle creating FAT-32... you might check into using them. >Which brings me to a question which I haven't found answered anywhere in the >documentation yet: what is the state of vstafs? is it useable? Yes, it's usable. Not anywhere near as mature as the DOS server at this point, but good enough to use as a root filesystem and such. With the DOS long filename support in the latest release, the one big thing vstafs still has over DOS is that the files and directories support VSTa's protection model. Andy Valencia From daemon Fri Dec 1 07:36:31 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eB17aVZ23337 for vsta-xplod; Fri, 1 Dec 2000 07:36:31 GMT Received: from hotmail.com ([209.185.241.80]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eB17aRU23317 for ; Fri, 1 Dec 2000 07:36:28 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Dec 2000 07:38:00 -0800 Received: from 64.229.102.143 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 01 Dec 2000 15:38:00 GMT X-Originating-IP: [64.229.102.143] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: VSTa 1.6.5 Date: Fri, 01 Dec 2000 10:38:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Dec 2000 15:38:00.0251 (UTC) FILETIME=[AF7448B0:01C05BAC] >cd /vsta/src/srv/dos >./dos -d 10M -n fs/tst & > >And then do: > >mount fs/tst /test (or whatever mount point you want) How do you mount a floppy in VSTa? I'm guessing the syntax is somewhat similar to the above, but I can't find any documentation on the required options or the procedure. I've tried a few things but can't get it to work. I can execute the fd server no problem, but then how can I mount the floppies in a directory? _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Fri Dec 1 13:19:21 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eB1DJLs23818 for vsta-xplod; Fri, 1 Dec 2000 13:19:21 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eB1DJGU23811; Fri, 1 Dec 2000 13:19:16 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA00403; Fri, 1 Dec 2000 13:20:44 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012012120.NAA00403@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: VSTa 1.6.5 In-reply-to: Your message of "Fri, 01 Dec 2000 10:38:00 EST." Date: Fri, 01 Dec 2000 13:20:44 -0800 From: Andy Valencia ["Sandro Magi" writes:] >How do you mount a floppy in VSTa? I'm guessing the syntax is somewhat >similar to the above, but I can't find any documentation on the required >options or the procedure. I've tried a few things but can't get it to work. Usually you don't want to bother mounting the floppy driver into your filesystem namespace, although it's easy enough to do: /vsta/boot/fd & mount disk/fd /fd cd /fd ls However, you usually just want to run a filesystem on top of the disk, so: /vsta/boot/fd & /vsta/boot/dos -d //disk/fd:fd0_1440 -n fs/tst & mount fs/tst /xyz cd /xyz ls So "//foo" means "go to the namer registry, and look for it there, even though it isn't mounted in my filesystem". The syntax "//foo:bar" means, "once you have the thing registered as 'foo', access it as a directory and open the file 'bar" within it". In the case of floppies, the floppy server/driver has registered itself as "disk/fd" with the namer registry. You can either mount this as a directory in your filesystem, and can cd into it, look at its files (which are just the floppy drive entries with names corresponding to the various densities), open/close/read/write them, and so forth. Or instead you can have a new filesystem server access the nodes directly. It also works just as well to do: /vsta/boot/fd & mount disk/fd /fd /vsta/boot/dos -d /fd/fd0_1440 -n fs/tst & mount fs/tst /xyz The only difference being that you'll have a /fd directory mounted in addition to the filesystem itself. Of course, you could always: umount /fd once the server is running, and it'll be removed from your filesystem view (though, of course, the dos server will continue to operate, since he has his own filesystem view cloned from when it *was* present, and besides, he already has the device open and won't need to look at his filesystem again). Andy Valencia From daemon Fri Dec 1 13:21:14 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eB1DLEr23836 for vsta-xplod; Fri, 1 Dec 2000 13:21:14 GMT Received: from vandys-pc.zendo.com (vandy-frame.cisco.com [171.70.231.17]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eB1DLCU23829 for ; Fri, 1 Dec 2000 13:21:13 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA00414 for ; Fri, 1 Dec 2000 13:22:40 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012012122.NAA00414@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Other VSTa news Date: Fri, 01 Dec 2000 13:22:40 -0800 From: Andy Valencia I noticed just recently that the 322 meg disk image I supplied to work with the Bochs x86 emulator somehow was truncated. I've uploaded a fresh copy. See ftp://ftp.vsta.org/vsta/pickup/bochs. And yes, the floppy emulation of Bochs is good enough for the VSTa floppy driver. I also coded up filename completion for the getline() library. I'm already wondering how I did without it for so long! Andy Valencia From daemon Wed Dec 13 08:17:21 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBD8HLd10968 for vsta-xplod; Wed, 13 Dec 2000 08:17:21 GMT Received: from hotmail.com (f95.law3.hotmail.com [209.185.241.95]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBD8HA110948 for ; Wed, 13 Dec 2000 08:17:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Dec 2000 08:25:54 -0800 Received: from 64.229.107.212 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 13 Dec 2000 16:25:53 GMT X-Originating-IP: [64.229.107.212] From: "Sandro Magi" To: vsta@zendo.com Subject: MGR in VSTa 1.6.5 Date: Wed, 13 Dec 2000 11:25:53 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Dec 2000 16:25:54.0197 (UTC) FILETIME=[5D6AA450:01C06521] I've installed VSTa on a real machine now(as opposed to running it in Bochs) but I can't run mgr; it exits with a 'perm'. This is what I tried when logged in as root(though I don't see how that should make any difference): vsta$ mgr & Using Cirrus Logic GD542x/3x driver (5436, 1024k) perm vsta$ mgr -v MGR version 0.53 compiled by SER at Sun Dec 15 09:36:11 1996 GMT System: VSTa baruk v1.5.2 i386 perm The video does work because the system is running windows. I took off the case and checked out the video chip. It is indeed a Cirrus Logic GD5436 chip integrated onto the motherboard. The computer is a Compaq Deskpro P166MHz. Any clues? Thanks or any help. :-) Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Wed Dec 13 08:42:22 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBD8gMm11019 for vsta-xplod; Wed, 13 Dec 2000 08:42:22 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBD8es111011; Wed, 13 Dec 2000 08:40:54 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA29057; Wed, 13 Dec 2000 08:49:45 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012131649.IAA29057@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: MGR in VSTa 1.6.5 In-reply-to: Your message of "Wed, 13 Dec 2000 11:25:53 EST." Date: Wed, 13 Dec 2000 08:49:45 -0800 From: Andy Valencia ["Sandro Magi" writes:] >I've installed VSTa on a real machine now(as opposed to running it in Bochs) >but I can't run mgr; it exits with a 'perm'. This is what I tried when >logged in as root(though I don't see how that should make any difference): >vsta$ mgr & > Using Cirrus Logic GD542x/3x driver (5436, 1024k) Did you have a mouse driver running? >vsta$ mgr -v > MGR version 0.53 compiled by SER at Sun Dec 15 09:36:11 1996 GMT > System: VSTa baruk v1.5.2 i386 >The video does work because the system is running windows. I took off the >case and checked out the video chip. It is indeed a Cirrus Logic GD5436 chip >integrated onto the motherboard. The computer is a Compaq Deskpro P166MHz. >Any clues? Thanks or any help. :-) Well... svgalib doesn't cover chipsets as well as Windoze, and who knows if I got the port right for your chipset (I don't have one of those, so I couldn't test it). In these situations the most you can do is attach a terminal the COM port (or bring up networking and telnet in) and go to work with gdb on the mgr executable. Andy From daemon Wed Dec 13 10:56:51 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBDAupj11303 for vsta-xplod; Wed, 13 Dec 2000 10:56:51 GMT Received: from hotmail.com (f214.law3.hotmail.com [209.185.241.214]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBDAul111283 for ; Wed, 13 Dec 2000 10:56:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Dec 2000 11:05:27 -0800 Received: from 64.229.107.212 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 13 Dec 2000 19:05:27 GMT X-Originating-IP: [64.229.107.212] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: MGR in VSTa 1.6.5 Date: Wed, 13 Dec 2000 14:05:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Dec 2000 19:05:27.0672 (UTC) FILETIME=[A7A6FF80:01C06537] > >I've installed VSTa on a real machine now(as opposed to running it in >Bochs) > >but I can't run mgr; it exits with a 'perm'. This is what I tried when > >logged in as root(though I don't see how that should make any >difference): > >vsta$ mgr & > > Using Cirrus Logic GD542x/3x driver (5436, 1024k) > >Did you have a mouse driver running? Ahh... I did not. I just tried to run the mouse driver but I can't figure out the options. It says I must specify a mouse type. What are the options for that? >Well... svgalib doesn't cover chipsets as well as Windoze, and who knows if >I got the port right for your chipset (I don't have one of those, so I >couldn't test it). In these situations the most you can do is attach a >terminal the COM port (or bring up networking and telnet in) and go to work >with gdb on the mgr executable. > >Andy Well, I'll let you know if this chipset works as soon as I get a mouse server running and I try mgr again. :-) Since you mentioned networking, what NIC's does VSTa support? I remember seeing that ne2000 chipsets are supported. Any others? I currently have a 3Com 3c905 10/100 Base-T NIC. I also have cards with DEC and RealTek chipsets I could try out. Are any of those supported? Sincerely, Sandro _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From daemon Thu Dec 14 10:14:24 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBEAEOB12821 for vsta-xplod; Thu, 14 Dec 2000 10:14:24 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBEAEG112814; Thu, 14 Dec 2000 10:14:16 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id KAA01095; Thu, 14 Dec 2000 10:23:06 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012141823.KAA01095@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: MGR in VSTa 1.6.5 In-reply-to: Your message of "Wed, 13 Dec 2000 14:05:27 EST." Date: Thu, 14 Dec 2000 10:23:06 -0800 From: Andy Valencia ["Sandro Magi" writes:] >>Did you have a mouse driver running? >Ahh... I did not. I just tried to run the mouse driver but I can't figure >out the options. It says I must specify a mouse type. What are the options >for that? Something like: /vsta/boot/mouse -type {pc98_bus, microsoft_bus, logitech_bus, serial, ps2aux} For ps2aux you may also need to add the "-bus" option, if mouse motion doesn't track correctly without it. >Since you mentioned networking, what NIC's does VSTa support? I remember >seeing that ne2000 chipsets are supported. Any others? I currently have a >3Com 3c905 10/100 Base-T NIC. I also have cards with DEC and RealTek >chipsets I could try out. Are any of those supported? You can have any NIC you want, so long as it's an NE2000. :-( This would be a really, really good project for anybody interested in doing something Truly Useful. An example of the approach to take is the wrappers which the Flux OS Kit folks put around the FreeBSD drivers. Andy Valencia From daemon Fri Dec 15 08:30:05 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBF8U5014401 for vsta-xplod; Fri, 15 Dec 2000 08:30:05 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBF8U1114393 for ; Fri, 15 Dec 2000 08:30:01 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA07916 for ; Fri, 15 Dec 2000 08:38:59 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012151638.IAA07916@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Would somebody be interested in giving a talk on VSTa? Date: Fri, 15 Dec 2000 08:38:59 -0800 From: Andy Valencia I have received an invitation to present at Cologne, Germany in March. I myself am unable to attend, but if anybody on the list is able and willing, please contact Mr. Schulte. As I told Martin, I will be happy to provide help to the presenter in preparing such a talk. Thanks! Andy Valencia >From: Martin Schulte >To: vandys@zendo.com >Subject: Talk about VSTa >Date: Thu, 14 Dec 2000 20:07:10 +0100 >X-Mailer: KMail [version 1.0.28] >XXContent-Type: text/plain >MIME-Version: 1.0 >Message-Id: <00121420103304.00957@martnix> >XXContent-Transfer-Encoding: 8bit > >Dear Andrew, > >my name is Martin Schulte, I'm organizing the Kongresses of the GUUG - German >UNIX Users Group. While the Linux-Kongress (http://www.linux-kongress.de/) is >widely known, we still have our traditional spring meeting >(http://www.guug.de/veranstaltungen/osie/2001 - sorry, it is in German), where >like to look on other technologies. > >As I heard of your project, I strongly felt that we would fit very well into the >track about new ideas in operating system design ! > >So, my question is: Could you imagine to give a talk about the basics of VSTa on >March, 1st or 2nd here in Cologne ? If not, is there someone else you could >suggest to give the talk ? > >I'm looking forward to hear from you, > >Martin From daemon Sun Dec 17 16:16:50 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBHGGo620229 for vsta-xplod; Sun, 17 Dec 2000 16:16:50 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBHGGk120221; Sun, 17 Dec 2000 16:16:46 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id QAA00582; Sun, 17 Dec 2000 16:25:49 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012180025.QAA00582@vandys-pc.zendo.com> To: Eric Jacobs cc: vsta@zendo.com Subject: Re: Event handlers In-reply-to: Your message of "Sun, 17 Dec 2000 14:52:29 EDT." Date: Sun, 17 Dec 2000 16:25:49 -0800 From: Andy Valencia [Eric Jacobs writes:] >I've been thinking about trying to get the Linux drivers to run >as a user process. To simulate hardware interrupts, an obvious >approach is to use notify, but in event.c: > > * A process has two distinct incoming streams > * of events--a process-generated one and a system-generated one. > * The system events take precedence. For process events, a sender > * will sleep until the target process has accepted a current event and > * (if he has a handler registered) returned from the handler. > >If the sender blocks, we'd have to use multiple threads to >simulate re-entrant interrupts, which could be kind of clumsy. You should use a thread to accept the ISR message. From there, I'd suggest just running the ISR code directly from that thread. There's no reason to suspend executing the ISR code to service the same ISR. If there's something long enough that you feel you need to get back to waiting for front-line ISR's, you should use mutex_thread() to kick awake a background thread to do the rest of the work. >But I don't see any code to actually make it do this. It looks as >though the sender doesn't block at all and the receiver just >picks up the event the next time it enters the kernel. See signal_thread(), for the EGAIN case right near the top of the routine. >Actually, having it asynchronous like that would be more suitable >for simulating interrupts. I'm thinking of a scenario where we have >N shepherd threads that all block on msg_receive(), synchronize with >the global lock and then jump into the driver. When an interrupt >message is received, we can notify the currently running thread >(which itself may be in an interrupt.) The interrupted thread would >be "wasted" for the duration of that interrupt handler, of course, >but I see no reason why the interruptor thread should be similarly >held up (it could go back for more interrupts, or at least get the >next request set up.) Am I on the right track here? Usually a single driver will handle a single ISR source. If this comes to a unique port (see how mach/rs232 does this) you avoid priority inversions with the clients of the driver. But so long as you you use a single thread, you're implicitly serialized for interrupt handling, and thus don't have to weigh down your design with lots of locks. When the ISR code is done with its part and wants to kick some work to the "top half" of the driver, it does it by way of mutex_thread() (rather than just sending a message to the main message queue, again to avoid priority inversion with other work the top half code may be executing at any given time). The thread waiting for this wakeup can either handle the work, or *it* turns it into a message to the main queue (which is what the RS-232 driver does), because it's OK for this slave to get blocked on the main message queue--it's just the ISR code we don't want to have hung. You really, really don't want to try and run a single process which represents all of the Linux drivers collectively. Each individual driver should be linked into an emulation environment which runs as its own distinct process. Then you're generally looking at one ISR source, and if you map it to one thread, things simplify nicely. Andy Valencia From daemon Sun Dec 17 23:48:09 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBHNm9s20685 for vsta-xplod; Sun, 17 Dec 2000 23:48:09 GMT Received: from gate1.fw.mn.man.de (gate1.fw.mn.man.de [151.136.100.171]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBHNm4120665 for ; Sun, 17 Dec 2000 23:48:04 GMT Received: by gate1.fw.mn.man.de (8.9.3/8.9.3) id IAA14447 for vsta@zendo.com; Mon, 18 Dec 2000 08:57:13 +0100 (CET) From: Martin_Doering@mn.man.de Received: (from localhost) by gate1.fw.mn.man.de (MSCAN) id 2/gate1.fw.mn.man.de/smtp-gw/mscan; Mon Dec 18 08:57:13 2000 Subject: HAL for Drivers To: vsta@zendo.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Mon, 18 Dec 2000 08:57:08 +0100 X-MIMETrack: Serialize by Router on MMMAIL001/SRV/MAN_Nutzfahrzeuge(Release 5.0.4 |June 8, 2000) at 12/18/2000 08:57:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Andy wrote: >This would be a really, really good project for anybody interested in doing >something Truly Useful. An example of the approach to take is the wrappers >which the Flux OS Kit folks put around the FreeBSD drivers. I read, that the FreeBSD Folks have some HAL to abstract the hardware over the platforms and to make proting of drivers a bit less complicated. Can we use the same HAL? Or does it not fit into VSTa? From daemon Mon Dec 18 08:53:27 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBI8rRT21308 for vsta-xplod; Mon, 18 Dec 2000 08:53:27 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBI8rL121301; Mon, 18 Dec 2000 08:53:21 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA03711; Mon, 18 Dec 2000 09:02:27 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012181702.JAA03711@vandys-pc.zendo.com> To: Martin_Doering@mn.man.de cc: vsta@zendo.com Subject: Re: HAL for Drivers In-reply-to: Your message of "Mon, 18 Dec 2000 08:57:08 +0100." Date: Mon, 18 Dec 2000 09:02:27 -0800 From: Andy Valencia [Martin_Doering@mn.man.de writes:] >I read, that the FreeBSD Folks have some HAL to abstract the hardware over >the platforms and to make proting of drivers a bit less complicated. Can we >use the same HAL? Or does it not fit into VSTa? I can't find anything about it (and it sure doesn't jump out at me from the FreeBSD source of my current system). Do you have a URL to something describing their design? Thanks, Andy Valencia From daemon Mon Dec 18 13:52:27 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBIDqRw21699 for vsta-xplod; Mon, 18 Dec 2000 13:52:27 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBIDqM121679 for ; Mon, 18 Dec 2000 13:52:23 GMT Message-id: Date: Mon, 18 Dec 2000 16:57:34 -0500 Subject: Re: Event handlers To: vsta@zendo.com From: "Eric Jacobs" References: In-Reply-To: MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Andy Valencia : > [Eric Jacobs writes:] > > > * A process has two distinct incoming streams > > * of events--a process-generated one and a system-generated one. > > * The system events take precedence. For process events, a sender > > * will sleep until the target process has accepted a current event and > > * (if he has a handler registered) returned from the handler. > > > > If the sender blocks, we'd have to use multiple threads to simulate > > re-entrant interrupts, which could be kind of clumsy. > > You should use a thread to accept the ISR message. From there, I'd > suggest just running the ISR code directly from that thread. There's no > reason to suspend executing the ISR code to service the same ISR. The Linux drivers probably do not expect their ISR's to run concurrently with the service threads. So we would need some way to suspend the currently running threads. It appears that notify() would be the best way to do that. I'm inclined to try to emulate the Linux environment as closely as possible, to maintain compatibility with the many idiosyncratic drivers and devices out there. If you look at the "Execution Environments" section of the OSKit documentation, you'll see that they have it spelled out. If I was going to translate each driver individually, I would probably look at changing around the ISR calling procedures to make it simpler and faster. But as the OSKit simply wraps the drivers, assuming a Linux execution model, I'm wary of such shortcuts. > If there's something long enough that you feel you need to get back to > waiting for front-line ISR's, you should use mutex_thread() to kick > awake a background thread to do the rest of the work. > > > But I don't see any code to actually make it do this. It looks as > > though the sender doesn't block at all and the receiver just picks up > > the event the next time it enters the kernel. > > See signal_thread(), for the EGAIN case right near the top of the > routine. Right, but t_evproc is cleared before the event is sent, not after it returns. That's what was throwing me off. > > Actually, having it asynchronous like that would be more suitable for > > simulating interrupts. I'm thinking of a scenario where we have N > > shepherd threads that all block on msg_receive(), synchronize with the > > global lock and then jump into the driver. When an interrupt message > > is received, we can notify the currently running thread (which itself > > may be in an interrupt.) The interrupted thread would be "wasted" for > > the duration of that interrupt handler, of course, but I see no reason > > why the interruptor thread should be similarly held up (it could go > > back for more interrupts, or at least get the next request set up.) Am > > I on the right track here? > > Usually a single driver will handle a single ISR source. If this comes > to a unique port (see how mach/rs232 does this) you avoid priority > inversions with the clients of the driver. But so long as you you use a > single thread, you're implicitly serialized for interrupt handling, and > thus don't have to weigh down your design with lots of locks. I've thought about having two receiving ports open like that. But each port requires at least one thread to service it, so we're automatically multithreaded and I don't see how we can avoid some kind of locking. The big lock for the linux code would be its global component lock, which shouldn't be too difficult anyway. It may be possible to have a compile or run time option that NOP's out the locking, if there's only going to be one client service thread (just have it always appear to be holding the lock.) > When the ISR code is done with its part and wants to kick some work to > the "top half" of the driver, it does it by way of mutex_thread() > (rather than just sending a message to the main message queue, again to > avoid priority inversion with other work the top half code may be > executing at any given time). The thread waiting for this wakeup can > either handle the work, or *it* turns it into a message to the main > queue (which is what the RS-232 driver does), because it's OK for > this slave to get blocked on the main > message queue--it's just the ISR code we don't want to have hung. The way that the OSKit wraps the drivers (and I'm not saying that this is the best way for VSTa) is to let the Linux code do all of the signaling between the top-half and bottom-half driver portions. So in the OSKit conception, all that the host OS (or process as we'll have it) needs to do is to suspend the thread that's executing the Linux code (if any) and then call that appropriate interrupt routine that was registered at initialization time. > You really, really don't want to try and run a single process which > represents all of the Linux drivers collectively. Each individual > driver should be linked into an emulation environment which runs as its > own distinct process. Then you're generally looking at one ISR source, > and if you map it to one thread, things simplify nicely. If we have two ports, one for clients and one for interrupts, we'll need at least two threads because msg_receive() will block, so single-threading is out. If we have only port, then we'll still at least need the option to have another thread to look for IRQ's while the thread is running (for instance, some Linux drivers could busy wait for interrupts.) I agree that running multiple drivers in one process is not going to be important for most applications. My attitude is that if we implement the driver set correctly (as specified by the OSKit), then drivers aggregated together will work. If not, random things will break. On the other hand, being able to run, say, a driver and a filesystem in the same process could be a big win, because then we avoid a whole layer of IPC. I know that all of this is not going to be optimal, and if we were in the business of rewriting the driver set I'm sure we could do things better. The good news is that a lot of these options could be selected at run-time (for example, if we knew it was okay, we could load a driver to run single-threaded, and its structure would reduce to something vaguely similar to the way native VSTa drivers are written.) Maybe we need something like the FreeBSD "ports" system, where we can collect data on how to run each driver best. From daemon Mon Dec 18 14:20:24 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBIEKO121760 for vsta-xplod; Mon, 18 Dec 2000 14:20:24 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBIEK6121753; Mon, 18 Dec 2000 14:20:09 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA04270; Mon, 18 Dec 2000 14:28:51 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012182228.OAA04270@vandys-pc.zendo.com> To: "Eric Jacobs" cc: vsta@zendo.com Subject: Re: Event handlers In-reply-to: Your message of "Mon, 18 Dec 2000 16:57:34 EST." Date: Mon, 18 Dec 2000 14:28:51 -0800 From: Andy Valencia ["Eric Jacobs" writes:] >... >I know that all of this is not going to be optimal, and if we were in the >business of rewriting the driver set I'm sure we could do things >better. The good news is that a lot of these options could be selected >at run-time (for example, if we knew it was okay, we could load a >driver to run single-threaded, and its structure would reduce to >something vaguely similar to the way native VSTa drivers are >written.) Maybe we need something like the FreeBSD "ports" system, >where we can collect data on how to run each driver best. Hey, in the proud tradition of experimentation, I'd say go for it. The worst that can happen is that you'll discover what needs to be changed. And most likely, not much. BTW, the new event handling system (handle_event() and friends, see src/lib/event.c) should let you plug into this nicely. Above all... have fun! Andy Valencia From daemon Tue Dec 19 15:16:06 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBJFG6v00295 for vsta-xplod; Tue, 19 Dec 2000 15:16:06 GMT Received: from fw.softwell.se (IDENT:root@[193.15.236.45]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBJFG0i00274; Tue, 19 Dec 2000 15:16:01 GMT Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id WAA12217; Tue, 19 Dec 2000 22:27:35 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id WAA28745; Tue, 19 Dec 2000 22:27:34 +0100 Date: Tue, 19 Dec 2000 22:27:34 +0100 From: Bengt Kleberg Message-Id: <200012192127.WAA28745@trillian.softwell.se> To: Martin_Doering@mn.man.de, vandys@zendo.com Subject: Re: HAL for Drivers Cc: vsta@zendo.com > From: Andy Valencia > I can't find anything about it (and it sure doesn't jump out at me from the > FreeBSD source of my current system). Perhaps this is the NetBSD approach that is actually meant? Bengt Kleberg From daemon Wed Dec 20 20:36:46 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBKKakm02223 for vsta-xplod; Wed, 20 Dec 2000 20:36:46 GMT Received: from smtp1.mail.yahoo.com (smtp1.mail.yahoo.com [128.11.69.60]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id eBKKaei02203 for ; Wed, 20 Dec 2000 20:36:41 GMT Received: from 103bus37.tampabay.rr.com (HELO yyz) (24.94.103.37) by smtp.mail.vip.suc.yahoo.com with SMTP; 21 Dec 2000 04:48:12 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: HAL for Drivers Date: Wed, 20 Dec 2000 23:48:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Perhaps a worthwhile endeavor is to unify interfaces, advocate and promulgate a device driver (HAL) bridge spec for portable drivers. Perhaps the various existing OS's such as linux and *bsd would need bridge driver entrypoints in several parts of the source tree, but the general methods of accessing any given driver could be squashed to least-common-denominator (fs, mentioned below). The idea that Intel's I2O could have been such a spec was intriguing, and unfortunately also proprietary and ultimately stillborn. The beginnings of this would work well if such drivers interfaces were wrapped into a unified filesystem spec, again, a portable spec designed to be 'just one more driver' in each adopting OS (which coincidentally would also facilitate the development of unoptimized filesystem drivers for ra(b|p)idly portable testbed development). Reiserfs has an interesting approach to method calls to the filesystem driver itself, such as the proposed ".archive" method. Something like this would exemplify a means of extensible additions to the base driver without introducing new binary interfaces at compile time (by tarring a directory in this case). Looks like Bochs and Plex are the dominant momentum in virtual machine stuff but I haven't read that either offers device solutions are actually geared toward simplified portability. Am I missing some ongoing effort that addresses concepts like these already? My $.02. -----Original Message----- From: Martin_Doering@mn.man.de [mailto:Martin_Doering@mn.man.de] Sent: Monday, December 18, 2000 2:57 AM To: vsta@zendo.com Subject: HAL for Drivers Andy wrote: >This would be a really, really good project for anybody interested in doing >something Truly Useful. An example of the approach to take is the wrappers >which the Flux OS Kit folks put around the FreeBSD drivers. I read, that the FreeBSD Folks have some HAL to abstract the hardware over the platforms and to make proting of drivers a bit less complicated. Can we use the same HAL? Or does it not fit into VSTa? _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Mon Dec 25 06:13:05 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBP6D5g11092 for vsta-xplod; Mon, 25 Dec 2000 06:13:05 GMT Received: from hotmail.com ([209.185.241.34]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBP6D0i11072 for ; Mon, 25 Dec 2000 06:13:00 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2000 06:24:40 -0800 Received: from 64.229.99.222 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 25 Dec 2000 14:24:40 GMT X-Originating-IP: [64.229.99.222] From: "Sandro Magi" To: vsta@zendo.com Subject: Performance Date: Mon, 25 Dec 2000 09:24:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Dec 2000 14:24:40.0876 (UTC) FILETIME=[6B22EEC0:01C06E7E] I was testing out VSTa and comparing it to my Linux installation and ran a brief subjective test. I tried untarring and gunzipping the vsta_src.tz file and noticed a huge speed difference. VSTa performed at least 3-4 times slower than Linux. I'll admit that I'm no OS expert, but I'm trying to learn so I was wondering what the main reason for the difference would be. Is it because of the extra overhead involved in message passing? Is it because of un-optimized disk drivers? Is it because of a less efficient or more fair scheduler? Is it just because of the extra overhead involved in piping by message passing through the 'pipe' server? Also, untarring and gunzipping the vsta_src.tz file never finishes. It always prematurely exits with a 'broken pipe' error. Is this because I'm running out of memory? Even small archives sometimes exit like this as well. Even compiling programs exit with broken pipes. Is this just a problem with my installation? Thanks for any help or insight. :-) Sincerely, Sandro _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Mon Dec 25 07:50:41 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBP7of711204 for vsta-xplod; Mon, 25 Dec 2000 07:50:41 GMT Received: from cosmic.com (trantor.cosmic.com [209.58.189.187]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBP7oci11184 for ; Mon, 25 Dec 2000 07:50:38 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id KAA03966 for vsta@zendo.com; Mon, 25 Dec 2000 10:53:48 -0500 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: Performance Date: 25 Dec 2000 10:53:48 -0500 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 34 Message-ID: <927qic$3rs$1@trantor.cosmic.com> References: X-Trace: trantor.cosmic.com 977759628 3965 10.10.10.1 (25 Dec 2000 15:53:48 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article , Sandro Magi wrote: >I was testing out VSTa and comparing it to my Linux installation and ran a >brief subjective test. I tried untarring and gunzipping the vsta_src.tz file >and noticed a huge speed difference. VSTa performed at least 3-4 times >slower than Linux. There are a few reasons for this, some good, some not. Linux gets a lot of its superior subjective performance from the fact that it caches disk writes so aggressively. VSTa, on the other hand, always tries to keep the disk in sync. There are upsides and downsides to both approaches; Linux's method feels faster but there's more risk of data loss in the case of a power failure. The other big reason is that the FAT filesystem is an extremely simple filesystem and is not as efficient as the ext2 filesystem that Linux uses. VSTa supports another filesystem called 'vstafs', which is a more modern design and gives better performance. Another thing you might try is passing a larger number in the -B switch to the "wd" server... this makes it use a larger buffer, if you've got some memory to spare. >Also, untarring and gunzipping the vsta_src.tz file never finishes. It >always prematurely exits with a 'broken pipe' error. Are you certain that it exits prematurely? i.e., have you verified that some files aren't being extracted. Strictly speaking, the broken pipe condition may not be an error.... for example, if you're piping the output from gunzip as input to tar, then tar only knows when to stop working when an EOF comes over the pipe. --Mirian From daemon Mon Dec 25 08:44:54 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBP8is111268 for vsta-xplod; Mon, 25 Dec 2000 08:44:54 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBP8ipi11261; Mon, 25 Dec 2000 08:44:51 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA18498; Mon, 25 Dec 2000 08:56:31 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012251656.IAA18498@vandys-pc.zendo.com> To: mirian@cosmic.com (Mirian Crzig Lennox) cc: vsta@zendo.com Subject: Re: Performance In-reply-to: Your message of "25 Dec 2000 10:53:48 EST." <927qic$3rs$1@trantor.cosmic.com> Date: Mon, 25 Dec 2000 08:56:31 -0800 From: Andy Valencia [mirian@cosmic.com (Mirian Crzig Lennox) writes:] >Linux gets a lot of its superior subjective performance from the fact >that it caches disk writes so aggressively. VSTa, on the other hand, always >tries to keep the disk in sync. This is true... it really costs quite a bit of performance. But as an OS experimenter, I find the hardness of the filesystem to be well worth the slowdown on the occasional bulk data operations I do. One other thing to note is that when doing "tar -z..." operations, you're going through a pipe server which does very, very little buffering. An interesting project for somebody would be to revisit this design aspect of VSTa pipes. Right now the pipe server doesn't maintain a private copy of the data (it blocks the writer until it can point the reader's I/O vectors directly at the writer's data). This is cool, and shows the flexibility of vectored I/O messages, but I suspect in the big picture it'd be better for the pipe server to buffer quite a bit of data, to permit more concurrency between reader and writer. >>Also, untarring and gunzipping the vsta_src.tz file never finishes. It >>always prematurely exits with a 'broken pipe' error. It probably finished OK... Dave Hudson made the pipe server play with compressed tar. But it has seemed like there's a race condition in there somewhere. The few times I've looked, the final file of the archive had been extracted OK, and thus I never gave much priority to fixing that spurious error message. Andy Valencia From daemon Mon Dec 25 12:01:51 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBPC1pu11504 for vsta-xplod; Mon, 25 Dec 2000 12:01:51 GMT Received: from hotmail.com (f118.law3.hotmail.com [209.185.241.118]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBPC1mi11484 for ; Mon, 25 Dec 2000 12:01:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2000 12:13:25 -0800 Received: from 64.229.99.222 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 25 Dec 2000 20:13:25 GMT X-Originating-IP: [64.229.99.222] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Performance Date: Mon, 25 Dec 2000 15:13:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Dec 2000 20:13:25.0293 (UTC) FILETIME=[230F95D0:01C06EAF] >Sandro Magi wrote: > >I was testing out VSTa and comparing it to my Linux installation and ran >a > >brief subjective test. I tried untarring and gunzipping the vsta_src.tz >file > >and noticed a huge speed difference. VSTa performed at least 3-4 times > >slower than Linux. > >There are a few reasons for this, some good, some not. > >Linux gets a lot of its superior subjective performance from the fact >that it caches disk writes so aggressively. VSTa, on the other hand, >always >tries to keep the disk in sync. There are upsides and downsides to both >approaches; Linux's method feels faster but there's more risk of data loss >in the case of a power failure. Ahhh... I hadn't thought of that. I see how that could result in apparent slower performance. >The other big reason is that the FAT filesystem is an extremely simple >filesystem and is not as efficient as the ext2 filesystem that Linux uses. >VSTa supports another filesystem called 'vstafs', which is a more modern >design and gives better performance. Well this is a moot point since I extracted the file on the same FAT partition in both Linux and VSTa to eliminate that possibility. >Another thing you might try is passing a larger number in the -B switch to >the "wd" server... this makes it use a larger buffer, if you've got some >memory to spare. I'll check that out. Thanks. > >Also, untarring and gunzipping the vsta_src.tz file never finishes. It > >always prematurely exits with a 'broken pipe' error. > >Are you certain that it exits prematurely? i.e., have you verified that >some files aren't being extracted. Strictly speaking, the broken pipe >condition may not be an error.... for example, if you're piping the >output from gunzip as input to tar, then tar only knows when to stop >working when an EOF comes over the pipe. > >--Mirian I see. I'm just saying it exits prematurely because it's giving me an error message. I'm performing the extraction with the command: 'tar zxvpf vsta_src.tz' so no explicit piping involved, just implicit. Thanks for the info. Sincerely, Sandro _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Mon Dec 25 12:52:20 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBPCqKO11572 for vsta-xplod; Mon, 25 Dec 2000 12:52:20 GMT Received: from hotmail.com (f153.law3.hotmail.com [209.185.241.153]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBPCqIi11552 for ; Mon, 25 Dec 2000 12:52:18 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2000 13:03:59 -0800 Received: from 64.229.99.222 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 25 Dec 2000 21:03:59 GMT X-Originating-IP: [64.229.99.222] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Performance Date: Mon, 25 Dec 2000 16:03:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Dec 2000 21:03:59.0602 (UTC) FILETIME=[33A66520:01C06EB6] >[mirian@cosmic.com (Mirian Crzig Lennox) writes:] > > >Linux gets a lot of its superior subjective performance from the fact > >that it caches disk writes so aggressively. VSTa, on the other hand, >always > >tries to keep the disk in sync. > >This is true... it really costs quite a bit of performance. But as an OS >experimenter, I find the hardness of the filesystem to be well worth the >slowdown on the occasional bulk data operations I do. I see your point. >One other thing to note is that when doing "tar -z..." operations, you're >going through a pipe server which does very, very little buffering. I figured alot of it had to do with the piping system in VSTa more than anything else. I hadn't considered the disk caching though. >An >interesting project for somebody would be to revisit this design aspect of >VSTa pipes. Right now the pipe server doesn't maintain a private copy of >the data (it blocks the writer until it can point the reader's I/O vectors >directly at the writer's data). This is cool, and shows the flexibility of >vectored I/O messages, but I suspect in the big picture it'd be better for >the pipe server to buffer quite a bit of data, to permit more concurrency >between reader and writer. > > >>Also, untarring and gunzipping the vsta_src.tz file never finishes. It > >>always prematurely exits with a 'broken pipe' error. > >It probably finished OK... Dave Hudson made the pipe server play with >compressed tar. But it has seemed like there's a race condition in there >somewhere. The few times I've looked, the final file of the archive had >been extracted OK, and thus I never gave much priority to fixing that >spurious error message. > >Andy Valencia I'm not sure since I don't know what the last file was. I'll try creating my own tarred, gzipped files and see what happens. The curious thing is, it only happens sometimes. If, as the previous person mentioned, it's because of an EOF on the pipe, then it would happen for every pipe, but it doesn't. It just happens on the larger archives. I'll do a little more testing. Thanks for all your help and suggestions! :-) Sincerely, Sandro _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Mon Dec 25 13:51:21 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBPDpLo11655 for vsta-xplod; Mon, 25 Dec 2000 13:51:21 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBPDpIi11648; Mon, 25 Dec 2000 13:51:18 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA18965; Mon, 25 Dec 2000 14:02:58 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012252202.OAA18965@vandys-pc.zendo.com> To: major@chaoticdreams.org cc: vsta@zendo.com Subject: Re: Performance In-reply-to: Your message of "Mon, 25 Dec 2000 13:54:08 PST." <20001225135408.I3853@chaoticdreams.org> Date: Mon, 25 Dec 2000 14:02:58 -0800 From: Andy Valencia [major@chaoticdreams.org writes:] >You can simulate this aspect under Linux to some extent by setting the +S >*attribute* on a directory, not to be confused with the +s *mode* on >directory. >See lsattr(1), chattr(1) There might even be a mount option (-o sync in the BSD world is pretty close). >> I'm not sure since I don't know what the last file was. I'll try creating my >> own tarred, gzipped files and see what happens. The curious thing is, it >> only happens sometimes. If, as the previous person mentioned, it's because >> of an EOF on the pipe, then it would happen for every pipe, but it doesn't. >> It just happens on the larger archives. I'll do a little more testing. >Quite to the contrary, this happens "once in a while" Linux as well .. though >not very often all in all. It's still can occure and it's still fairly >harmless. Good to know it's not just cranky microkernels which run into such things! :-> Andy Valencia From daemon Mon Dec 25 15:40:06 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBPFe6B11788 for vsta-xplod; Mon, 25 Dec 2000 15:40:06 GMT Received: from hotmail.com (f149.law3.hotmail.com [209.185.241.149]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBPFe4i11768 for ; Mon, 25 Dec 2000 15:40:04 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2000 15:51:45 -0800 Received: from 64.229.99.222 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 25 Dec 2000 23:51:45 GMT X-Originating-IP: [64.229.99.222] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Performance Date: Mon, 25 Dec 2000 18:51:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Dec 2000 23:51:45.0650 (UTC) FILETIME=[A37B6D20:01C06ECD] >Quite to the contrary, this happens "once in a while" Linux as well .. >though >not very often all in all. It's still can occure and it's still fairly >harmless. Well, it's completely reproducible with the same archive. So it's not 'once in awhile' if it's reproducible. I'll grant that it happens under Linux as well, but my concern was the frequency with which it was ocurring under VSTa. Broken pipes were appearing in many places as I'd mentioned(ie. when compiling, untarring and gunzipping, etc.), so I thought it might be a problem. But if it's harmless, as some of you have said, then I'll leave it at that. I'm still wondering where they're all coming from though... Thanks for your help. :-) Sincerely, Sandro _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Tue Dec 26 10:24:42 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBQAOgP13377 for vsta-xplod; Tue, 26 Dec 2000 10:24:42 GMT Received: from web11503.mail.yahoo.com (web11503.mail.yahoo.com [216.136.172.35]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id eBQAOai13357 for ; Tue, 26 Dec 2000 10:24:37 GMT Message-ID: <20001226183625.7690.qmail@web11503.mail.yahoo.com> Received: from [24.94.103.37] by web11503.mail.yahoo.com; Tue, 26 Dec 2000 10:36:25 PST Date: Tue, 26 Dec 2000 10:36:25 -0800 (PST) From: James Northrup Subject: Re: Performance To: vsta@zendo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii a couple of years ago I had tried my own subjective speed test against a linux 2.0.x system on a Cyrix 233w/128 megs, VSTA on vstafs, and the hurd. A couple of years before that I performed the same subjective speed test on vsta vs. a linux 1.2 system, using a dx2-66 w/16 megs. My benchmark in both occasions was tarring+gzipping and building various gnu utils packages as the libc would permit. Subjectively, the vsta+vstafs vs the linux 1.2 was astonishing on the side of vsta. I had guessed a margin of around 33% faster either by the vsta simplified include paths and/or the shared page behavior that was not quite dialed into Linux at the time. gzip throughput seemed noticably faster on vsta; however disc commit operations under vsta were noticably less optimized. the 2.0 test vs its contemporary vsta was certainly a closer match but I just happened to love the immediate "feel" of the vsta shell and its response characteristics. I recall nothing noteworthy regarding the hurd in my second round of experimenting. --- Sandro Magi wrote: > >Quite to the contrary, this happens "once in a while" Linux as > well .. > >though > >not very often all in all. It's still can occure and it's still > fairly > >harmless. > > Well, it's completely reproducible with the same archive. So it's > not 'once > in awhile' if it's reproducible. I'll grant that it happens under > Linux as > well, but my concern was the frequency with which it was ocurring > under > VSTa. > > Broken pipes were appearing in many places as I'd mentioned(ie. > when > compiling, untarring and gunzipping, etc.), so I thought it might > be a > problem. But if it's harmless, as some of you have said, then > I'll leave it > at that. I'm still wondering where they're all coming from > though... > > Thanks for your help. :-) > > Sincerely, > Sandro > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > . > p://www.hotmail.com. > > . > __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From daemon Wed Dec 27 02:27:25 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBR2RPQ14732 for vsta-xplod; Wed, 27 Dec 2000 02:27:25 GMT Received: from finch-post-12.mail.demon.net ([194.217.242.41]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBR2RKN14712 for ; Wed, 27 Dec 2000 02:27:21 GMT Received: from humbug.demon.co.uk ([158.152.11.229]) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 14BDz6-000Lmo-0C; Wed, 27 Dec 2000 10:39:04 +0000 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id KAA00780; Wed, 27 Dec 2000 10:34:58 GMT Sender: dave@humbug.demon.co.uk Message-ID: <3A49C5B3.7A0D7C1C@humbug.demon.co.uk> Date: Wed, 27 Dec 2000 10:34:27 +0000 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: James Northrup CC: vsta@zendo.com Subject: Re: Performance References: <20001226183625.7690.qmail@web11503.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi James, James Northrup wrote: > > My benchmark in both occasions was tarring+gzipping and building > various gnu utils packages as the libc would permit. > > Subjectively, the vsta+vstafs vs the linux 1.2 was astonishing on > the side of vsta. I had guessed a margin of around 33% faster > either by the vsta simplified include paths and/or the shared page > behavior that was not quite dialed into Linux at the time. If memory serves I think there are 3 points here (and please excuse me if any of this is now incorrect as I don't have any recent sources handy and it's a while since I spent a lot of time in the kernel): 1) VSTa is still running with an old version of gcc - Linux has been continuing apace with the latest and greatest optimizing versions and that will certainly have made a big impact. I spent a lot of time looking at what code generation worked best for different 386, 486 (single, double and triple clocked) and Pentium systems about 5 years ago and there were huge gains (in some code sequences a factor of 2) if the code sequencing was correct for the specific CPU being used. 2) Wherever there is significant messaging traffic there's quite a hit. I suspect there's a factor of 2 still waiting to be extracted from the message passing code given some judicious use of assembly code. With Linux someone will tend to optimize these sorts of things quite quickly. 3) VSTa's page mapping is both a blessing and a curse - when doing things like the pipe server where there are 4k pages being moved about it is without doubt the fastest way to go. If messages get smaller (e.g. less than 500 bytes say) then the cost of the page mapping will often be greater than the cost of simply copying the data (TLB misses, TLB thrashing, etc). Block oriented operations will do very well with page mapping whilst ops that don't work this way will be slower. Regards, Dave From daemon Wed Dec 27 08:23:24 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBR8NOt15076 for vsta-xplod; Wed, 27 Dec 2000 08:23:24 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id eBR8NJN15069; Wed, 27 Dec 2000 08:23:19 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA03349; Wed, 27 Dec 2000 08:35:05 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200012271635.IAA03349@vandys-pc.zendo.com> To: Dave Hudson cc: vsta@zendo.com Subject: Re: Performance In-reply-to: Your message of "Wed, 27 Dec 2000 10:34:27 GMT." <3A49C5B3.7A0D7C1C@humbug.demon.co.uk> Date: Wed, 27 Dec 2000 08:35:05 -0800 From: Andy Valencia [Dave Hudson writes:] >1) VSTa is still running with an old version of gcc Actually, I ported a much newer one a while back (well, newer than the one I remember Dave wrestling with when he was doing performance work, anyway). And then I actually did "most" of a port of whatever was latest as of a couple months ago. But I'm pretty sure we're enjoying the benefits of a reasonably modern gcc anyway. >2) Wherever there is significant messaging traffic there's quite a hit. >... >3) VSTa's page mapping is both a blessing and a curse Both true. But in the context of the performance tests discussed in this thread, I bet a lot more performance can be gained from filesystem and disk I/O issues than from messaging path CPU cycles. Andy Valencia From daemon Wed Dec 27 08:24:41 2000 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBR8OfK15103 for vsta-xplod; Wed, 27 Dec 2000 08:24:41 GMT Received: (from root@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id eBR8Ocs15082; Wed, 27 Dec 2000 08:24:38 GMT Message-Id: <200012271521.eBRFL9h09029@lima.md.photuris.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: broken pipes (was Re: Performance) Date: Wed, 27 Dec 2000 10:24:06 -0500 From: James da Silva Sandro writes: > Broken pipes were appearing in many places as I'd mentioned(ie. when > compiling, untarring and gunzipping, etc.), so I thought it might be a > problem. But if it's harmless, as some of you have said, then I'll leave it > at that. I'm still wondering where they're all coming from though... Pardon this intrusion from the peanut gallery (I don't actually run vsta, I just lurk) but I have some general points that I haven't seen raised yet: A ``broken pipe'' error comes when the writer writes to a pipe that has already been closed by the other end. In this case the writer is most likely the gzip spawned by tar, and the reader is tar. So most likely tar is seeing an eof marker within the data before the data stream is actually exhausted and is closing its end before gzip has finished fully writing the last block. The explanation could be as simple as tar not being compiled with the same default block size on the system where the file was created. Or if not that, it may be that vsta's scheduler is more agressive: rather than letting gzip run for a while as a unix system would it passes control to tar as soon as partial pipe write is complete (just another guess). I suggest playing with tar options: try -B (reblock input), -i (ignore zeros as eof marker) and/or -b N (to change the expected block size). If these work then you don't have an OS problem, but maybe tar should be compiled differently. Cheers, Jaime ........................................................................... : James da Silva : Stand on my shoulders, : : at work : not on my toes. : From daemon Wed Jan 3 09:47:16 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f039lGc29474 for vsta-xplod; Wed, 3 Jan 2001 09:47:16 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f039lCN29467 for ; Wed, 3 Jan 2001 09:47:12 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA18098 for ; Wed, 3 Jan 2001 09:59:18 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200101031759.JAA18098@vandys-pc.zendo.com> To: vsta@zendo.com Subject: Request for comments Date: Wed, 03 Jan 2001 09:59:18 -0800 From: Andy Valencia Two things have come up recently with VSTa. First, I've been looking at getting GNU's "configure" to work properly on VSTa. I've ported various little missing shell tools, and ended up realizing that the current Bourne shell we're using is a little down-rev from what's required by autoconfig. So I grabbed a later FreeBSD "ash", and ported it over. Bleah. The current one is shy of 60k of code. The new, improved one is almost 200k. And yet with this footprint, it lacks things like filename completion, and yet has to carry its own input line editing code (it actually uses a "libedit" library, which I also ported). I'm now tending to think that I should just address the buglets in the current port of the shell, rather than bring in such gratuitous bloat. Comments? The other interesting thing is a long-standing bug in VSTa based on my lack of appreciation for the treatment of file positions. Quick quiz for you UNIX experts... is it possible for one process to change the file position of an open file of another process? If you're like me, you quickly say "no way... the whole point of process boundaries is to insulate contexts". And yet on deeper reflection this is not at all true. Consider the trivial shell script: printf "Hi, Mom!\n" printf "Another line.\n" Now, if you run this interactive, you'll see one line following the other. On a TTY, "file position" doesn't mean much anyway. But if you run this shell script redirected to, say, "foo.sh > xx", what do you expect to see in file "xx" after the run? If you expect the two lines, then you're right, but think about what's actually going on. The shell itself has one open file descriptor to "xx". It fork()'s and then execv()'s to the first "printf" program, dup'ing the file descriptor. "printf" runs, and writes to the file "xx". Starting at what file position? 0, of course--that's the position of the file descriptor it inherited from the shell script. Now the key question. The first printf exits, and now the shell runs again. What position is its version of the file descriptor set to? If you believe in the insulation of processes, it'll still be at 0. But, in fact, its position must reflect the I/O of its child process, since otherwise when the second printf runs, it'll also write its output at position 0, right on top of the previous output. And this is what currently happens on VSTa! So I'm going to go back and do some rework on when distinct contexts should exist. dup()/dup2() already work right, it's only the behavior of a fork() which needs to be handled differently. It seems like there's going to need to be a distinction in the M_DUP message between fork()-type dup'ing and an actual clone() operation. More to come as I hack upon it. Regards, Andy Valencia From daemon Wed Jan 3 20:15:57 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f03KFvx00514 for vsta-xplod; Wed, 3 Jan 2001 20:15:57 GMT Received: from smtp4.mail.yahoo.com (smtp4.mail.yahoo.com [128.11.69.101]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f03KFqE00492 for ; Wed, 3 Jan 2001 20:15:53 GMT Received: from 103bus37.tampabay.rr.com (HELO yyz) (24.94.103.37) by smtp.mail.vip.suc.yahoo.com with SMTP; 4 Jan 2001 04:30:59 -0000 X-Apparently-From: From: "James Northrup" To: "Andy Valencia" , Subject: RE: Request for comments Date: Wed, 3 Jan 2001 23:30:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <200101031759.JAA18098@vandys-pc.zendo.com> I have no recommendation regarding ash and VSTA per se, and unfortunately I have a backlog of test OS's to run on finite test machines, thus I'm not running a VSTA box presently... I'm partial to bash, though; does it port to VSTA? What major readline and posixisms might we find absent in a VSTA port of bash? I have not messed with the restricted shell that bash can be configured to provide, but it seems to offer one. My $.02 [...] Two things have come up recently with VSTa. First, I've been looking at getting GNU's "configure" to work properly on VSTa. I've ported various little missing shell tools, and ended up realizing that the current Bourne shell we're using is a little down-rev from what's required by autoconfig. So I grabbed a later FreeBSD "ash", and ported it over. Bleah. The current one is shy of 60k of code. The new, improved one is almost 200k. And yet with this footprint, it lacks things like filename completion, and yet has to carry its own input line editing code (it actually uses a "libedit" library, which I also ported). I'm now tending to think that I should just address the buglets in the current port of the shell, rather than bring in such gratuitous bloat. Comments? [...] _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Wed Jan 3 20:33:19 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f03KXJ800557 for vsta-xplod; Wed, 3 Jan 2001 20:33:19 GMT Received: from ms1.mcps.k12.md.us (ms1.mcps.k12.md.us [205.222.0.40]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f03KXGE00537 for ; Wed, 3 Jan 2001 20:33:16 GMT Received: from fcgateway2.mcps.k12.md.us (fcgateway2.mcps.k12.md.us [205.222.0.94]) by ms1.mcps.k12.md.us (8.9.3/8.9.3) with ESMTP id XAA28581 for ; Wed, 3 Jan 2001 23:59:17 -0500 Message-id: Date: Wed, 03 Jan 2001 23:43:30 -0500 Subject: Re: Request for comments To: vsta@zendo.com From: "Eric Jacobs" References: <200101031759.JAA18098@vandys-pc.zendo.com> In-Reply-To: <200101031759.JAA18098@vandys-pc.zendo.com> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit vandys@zendo.com writes: >The other interesting thing is a long-standing bug in VSTa based on my >lack >of appreciation for the treatment of file positions. Quick quiz for you >UNIX experts... is it possible for one process to change the file position >of an open file of another process? The important thing to realize here is that open file objects are not associated with any particular process. They're independent. On the BSD man page for fork(2) this behavior is clearly spelled out. In Unix, a file descriptor is just a pointer to a system object - there's no "magic context" assoicated with it. (But I'm not a Unix expert ;) > > >If you're like me, you quickly say "no way... the whole point of process >boundaries is to insulate contexts". And yet on deeper reflection this is >not at all true. Consider the trivial shell script: I would say that the 90% of the point of IPC is to deal with objects that are shared across process boundaries. It is up to the server and clients to figure out how they're going to interact. The kernel shouldn't (and really can't) try to impose any policy of insulation. What does it mean to be "insulated", anyway? If two processes open the same file for writing, how should the kernel insulate them? It can't. It is the clients' responsibility to make sure they don't trample each other. Furthermore, the clients may _want_ to share the exact same object: and when the kernel does behind-the-back magic like VSTa is doing that can get in the way. It is also quite contrary to the spirit of microkernels (considering especially that the "big" Unix kernel does even less!) My suggestion is to let file descriptors be as in Unix: as simple references to objects, with no concept of owner. The kernel should do what only the kernel can do, which is to make sure that clients and servers can't illegally obtain file descriptors or manipulate each other except through the message interface. Everything within that message interface, however, is entirely up to the individual servers and clients to define, including behavior with multiple clients using the same object. > > printf "Hi, Mom!\n" > printf "Another line.\n" > >Now, if you run this interactive, you'll see one line following the other. >On a TTY, "file position" doesn't mean much anyway. But if you run this >shell script redirected to, say, "foo.sh > xx", what do you expect to see >in >file "xx" after the run? > >If you expect the two lines, then you're right, but think about what's >actually going on. The shell itself has one open file descriptor to "xx". >It fork()'s and then execv()'s to the first "printf" program, dup'ing the >file descriptor. "printf" runs, and writes to the file "xx". Starting at >what file position? 0, of course--that's the position of the file >descriptor it inherited from the shell script. You wouldn't expect the stdout of foo.sh's descendants to end up pointing to completely different objects unless explicitly redirected. > >Now the key question. The first printf exits, and now the shell runs >again. >What position is its version of the file descriptor set to? If you >believe >in the insulation of processes, it'll still be at 0. But, in fact, its >position must reflect the I/O of its child process, since otherwise when >the >second printf runs, it'll also write its output at position 0, right on >top >of the previous output. And this is what currently happens on VSTa! What's happening is the concept of "file object" is getting confused with that of "file context object" (which includes a file position.) A TTY-like object implements read and write. A file object implements absread and abswrite. A file context inherits from that, adding read, write and seek. So what's being passed to foo.sh is really a composite object: context object -> file object The problem is that while a context object interface is being presented to the script, VSTa is secretly copying the _contents_ of that context object, creating a new file descriptor variable in the process: context object \ > file object context object / Keep in mind that the shell script is expecting only a TTY- like object, consisting of read and write (actually only write, on stdout), and does not know anything about what's behind it. VSTa is performing a "shallow copy" of the this imaginary composite object: the problem is that the shell only knows the TTY interface, and has no idea that there is this complex scenario behind it. The key idea here is that the context (file pointer) is really just another object in the system. It is not guaranteed to be private to a process. So it is not like getting into someone else's address space. A process may choose whether or not to share it, of course. In the name of insulation, I wonder why VSTa doesn't do this: context object -> file object context object -> file object that is, "deep copy" the composite objects. When you run foo.sh > xx, _nothing_ appears in xx! That's because the descendents of foo.sh need to be "insulated" from foo.sh, and actually had their output redirected to two completely new, nameless files that were deleted immediately after they finished. Sure enough, when foo.sh checks out its file descriptor, it finds it exactly as it left it, immune to the other process's effects! Now that's insulation! Okay, I don't really wonder that :) My point is that sometimes multiple clients need to be working on exactly the same object, and it is in the user-defined client- server protocol that they decide how to do this and what the effects would be. > >So I'm going to go back and do some rework on when distinct contexts >should >exist. dup()/dup2() already work right, it's only the behavior of a >fork() >which needs to be handled differently. It seems like there's going to >need >to be a distinction in the M_DUP message between fork()-type dup'ing and >an >actual clone() operation. More to come as I hack upon it. I think that's the right way to go. Suppose that a process wanted its descendents to have their own file pointers. Then before it exec's the child process, it could do: (in imaginary pseudo-code): fd[1] = fd[1].getFileObject().newContext() This way the underlying structure is made explicit through the interface. This approach has an additional benefit: if the process is passed a file descriptor that refers to a real TTY that doesn't have a underlying file object, it is an error instead of just doing the wrong thing. The most direct way to implement this in VSTa would be to scratch M_DUP completely and attach the clone functionality as an optional FS_NEWCONTEXT message that is completely defined between the servers and the clients. From daemon Mon Jan 15 19:42:41 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0FJgfJ24704 for vsta-xplod; Mon, 15 Jan 2001 19:42:41 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0FJgUE24684 for ; Mon, 15 Jan 2001 19:42:31 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 11:57:37 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB71559E1@GERNT002> From: "Dines, Eric" To: "'Brett McCoy'" , Andy Valencia Cc: vsta@zendo.com Subject: RE: vsta under vmware Date: Tue, 16 Jan 2001 12:09:10 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I am still having trouble with VSTa under Vmware. Exactly the same problem identified by Brett (4/1/00), where grub seems to load everything but VSTa crashes with "Boot process 3 dies". Can anyone help. cheers Eric ------------------------------------------------------------------------- From daemon Sat Jan 20 06:50:45 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0K6ojm04905 for vsta-xplod; Sat, 20 Jan 2001 06:50:45 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0K6odE04885 for ; Sat, 20 Jan 2001 06:50:39 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Sat, 20 Jan 2001 23:05:44 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB71559F2@GERNT002> From: "Dines, Eric" To: "'vsta@zendo.com'" Cc: "'mirian@cosmic.com'" Subject: i386-aout-vsta cross-compilers Date: Sat, 20 Jan 2001 23:17:18 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" If anyone has a set of pre built i386-aout-vsta binaries for running under Linux (or DJGPP) can they find it in their heart to post them on the web somewhere so that I can grab them? I have had no joy at all so far in trying to compile up several versions of 2.9; 2.7, and seem to be able to get the tarballs from GNU to fail in the most inexplicable of places; missing files etc. Muchas gracias Eric ------------------------------------------------------------------------- From daemon Sat Jan 20 08:44:58 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0K8iwX05054 for vsta-xplod; Sat, 20 Jan 2001 08:44:58 GMT Received: from cosmic.com (trantor.cosmic.com [209.58.189.187]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0K8itE05034 for ; Sat, 20 Jan 2001 08:44:55 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id LAA03700 for vsta@zendo.com; Sat, 20 Jan 2001 11:40:14 -0500 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: i386-aout-vsta cross-compilers Date: 20 Jan 2001 11:40:14 -0500 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 33 Message-ID: <94cf1e$3ji$1@trantor.cosmic.com> References: <3FC96A0BD509D411930500062950DFB71559F2@GERNT002> X-Trace: trantor.cosmic.com 980008814 3699 10.10.10.1 (20 Jan 2001 16:40:14 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article <3FC96A0BD509D411930500062950DFB71559F2@GERNT002>, Dines, Eric wrote: >If anyone has a set of pre built i386-aout-vsta binaries for running under >Linux (or DJGPP) can they find it in their heart to post them on the web >somewhere so that I can grab them? I've just put them on my web site. Go to http://www.cosmic.com/pub/vsta-tools/ In that directory you'll find 5 files: vsta-gcc-2.7.2.3-1.i386.rpm binary RPM for cross-gcc vsta-gcc-2.7.2.3-1.src.rpm source RPM for cross-gcc vsta-binutils-2.8.1-0.i386.rpm binary RPM for cross-binutils vsta-binutils-2.8.1-0.src.rpm source RPM for cross-binutils vsta-1.6.5-cross.patch patch to allow VSTa-1.6.5 to be cross-compiled under Linux To apply the patch, type patch -p2 < vsta-1.6.5-cross.patch in the same directory into which you have untarred vsta_src.tz. The patched sources can be compiled cross or natively. If you define the environment variable CROSS, it will do a cross-compile. If CROSS is not defined, then it will compile natively in the old manner. Let me know if you have any problems with it. cheers, --Mirian From daemon Sat Jan 20 09:25:11 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0K9PBH05157 for vsta-xplod; Sat, 20 Jan 2001 09:25:11 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0K9P7E05137 for ; Sat, 20 Jan 2001 09:25:07 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Jan 2001 01:40:25 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB71559F3@GERNT002> From: "Dines, Eric" To: "'mirian@cosmic.com'" , vsta@zendo.com Subject: RE: i386-aout-vsta cross-compilers Date: Sun, 21 Jan 2001 01:51:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" >>If anyone has a set of pre built i386-aout-vsta binaries for running under >>Linux (or DJGPP) can they find it in their heart to post them on the web >>somewhere so that I can grab them? >I've just put them on my web site. Go to > http://www.cosmic.com/pub/vsta-tools/ >The patched sources can be compiled cross or natively. If you define >the environment variable CROSS, it will do a cross-compile. If >CROSS is not defined, then it will compile natively in the old manner. You're a legend Mirian! Just one last request. Do you mind spelling out exactly how/where the CROSS env. variable should be defined please? Thanks again. Eric ------------------------------------------------------------------------- From daemon Sat Jan 20 10:44:58 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0KAiwl05273 for vsta-xplod; Sat, 20 Jan 2001 10:44:58 GMT Received: from cosmic.com (trantor.cosmic.com [209.58.189.187]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0KAisE05253 for ; Sat, 20 Jan 2001 10:44:54 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id NAA04359 for vsta@zendo.com; Sat, 20 Jan 2001 13:48:00 -0500 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: i386-aout-vsta cross-compilers Date: 20 Jan 2001 13:48:00 -0500 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 31 Message-ID: <94cmh0$485$1@trantor.cosmic.com> References: <3FC96A0BD509D411930500062950DFB71559F3@GERNT002> X-Trace: trantor.cosmic.com 980016480 4358 10.10.10.1 (20 Jan 2001 18:48:00 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article <3FC96A0BD509D411930500062950DFB71559F3@GERNT002>, Dines, Eric wrote: >>The patched sources can be compiled cross or natively. If you define >>the environment variable CROSS, it will do a cross-compile. If >>CROSS is not defined, then it will compile natively in the old manner. > >You're a legend Mirian! Gosh, I've never been called that before. >Just one last request. Do you mind spelling out exactly how/where the CROSS >env. variable should be defined please? You can either set it in your shell; for bash, it would be export CROSS=1 for csh, it would be setenv CROSS 1 or else, you can specify it right on the make command line: cd vsta/src/os/make make CROSS=1 vsta It doesn't matter what value you give it so long as it's defined. One thing I forgot to mention is that you absolutely need GNU make after applying my patch. On a Linux system, GNU make is the default make anyway, so you're all set, but when you go back to your VSTa system, you'll need to invoke make as "gmake". cheers, --Mirian From daemon Sat Jan 20 20:53:17 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0KKrH705897 for vsta-xplod; Sat, 20 Jan 2001 20:53:17 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f0KKrCE05890; Sat, 20 Jan 2001 20:53:12 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id VAA29037; Sat, 20 Jan 2001 21:09:01 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200101210509.VAA29037@vandys-pc.zendo.com> To: mirian@cosmic.com (Mirian Crzig Lennox) cc: vsta@zendo.com Subject: Re: i386-aout-vsta cross-compilers In-reply-to: Your message of "20 Jan 2001 11:40:14 EST." <94cf1e$3ji$1@trantor.cosmic.com> Date: Sat, 20 Jan 2001 21:09:01 -0800 From: Andy Valencia [mirian@cosmic.com (Mirian Crzig Lennox) writes:] >>If anyone has a set of pre built i386-aout-vsta binaries for running under >>Linux (or DJGPP) can they find it in their heart to post them on the web >>somewhere so that I can grab them? >I've just put them on my web site. >... I've mirrored this to: ftp://ftp.vsta.org/vsta/pickup/cross-linux Thanks for providing this, and please let me know any time I need to update them. BTW, I still have your patches in the queue, but haven't figured out how to reconcile them with the native source yet. The biggest hassle is avoiding GNU make extensions. Still... I'll get there! Andy From daemon Wed Jan 24 13:56:22 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f0ODuMJ12179 for vsta-xplod; Wed, 24 Jan 2001 13:56:22 GMT Received: from localhost.zendo.com (localhost.zendo.com [127.0.0.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f0ODuIE12170 for ; Wed, 24 Jan 2001 13:56:18 GMT Message-Id: <200101241356.f0ODuIE12170@bodhi.zendo.com> X-Authentication-Warning: bodhi.zendo.com: localhost.zendo.com [127.0.0.1] didn't use HELO protocol To: vsta@zendo.com Subject: VSTa 1.6.6 released Date: Wed, 24 Jan 2001 13:56:17 +0000 From: Andy Valencia Please find in ftp://ftp.vsta.org/vsta/vsta_166 the 1.6.6 release of VSTa. I've attached my notes on what I *think* is in this release. :-> Note that I dodged a couple bullets on this release. While doing regression testing on my old DOS 3.1 tower system I ran into a latent bug in 8.3 filename compatibility, as well as a much bigger bug in the new > 4gig disk support. But all of that is resolved (he said hopefully) and I hope you'll all find this release less of a bumpy ride than 1.6.5. Enjoy, Andy Valencia ========================================== Added FS_BLK{READ,WRITE} operations to support true sector-oriented I/O. Offsets and counts are in units of 512-byte sectors, and thus the 4 gigabyte offset limit of byte-oriented I/O is avoided. vsta/src/lib/abc.c uses this, and falls back to the old I/O primitives if it finds these not supported. For now, IDE supports it. Filename completion is available in the shell. TBD... right now it's a separate plug-in from libusr.a; should it be made a part of getline()? When should it be active versus the regular tab expansion function? TTY state (vsta/src/lib/tty.c) is now per-TTY. Added "dev" FS_STAT parameter to the console server, also fixed a bug where interrupts didn't clear typeahead. Fixed shift key rollover--if you hold one shift, then the other, then release the first, you'll still be shifted until you release the final key. Converted current regexp package to use libregexp.a (note the new 'p'). This is made possible by long filenames in VFAT, and makes room for... Ported POSIX libregex.a package. Ported BSD's expr. Added lots more details on how to implement select() in a server. See /vsta/doc/select.txt RS-232 server now supports select(). Fix output positioning so things like "make > make.log" now give you usable output. Fixed some latent race conditions in port duplication messaging. Made the shell use wait.h macros; non-zero exits don't get listed as signal terminations now. Shell doesn't hang on pipe when doing some types of here documents. Add some options to kill, and convert to getopt(). Create aliases for awk (=gawk), egrep/fgrep (=grep), [ (=test). We still have cc (=gcc). hostname(1) emulated in shell script using uname. Fix long-standing latent bug in "fstab" with no arguments. Ported vim-5.7... multiple edit buffers, filename completion, lotsa good stuff. The new one is more than 3x the size of the old one, though, so I'm going to keep the old one available for now as "ovim". access(2) for W_OK doesn't change the file's mtime any more. Since the output positioning fix spares us needing to do clone() operations on each fork(), I've decided to live it up and have /vsta/bin mounted as /bin as a standard configuration. This means standard shell scripts which start with #!/bin/sh will now work, too. Ported file utility. Fixed up libgcc.a so it holds all the functions needed for floats, doubles, and long longs. Port of dosfsck... native filesystem checking of DOS filesystems Fix DLL loader so short filename conversion always works (missing null termination) Fix MGR's startup so it gives a clear message and exits when it can't attach to the mouse. From daemon Thu Feb 1 22:01:23 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f11M1Nn04376 for vsta-xplod; Thu, 1 Feb 2001 22:01:23 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f11M14E04368; Thu, 1 Feb 2001 22:01:04 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id WAA21923; Thu, 1 Feb 2001 22:17:29 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102020617.WAA21923@vandys-pc.zendo.com> To: "Nymia" cc: vsta@zendo.com Subject: Welcome In-reply-to: Your message of "Thu, 01 Feb 2001 22:07:08 PST." <003501c08cde$60c31580$8957e1cf@home> Date: Thu, 01 Feb 2001 22:17:29 -0800 From: Andy Valencia ["Nymia" writes:] >I downloaded the latest (1.6.6) and was able to boot it using grub. Cool! Glad it worked OK for you. >No major problems encountered so far. That's because I haven't tried running >MGR yet and played around the filesystem. > >I was wondering if anybody would give some comments or opinions about >application servers. From what I gathered, BeOS and AtheOS has application >servers and it seems to work very well in that environment. Would an >application server be good on the VSTa environment as well? I don't know what an application server is. Or, rather, I can imagine this in a web farm environment, but not how it relates back to basic OS mechanisms. >I was also thinking about about loopers and (un)lockers. Does VSTa have a >mechanism of locking a resource? And loopers for processes or threads that >continuously loop for events/messages? There are IPC primitives which are used to implement an event loop for a server. There are spinlocks, and also a semaphore server, and also a simple P/V mutex mechanism for use between threads. Recall that in VSTa, the kernel doesn't have much to do with resources (except for CPU cycles and memory bytes in their rawest form). Each server is accessed as a filesystem, and represents its services (and their underlying resourcse) as file nodes within this hierarchy. There's a bunch of protocol which exists by convention between filesystem servers and their clients... but this framework is very extensible, especially the FS_STAT and FS_WSTAT messages for reading and initiating actions on attributes of filesystem objects. You may want to read the code for a simple filesystem, like the semaphore one or perhaps the RAM-based /tmp filesystem. They're in /vsta/src/srv, and /tmp in particular is pretty representative of how a server acts as a filesystem. Regards, Andy Valencia From daemon Thu Feb 1 22:41:39 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f11Mfdw04435 for vsta-xplod; Thu, 1 Feb 2001 22:41:39 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f11MfaE04415 for ; Thu, 1 Feb 2001 22:41:36 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 14:58:09 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB73C1B04@GERNT002> From: "Dines, Eric" To: "'vsta@zendo.com'" Cc: "'mirian@cosmic.com'" Subject: genassym.c etc. with non-VSTa gcc Date: Fri, 2 Feb 2001 15:10:08 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Does anyone (Mirian?) have time to explain why genassym and genfctl are compiled with gcc and not the cross compiler when compiling on Linux? Why do things work out OK with the native compiler? many thanks Eric ------------------------------------------------------------------------- From daemon Fri Feb 2 06:43:35 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f126hZf05110 for vsta-xplod; Fri, 2 Feb 2001 06:43:35 GMT Received: from cosmic.com (trantor.cosmic.com [209.58.189.187]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f126hUE05090 for ; Fri, 2 Feb 2001 06:43:30 GMT Received: (from news@localhost) by cosmic.com (8.9.3/8.9.3) id JAA04188 for vsta@zendo.com; Fri, 2 Feb 2001 09:13:47 -0500 X-Authentication-Warning: trantor.cosmic.com: news set sender to using -f From: mirian@cosmic.com (Mirian Crzig Lennox) X-Newsgroups: cosmic.vsta Subject: Re: genassym.c etc. with non-VSTa gcc Date: 2 Feb 2001 09:13:47 -0500 Organization: Cosmic Computing Corporation of Alpha Centauri Lines: 13 Message-ID: <95efar$42q$1@trantor.cosmic.com> References: <3FC96A0BD509D411930500062950DFB73C1B04@GERNT002> X-Trace: trantor.cosmic.com 981123227 4187 10.10.10.1 (2 Feb 2001 14:13:47 GMT) X-Complaints-To: news@trantor.cosmic.com To: vsta@zendo.com In article <3FC96A0BD509D411930500062950DFB73C1B04@GERNT002>, Dines, Eric wrote: >Does anyone (Mirian?) have time to explain why genassym and genfctl are >compiled with gcc and not the cross compiler when compiling on Linux? >Why do things work out OK with the native compiler? These programs are pre-processors; they only exist to generate C source code from other data as part of the build process. Therefore, they have to be compiled to run on the host system, NOT the target system. After the VSTa kernel has been built, they are no longer used. cheers, --Mirian From daemon Tue Feb 6 07:37:18 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f167bII15089 for vsta-xplod; Tue, 6 Feb 2001 07:37:18 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f167bCE15069 for ; Tue, 6 Feb 2001 07:37:12 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f16FtTs20507 for ; Tue, 6 Feb 2001 16:55:29 +0100 Date: Tue, 6 Feb 2001 16:55:29 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: 3c509 driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My friend has just "finished" a driver for the 3c509 network card (Etherlink III). It can be found at: http://www.jpl.nu/~erik/3c509.tar.gz /Erik Kristoffer's notes: To use it with ka9q you have to change from net/ne:0 to net/el3:0 in geneth.c. Also, I had to do my own repoutsl and repinsl functions. They are at the bottom of el3.h. Maybe they should be added to the system? for other info, read the release notes in the archive. From daemon Tue Feb 6 14:28:27 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f16ESR015682 for vsta-xplod; Tue, 6 Feb 2001 14:28:27 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f16ERwE15673; Tue, 6 Feb 2001 14:28:03 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA13087; Tue, 6 Feb 2001 14:44:10 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102062244.OAA13087@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: 3c509 driver In-reply-to: Your message of "Tue, 06 Feb 2001 16:55:29 +0100." Date: Tue, 06 Feb 2001 14:44:10 -0800 From: Andy Valencia [Erik Dalen writes:] >My friend has just "finished" a driver for the 3c509 network card >(Etherlink III). It can be found at: http://www.jpl.nu/~erik/3c509.tar.gz Awesome! Looks like KA9Q should start taking some sort of argument to specify which LAN interface to use. Needless to say, this'll be folded into the next release. Andy Valencia From daemon Fri Feb 9 11:12:12 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f19BCCp21925 for vsta-xplod; Fri, 9 Feb 2001 11:12:12 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f19BC7E21917 for ; Fri, 9 Feb 2001 11:12:08 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id LAA27364 for ; Fri, 9 Feb 2001 11:28:54 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102091928.LAA27364@vandys-pc.zendo.com> To: vsta@vsta.org Subject: Java port to VSTa? Date: Fri, 09 Feb 2001 11:28:54 -0800 From: Andy Valencia Does anybody out there have a Java SDK port to VSTa? I know the current one is burdened under Sun's licenses, but I think the older ones might have had source access available. Or a port of a non-Sun Java environment would be OK, too. If nobody has something I may go ahead and port Kaffe with Kjc, but my primary interest is doing stuff in Java, not dealing with the Java tools themselves. Thanks, Andy Valencia From daemon Fri Feb 9 12:04:41 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f19C4fE22091 for vsta-xplod; Fri, 9 Feb 2001 12:04:41 GMT Received: from hotmail.com (f75.law3.hotmail.com [209.185.241.75]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f19C4bE22071 for ; Fri, 9 Feb 2001 12:04:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Feb 2001 12:21:21 -0800 Received: from 128.100.8.117 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 09 Feb 2001 20:21:21 GMT X-Originating-IP: [128.100.8.117] From: "Sandro Magi" To: vsta@vsta.org Subject: Re: Java port to VSTa? Date: Fri, 09 Feb 2001 15:21:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2001 20:21:21.0479 (UTC) FILETIME=[DDE44D70:01C092D5] >Does anybody out there have a Java SDK port to VSTa? I know the current >one >is burdened under Sun's licenses, but I think the older ones might have had >source access available. Or a port of a non-Sun Java environment would be >OK, too. If nobody has something I may go ahead and port Kaffe with Kjc, >but my primary interest is doing stuff in Java, not dealing with the Java >tools themselves. If you're just interested in doing Java stuff(without license hassles), how about GCJ then? http://gcc.gnu.org/java It's under the GPL with the libgcc extensions(according to the FAQ). It can compile Java source programs into Java bytecode or native machine code, so it seems quite flexible. I guess the only issue is completeness. I don't think it supports full AWT yet, though that shouldn't be an issue anyway since VSTa wouldn't be able to take advantage of it yet(would it?). I just checked Kaffe's site and the new release boasts preliminary GCJ integration. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Fri Feb 9 19:22:16 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f19JMGL22692 for vsta-xplod; Fri, 9 Feb 2001 19:22:16 GMT Received: from smtp6.mail.yahoo.com (smtp6.mail.yahoo.com [128.11.69.103]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f19JMEE22672 for ; Fri, 9 Feb 2001 19:22:14 GMT Received: from 103bus37.tampabay.rr.com (HELO yyz) (24.94.103.37) by smtp.mail.vip.suc.yahoo.com with SMTP; 10 Feb 2001 00:52:54 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: Java port to VSTa? -- tangent Date: Fri, 9 Feb 2001 19:52:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: Not to stray the topic at all... but... I have considered vsta ripe with opportunity to operate as a dedicated java workstation. My experience with low-power old sparcs with fast framebuffers and pathetic cpu's has shaped my conception of a vsta NC-like device (or any other platform for that matter.). I have adequate success using VNC to develop java from old sun4c workstations remotely connecting to my windows and linux servers. While I am involved presently with a startup, and can't devote much time to learning and hacking device drivers, opengl ports, jdk ports, etc. I have some ideas I'm putting down on paper for some future retirement date wherein I can take up such heartfelt pursuits. I still hold vsta in my mind as the ideal kernel platform with which to produce low-overhead remote desktop environments, and I have seen underwhelming CPU's pushing fantastic opengl displays with some reasonably low-cost voodoo banshee cards ($25). I also have yet to see a successful texture mapped window manager running X11/vnc displays with xy + Z! layout management and realtime updates. Meanwhile contemporary video cards are dumping gobs of heat and voltage at insane clock rates to perform essentially what an old paradise VGA card performs in 2d. My idea is to form a working discussion group and contribute occasional weekend to distributed protocol and driver development. Coming soon to a sourceforge near you... [...] AARDVARK -AbstrAct Remote Display Virtual Aperture Kernel This project will lay the groundwork for a middleware display layer to integrate many machines onto many virtual desktops using a network and hardware abstraction layer. This project will also attempt to integrate VNC's RFB protocol or develop an analog which will provide rendering primitives for a 3d panel management environ which allows a 3d rendering of the user's 2-d mouse/keyboard/audio interfaces. The goal is to provide encrypted, compressed, optimized, WAN and LAN quality remote rendering and sharing of collections of workstations and servers and the various window interfaces of X11, Win32, and Java/2d/3d/jfc api's. [...]resume original topic... -----Original Message----- From: Sandro Magi [mailto:naasking@hotmail.com] Sent: Friday, February 09, 2001 3:21 PM To: vsta@vsta.org Subject: Re: Java port to VSTa? >Does anybody out there have a Java SDK port to VSTa? I know the current >one >is burdened under Sun's licenses, but I think the older ones might have had >source access available. Or a port of a non-Sun Java environment would be >OK, too. If nobody has something I may go ahead and port Kaffe with Kjc, >but my primary interest is doing stuff in Java, not dealing with the Java >tools themselves. If you're just interested in doing Java stuff(without license hassles), how about GCJ then? http://gcc.gnu.org/java It's under the GPL with the libgcc extensions(according to the FAQ). It can compile Java source programs into Java bytecode or native machine code, so it seems quite flexible. I guess the only issue is completeness. I don't think it supports full AWT yet, though that shouldn't be an issue anyway since VSTa wouldn't be able to take advantage of it yet(would it?). I just checked Kaffe's site and the new release boasts preliminary GCJ integration. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Sat Feb 10 06:50:24 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1A6oOk25820 for vsta-xplod; Sat, 10 Feb 2001 06:50:24 GMT Received: from hotmail.com (f257.law3.hotmail.com [209.185.240.30]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1A6oJE25800 for ; Sat, 10 Feb 2001 06:50:19 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 10 Feb 2001 07:07:09 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 10 Feb 2001 15:07:08 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@vsta.org Subject: RE: Java port to VSTa? -- tangent Date: Sat, 10 Feb 2001 10:07:08 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Feb 2001 15:07:09.0167 (UTC) FILETIME=[237387F0:01C09373] >Not to stray the topic at all... but... I have considered vsta ripe with >opportunity to operate as a dedicated java workstation. My experience with >low-power old sparcs with fast framebuffers and pathetic cpu's has shaped >my >conception of a vsta NC-like device (or any other platform for that >matter.). > >I have adequate success using VNC to develop java from old sun4c >workstations remotely connecting to my windows and linux servers. > >While I am involved presently with a startup, and can't devote much time to >learning and hacking device drivers, opengl ports, jdk ports, etc. I have >some ideas I'm putting down on paper for some future retirement date >wherein >I can take up such heartfelt pursuits. > >I still hold vsta in my mind as the ideal kernel platform with which to >produce low-overhead remote desktop environments, and I have seen >underwhelming CPU's pushing fantastic opengl displays with some reasonably >low-cost voodoo banshee cards ($25). > >I also have yet to see a successful texture mapped window manager running >X11/vnc displays with xy + Z! layout management and realtime updates. >Meanwhile contemporary video cards are dumping gobs of heat and voltage at >insane clock rates to perform essentially what an old paradise VGA card >performs in 2d. > >My idea is to form a working discussion group and contribute occasional >weekend to distributed protocol and driver development. > >Coming soon to a sourceforge near you... > >[...] >AARDVARK -AbstrAct Remote Display Virtual Aperture Kernel > >This project will lay the groundwork for a middleware display layer to >integrate many machines onto many virtual desktops using a network and >hardware abstraction layer. > >This project will also attempt to integrate VNC's RFB protocol or develop >an >analog which will provide rendering primitives for a 3d panel management >environ which allows a 3d rendering of the user's 2-d mouse/keyboard/audio >interfaces. > >The goal is to provide encrypted, compressed, optimized, WAN and LAN >quality >remote rendering and sharing of collections of workstations and servers and >the various window interfaces of X11, Win32, and Java/2d/3d/jfc api's. > >[...]resume original topic... If you're looking for a network transparent windowing environment with incredible 2-D capabilities you should check out Berlin(http://www.berlin-consortium.org) It's a new vector based window system developed from scratch and built on CORBA and GGI(http://www.ggi-project.org). GGI also forms the base graphics library for the 3-D window manager project(http://www.3dwm.org). Berlin is currently being developed in C++. I believe they also have plans to integrate other media into the transport model so they can network transparent audio and video, but I'm not sure. You'd have to check out the mailing lists. Hope that's what you were looking for. No sense starting from scratch if you can just help out. :-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 10 11:31:39 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1ABVd226195 for vsta-xplod; Sat, 10 Feb 2001 11:31:39 GMT Received: from hotmail.com (f5.law3.hotmail.com [209.185.241.5]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1ABVaE26175 for ; Sat, 10 Feb 2001 11:31:36 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 10 Feb 2001 11:48:26 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 10 Feb 2001 19:48:26 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@vsta.org Subject: directory listing problem Date: Sat, 10 Feb 2001 14:48:26 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Feb 2001 19:48:26.0517 (UTC) FILETIME=[6F22C450:01C0939A] When I 'cd /' and I type 'ls', it doesn't list the 'vsta' directory. It definitely exists though, since I can 'cd vsta'. I'm running VSTa on a FAT32 partition. Any idea what could be causing that? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 10 12:50:48 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1AComC26338 for vsta-xplod; Sat, 10 Feb 2001 12:50:48 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1ACokE26331; Sat, 10 Feb 2001 12:50:46 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id NAA02223; Sat, 10 Feb 2001 13:07:36 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102102107.NAA02223@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@vsta.org Subject: Re: directory listing problem In-reply-to: Your message of "Sat, 10 Feb 2001 14:48:26 EST." Date: Sat, 10 Feb 2001 13:07:35 -0800 From: Andy Valencia ["Sandro Magi" writes:] >When I 'cd /' and I type 'ls', it doesn't list the 'vsta' directory. It >definitely exists though, since I can 'cd vsta'. I'm running VSTa on a FAT32 >partition. Any idea what could be causing that? If you "cd /vsta" and "ls", do you get what you expected? You might want to do a "fstab" to see what's mounted where in your pathname space. This is version 1.6.6? Andy Valencia From daemon Sat Feb 10 13:55:27 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1ADtRR26482 for vsta-xplod; Sat, 10 Feb 2001 13:55:27 GMT Received: from hotmail.com (f56.law3.hotmail.com [209.185.241.56]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1ADtOE26462 for ; Sat, 10 Feb 2001 13:55:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 10 Feb 2001 14:12:15 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 10 Feb 2001 22:12:14 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: directory listing problem Date: Sat, 10 Feb 2001 17:12:14 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Feb 2001 22:12:15.0038 (UTC) FILETIME=[862295E0:01C093AE] >If you "cd /vsta" and "ls", do you get what you expected? Yep. It correctly lists all files and directories in /vsta so this doesn't look like a critical problem/bug. Neither 'ls' nor 'vls' displays all the correct entries on '/'. >You might want to do a "fstab" to see what's mounted where in your pathname >space. 'fstab' gives me the following: 1025 on / 6 on /env 1030 on /tmp 1027 on /dev/null 1025 on /bin >This is version 1.6.6? yes it is. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 10 15:05:33 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1AF5Xw26585 for vsta-xplod; Sat, 10 Feb 2001 15:05:33 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1AF5TE26578; Sat, 10 Feb 2001 15:05:30 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id PAA02554; Sat, 10 Feb 2001 15:22:20 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102102322.PAA02554@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: directory listing problem In-reply-to: Your message of "Sat, 10 Feb 2001 17:12:14 EST." Date: Sat, 10 Feb 2001 15:22:20 -0800 From: Andy Valencia ["Sandro Magi" writes:] >>If you "cd /vsta" and "ls", do you get what you expected? >Yep. It correctly lists all files and directories in /vsta so this doesn't >look like a critical problem/bug. Neither 'ls' nor 'vls' displays all the >correct entries on '/'. I don't know if you really want to debug it; personally, I'm curious. If you do, read on.... Go into /vsta/src/lib, do a "make libc_s.a", then "rm dir.o", edit makefile to add -g to CFLAGS, then do "make libc_s.a" again. This'll give you a static libc with -g information for the directory traversal routines. Now go over to /vsta/src/bin/cmds, do "make ls.o" and then: rm -f ls gcc -o ls ls.o /vsta/src/lib/libc_s.a This'll give you an "ls" which uses a static link of libc. More to the point, it picked up those debug symbols. Now when you do "gdb ls", you can do "b opendir" or "b readdir". Finally(!) you can do "r /" to run the ls, and then you can go digging into what the directory traversal routines are doing as they try to provide "ls" with the entries in the root of the filesystem. Seems like something funny's going on, and I'm guessing you can see what it is at the opendir/readdir level. Andy From daemon Sun Feb 11 03:45:27 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1B3jRL27538 for vsta-xplod; Sun, 11 Feb 2001 03:45:27 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1B3jME27518 for ; Sun, 11 Feb 2001 03:45:22 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1BC4Ep19279 for ; Sun, 11 Feb 2001 13:04:14 +0100 Date: Sun, 11 Feb 2001 13:04:14 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: Servers vs. Libs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all In the VSTa design methodology it says that "if you can put it in a library, put it in a library" and then "If you can put it in a server, put it in a server". But is it really preffered to put things that could be put in a server, in a library instead? Personally I think things that can be put in servers should be put in servers. The graphics is a good example, In plan9 it is in a server providing a device to write to. The programs don't need to be aware at all of which graphics hardware there is in the computer. But if it is put in a library instead, it can't be multiplexed (ala 8.5 and rio). But probably worse, you would have to code wrappers for the graphics library to each programming language you'd want to code graphics in. And for those that preffer coding graphics by calling functions instead of writing data to a device, a library for drawing that uses the device(server) could be coded. /Erik From daemon Sun Feb 11 06:52:17 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1B6qHP27754 for vsta-xplod; Sun, 11 Feb 2001 06:52:17 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1B6qCE27734 for ; Sun, 11 Feb 2001 06:52:12 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1BFBAD23395 for ; Sun, 11 Feb 2001 16:11:10 +0100 Date: Sun, 11 Feb 2001 16:11:10 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: New Homepages Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi all I've made a suggestion for new homepages at: http://www.jpl.nu/~erik/vsta/ They're kind of based on the old homepages so there's not that much new content. But I think they look much better and are easier to navigate. So if any of you guys have any comments on them I'd like to hear them. You probably have, as they have some small stuff that could be improved still, but I'll fix all soon :) Another suggestion (mostly to Andy) is that I become the new maintaner of the homepages. Then it would be easier to improve them even more and update them. Regards /Erik From daemon Sun Feb 11 12:06:51 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1BC6p828156 for vsta-xplod; Sun, 11 Feb 2001 12:06:51 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1BC6jE28149; Sun, 11 Feb 2001 12:06:46 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id MAA03853; Sun, 11 Feb 2001 12:23:38 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102112023.MAA03853@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: Servers vs. Libs In-reply-to: Your message of "Sun, 11 Feb 2001 13:04:14 +0100." Date: Sun, 11 Feb 2001 12:23:38 -0800 From: Andy Valencia [Erik Dalen writes:] >But is it really preffered to put things that could be put in a server, in >a library instead? It depends. But, generally, it takes less code and fewer cycles to invoke a service in a library rather than across a context switch to some other process. >Personally I think things that can be put in servers should be put in >servers. The graphics is a good example, In plan9 it is in a server >providing a device to write to. The programs don't need to be aware at all >of which graphics hardware there is in the computer. >But if it is put in a library instead, it can't be multiplexed (ala 8.5 >and rio). But probably worse, you would have to code wrappers for the >graphics library to each programming language you'd want to code graphics >in. >And for those that preffer coding graphics by calling functions instead of >writing data to a device, a library for drawing that uses the >device(server) could be coded. Except that almost every "serious" graphics program does the inevitable genesis to the point where it wants memory mapped access to the frame buffer. And I'm not really arguing much, since the MGR port could call the main mgr process the "graphics server", and then all clients are in their own address spaces. But, then, MGR is linked with svgalib to actually control the graphics card, so that's adopting the other rule. The other big question is state management. Multiplexing is one (thus, mgr has its own process). But even in a single client case, the complexity of state and requirements for cleanup (i.e., on a segv hardware needs to be un-programmed) might argue for a distinct process. Any rule can be applied in such a way that it doesn't make sense. I don't see any problem with your arguments. Andy Valencia From daemon Sun Feb 11 14:49:27 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1BEnR128414 for vsta-xplod; Sun, 11 Feb 2001 14:49:27 GMT Received: from smtp1.a2000.nl ([62.108.1.203]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1BEnNE28394 for ; Sun, 11 Feb 2001 14:49:24 GMT Received: from node10338.a2000.nl ([24.132.3.56] helo=system) by smtp1.a2000.nl with esmtp (Exim 2.02 #4) id 14S5ZT-0000fR-00 for vsta@vsta.org; Mon, 12 Feb 2001 00:06:19 +0100 From: "chefren" To: Date: Mon, 12 Feb 2001 00:06:18 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Java port to VSTa? -- tangent Priority: normal In-reply-to: References: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: On 9 Feb 01, at 19:52, James Northrup wrote: > Not to stray the topic at all... but... I have considered vsta ripe with > opportunity to operate as a dedicated java workstation. My experience with > low-power old sparcs with fast framebuffers and pathetic cpu's has shaped my > conception of a vsta NC-like device (or any other platform for that > matter.). I would be happy if this hardware platform would be chosen: http://www.thinknic.com/ Simply put, the idea is: CD in the box, boot, and it works. There is 64MB RAM available, 200MHz CPU and it costs $199. There are a few different efforts for this hardware platform. That can all be tried and compared easily. All software is open source. People are making webservers with it, routers, terminals and so on. +++chefren From daemon Sun Feb 11 18:47:59 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1BIlxB28734 for vsta-xplod; Sun, 11 Feb 2001 18:47:59 GMT Received: from hotmail.com (f235.law3.hotmail.com [209.185.241.235]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1BIltE28714 for ; Sun, 11 Feb 2001 18:47:55 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 11 Feb 2001 19:04:49 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 12 Feb 2001 03:04:49 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: directory listing problem Date: Sun, 11 Feb 2001 22:04:49 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2001 03:04:49.0293 (UTC) FILETIME=[8FB313D0:01C094A0] >I don't know if you really want to debug it; personally, I'm curious. If >you do, read on.... > >Go into /vsta/src/lib, do a "make libc_s.a", then "rm dir.o", edit makefile >to add -g to CFLAGS, then do "make libc_s.a" again. This'll give you a >static libc with -g information for the directory traversal routines. This part goes well. >Now go over to /vsta/src/bin/cmds, do "make ls.o" and then: > > rm -f ls > gcc -o ls ls.o /vsta/src/lib/libc_s.a At this point I run into a problem. gcc exits and pukes out this message: ls.o(.text+0xeb):undefined reference to cvt_id gcc: Internal Compiler error:program got fata signal 1 Any idea what happened? I also ran into another interesting problem. I was logged in as root and all the source files had rw capabilities for sys.sys, and nothing for anyone else(this is what I could interpret given my current knowledge of VSTa). So I tried editing the file, but as soon as I typed 'i' in vi to insert some text, it dropped into the debugger. I quit that and it returned me to the command line, but when I tried typing in commands, I just got 'error 22'(or something similar) as my only response. I'm guessing server that handles the disk or filesystem exited because of permission violation. Am I close? Wouldn't better behaviour be to simply deny writing out the file, or is this a symptom of a deeper problem/bug? Thanks for the help. :-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sun Feb 11 21:12:54 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1BLCsp28898 for vsta-xplod; Sun, 11 Feb 2001 21:12:54 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1BLCnE28891; Sun, 11 Feb 2001 21:12:50 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id VAA04417; Sun, 11 Feb 2001 21:29:43 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102120529.VAA04417@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: directory listing problem In-reply-to: Your message of "Sun, 11 Feb 2001 22:04:49 EST." Date: Sun, 11 Feb 2001 21:29:43 -0800 From: Andy Valencia ["Sandro Magi" writes:] >> rm -f ls >> gcc -o ls ls.o /vsta/src/lib/libc_s.a >At this point I run into a problem. gcc exits and pukes out this message: > ls.o(.text+0xeb):undefined reference to cvt_id > gcc: Internal Compiler error:program got fata signal 1 Hmmm, add "-lusr" to the end of the "gcc" command line. Or, actually, do a "make ls" first and see what *it* links in as auxiliary libraries. But I'm pretty sure it's "-lusr". >I also ran into another interesting problem. I was logged in as root and all >the source files had rw capabilities for sys.sys, and nothing for anyone >else(this is what I could interpret given my current knowledge of VSTa). So >I tried editing the file, but as soon as I typed 'i' in vi to insert some >text, it dropped into the debugger. I quit that and it returned me to the >command line, but when I tried typing in commands, I just got 'error 22'(or >something similar) as my only response. Did it say which process had died? I'm guessing DOS, since vim tries to create a checkpoint file when you first make a change. >I'm guessing server that handles the disk or filesystem exited because of >permission violation. Am I close? Wouldn't better behaviour be to simply >deny writing out the file, or is this a symptom of a deeper problem/bug? Yes, in the normal circumstance that's what happens (DOS filesystems don't have any actual protection labeling, so the VSTa DOS server acts as if everything is globally readable and only writable by sys.sys). Having the filesystem server barf usually means Something Bad. If you're on console 0 (the initial one) I'd be curious if a syslog message comes up saying something about it. Also, do a "tf" while in the kernel debugger, and see if it faulted on a segv, or trap type 255 (syscall)--i.e., a voluntary exit. You can also get a stack backtrace of the dying user process; see: http://www.vsta.org/mail/2/0020.html (Ignore the part about debug32--that's ancient history; but the stack backtrace collection still works.) If you get the program counter values, you can then go into /vsta/src/srv/dos, edit the makefile to have -g added to COPTS, do "make", and then you can gdb the executable and turn those PC values into source references. There's definitely something funny going on with your filesystem. I just can't guess what it is yet.... Andy Valencia From daemon Mon Feb 12 20:32:04 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1CKW4O00957 for vsta-xplod; Mon, 12 Feb 2001 20:32:04 GMT Received: from web11506.mail.yahoo.com (web11506.mail.yahoo.com [216.136.172.38]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1CKVxE00937 for ; Mon, 12 Feb 2001 20:31:59 GMT Message-ID: <20010213044901.65856.qmail@web11506.mail.yahoo.com> Received: from [24.94.103.37] by web11506.mail.yahoo.com; Mon, 12 Feb 2001 20:49:01 PST Date: Mon, 12 Feb 2001 20:49:01 -0800 (PST) From: James Northrup Subject: Fwd: RE: Java port to VSTa? -- tangent To: vsta@vsta.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2130938248-982039741=:63511" --0-2130938248-982039741=:63511 Content-Type: text/plain; charset=us-ascii ThinkNIC offers a fine system if a small linux box is your goal. What's next? First it was programming a VCR, now the trend is to put up a masquerading firewall server on the cable-modem. VCR coders came and went.. as T approaches infinity We'll all outlive our current pc's. we're likely to afford hdtv's somewhere along the way and a 266 mhz ia32 will be emulated by awfully compact microdevice(s) in the coming years. The PC's we're currently outliving already come with 3d accelerators, mpeg/dvd decoders, and digital PCM sound output, and generous helpings of RAM. Linux abides, oblivious. in the not too different future we'll be plugging our DVD players into systems like these because dolby 5.1 tuners are about 1000% more expensive than present day audio cards and video adapters. consider how overkill it is to have all this hardware, a 100mb network pipe, and a desktop display protocol that uses 2% of the bandwidth capacity on 2d widgets and panels with combinations of bitmap ops and text rendering. firewire provides 4 times this bandwidth. packets are cheap as water. For my purposes VSTA would serve fine as a high performance remote terminal; the missing components presently are a 3d space window manager, kernel remote display protocols suitable for high bandwidth or crypto+compression for insecure WAN links, and perhaps a bit of driver abstraction magic for the various mutlimedia chipsets and op-codes. also missing is the whole paradigm that escapes single-machine thinking. VSTA has (at least once upon a time) exported its namespace items across the network. add to this an elegant scheduler algorithm and the ease with which a linux driver might be hijacked and ported to vsta, its a very tempting platform for bus-intensive remote workstations. How do you really wish to address hundred of machines you need to operate and access regularly? a scene from Jurrassic park that comes to my mind, unlikely as it sounds, was of the little girl pointing and clicking her way through a 3d fly-through "unix system". someday sourceforge will acknowledge my project application :-) I will gladly discuss these matters in thier own setting when that happens. I originally started down the path of minimalist javaOS platform; though found it better to strive for a single remote workstation to the dozens of boring machine displays i interact with which run supported jvm's and heaps of horsepower and JIT's on platforms customers are demanding. > chefren wrote: > > On 9 Feb 01, at 19:52, James Northrup wrote: > > > Not to stray the topic at all... but... I have considered vsta > ripe with > > opportunity to operate as a dedicated java workstation. My > experience with > > low-power old sparcs with fast framebuffers and pathetic cpu's > has shaped my > > conception of a vsta NC-like device (or any other platform for > that > > matter.). > > I would be happy if this hardware platform would be chosen: > > http://www.thinknic.com/ > > > Simply put, the idea is: CD in the box, boot, and it works. > > There is 64MB RAM available, 200MHz CPU and it costs $199. > > > There are a few different efforts for this hardware > platform. That can all be tried and compared easily. All > software is open source. People are making webservers with > it, routers, terminals and so on. > > +++chefren > > > > > > > > > --------------------------------- > Do You Yahoo!? > - Get personalized email addresses from Yahoo! Mail Personal > Address - only $35 a year! --------------------------------- Do You Yahoo!? - Get personalized email addresses from Yahoo! Mail Personal Address - only $35 a year! --0-2130938248-982039741=:63511 Content-Type: text/html; charset=us-ascii ThinkNIC offers a fine system if a small linux box is your goal.

What's next? First it was programming a VCR, now the trend is to put up a masquerading firewall server on the cable-modem. VCR coders came and went.. as T approaches infinity We'll all outlive our current pc's. we're likely to afford hdtv's somewhere along the way and a 266 mhz ia32 will be emulated by awfully compact microdevice(s) in the coming years.

The PC's we're currently outliving already come with 3d accelerators, mpeg/dvd decoders, and digital PCM sound output, and generous helpings of RAM. Linux abides, oblivious.

in the not too different future we'll be plugging our DVD players into systems like these because dolby 5.1 tuners are
about 1000% more expensive than present day audio cards and video adapters. consider how overkill it is to have all this hardware,
a 100mb network pipe, and a desktop display protocol that uses 2% of the bandwidth capacity on 2d widgets and panels with
combinations of bitmap ops and text rendering. firewire provides 4 times this bandwidth. packets are cheap as water.

For my purposes VSTA would serve fine as a high performance remote terminal; the missing components presently are a 3d space
window manager, kernel remote display protocols suitable for high bandwidth or crypto+compression for insecure WAN links, and
perhaps a bit of driver abstraction magic for the various mutlimedia chipsets and op-codes. also missing is the whole paradigm that escapes single-machine thinking. VSTA has (at least once upon a time) exported its namespace items across the  network. add to this an elegant scheduler algorithm and the ease with which a linux driver might be hijacked and ported to vsta, its a very tempting platform for bus-intensive remote workstations.

How do you really wish to address hundred of machines you need to operate and access regularly? a scene from Jurrassic park that comes to my mind, unlikely as it sounds, was of the little girl pointing and clicking her way through a 3d fly-through "unix system".

someday sourceforge will acknowledge my project application :-) I will gladly discuss these matters in thier own setting when that happens. I originally started down the path of minimalist javaOS platform; though found it better to strive for a single remote workstation to the dozens of boring machine displays i interact with which run supported jvm's and heaps of horsepower and JIT's on platforms customers are demanding.

> chefren <chefren@pi.net> wrote:
>
> On 9 Feb 01, at 19:52, James Northrup wrote:
>
> > Not to stray the topic at all... but... I have considered vsta
> ripe with
> > opportunity to operate as a dedicated java workstation. My
> experience with
> > low-power old sparcs with fast framebuffers and pathetic cpu's
> has shaped my
> > conception of a vsta NC-like device (or any other platform for
> that
> > matter.).
>
> I would be happy if this hardware platform would be chosen:
>
> http://www.thinknic.com/
>
>
> Simply put, the idea is: CD in the box, boot, and it works.
>
> There is 64MB RAM available, 200MHz CPU and it costs $199.
>
>
> There are a few different efforts for this hardware
> platform. That can all be tried and compared easily. All
> software is open source. People are making webservers with
> it, routers, terminals and so on.
>
> +++chefren
>
>
>
>
>
>
>
>
> ---------------------------------
> Do You Yahoo!?
> - Get personalized email addresses from Yahoo! Mail Personal
> Address - only $35 a year!


Do You Yahoo!?
- Get personalized email addresses from Yahoo! Mail Personal Address - only $35 a year! --0-2130938248-982039741=:63511-- From daemon Tue Feb 13 06:07:47 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1D67ln01819 for vsta-xplod; Tue, 13 Feb 2001 06:07:47 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1D67hE01799 for ; Tue, 13 Feb 2001 06:07:43 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1DEQn422942 for ; Tue, 13 Feb 2001 15:26:49 +0100 Date: Tue, 13 Feb 2001 15:26:49 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: Updated the homepage a bit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi all did a small update. added some more documentation. /Erik From daemon Tue Feb 13 11:24:31 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1DBOVH02391 for vsta-xplod; Tue, 13 Feb 2001 11:24:31 GMT Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1DBORE02371 for ; Tue, 13 Feb 2001 11:24:27 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Feb 2001 19:41:31 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: Java port to VSTa? -- tangent Date: Tue, 13 Feb 2001 14:41:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: If you're looking for a network transparent windowing environment with incredible 2-D capabilities you should check out Berlin(http://www.berlin-consortium.org) It's a new vector based window system developed from scratch and built on CORBA and GGI(http://www.ggi-project.org). GGI also forms the base graphics library for the 3-D window manager project(http://www.3dwm.org). Berlin is currently being developed in C++. I believe they also have plans to integrate other media into the transport model so they can network transparent audio and video, but I'm not sure. You'd have to check out the mailing lists. These look like a great starting point. Were they to suit the exact needs the remainder of my work would be cranking up the frame rate end-to end from the server to its display on /n/ subscribing clients. CORBA makes a convenient connection aide but imposes marshalling overhead if used religiously. I would be content to write dedicated protocols thereafter for packet and streaming updates of the right fit. I'm certain all of the pieces exist for a really spiffy 3d remote terminal environment, but all these pieces have been built with different purpose in mind. My ideal concept of a remote client update is like follows: Machines A,B; Process Exists on A Process Display Context on B B has n [{X11|Glide|opengl|directx|ggi?}] displays, and could be a repeater to C. a) A or B is capable of delivering raw image data to displays; where A could (in an ideal world) dump translated machine-specific buffers across the network to waiting DMA on the AGP bus. b) A could also encode/encrypt/compress image data for reciprocal decoding on B. on a fast network where A is a beefy server and B is an underpowered graphics workstation, the choice to send raw machine specific info rendered on the server would yield a snappier frame rate. Exactly what the bandwidth could bear. Unknown if this approach scales for 3d info, but one could a take a lesson from the Quake engine on remote 3d rendering. Bandwidth is king. VNC sends bitmap corrections through an encoding pipe, X11 sends X11 primitives across the wire. VNC is a huge drain on CPU on both client and server, due to its bandwidth-saving encoders. On a 200mhz Pentium it's a noticeable drag serving remote display as well. X11 is a joy to work with but is specific to X11 overhead, and can sometimes thrash bandwidth needlessly with trivial updates made. There is no middle ground, nor are VNC or X11 multimedia savvy protocols; but the chipsets exist for these features, and machines with these chipsets will retire as certain as Moore's Law marches on. It's such a performance hungry bent that I'm on that makes it so attractive to consider VSTA as a choice as good as any more established platform. These concepts would be easily expressed in kernel level services, more so than building an application architecture around the problem. It would probably put my entire perspective into sharper focus to need to port Glide to VSTA, port Xvfb, port GGI, etc. It's problem I am looking forward to having :) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Tue Feb 13 16:11:37 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1DGBbN02943 for vsta-xplod; Tue, 13 Feb 2001 16:11:37 GMT Received: from hotmail.com (f179.law3.hotmail.com [209.185.241.179]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1DGBYE02923 for ; Tue, 13 Feb 2001 16:11:34 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Feb 2001 16:28:33 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 14 Feb 2001 00:28:33 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Servers vs. Libs Date: Tue, 13 Feb 2001 19:28:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Feb 2001 00:28:33.0325 (UTC) FILETIME=[100365D0:01C0961D] > >Personally I think things that can be put in servers should be put in > >servers. The graphics is a good example, In plan9 it is in a server > >providing a device to write to. The programs don't need to be aware at >all > >of which graphics hardware there is in the computer. > >But if it is put in a library instead, it can't be multiplexed (ala 8.5 > >and rio). But probably worse, you would have to code wrappers for the > >graphics library to each programming language you'd want to code graphics > >in. > >And for those that preffer coding graphics by calling functions instead >of > >writing data to a device, a library for drawing that uses the > >device(server) could be coded. > >Except that almost every "serious" graphics program does the inevitable >genesis to the point where it wants memory mapped access to the frame >buffer. And I'm not really arguing much, since the MGR port could call the >main mgr process the "graphics server", and then all clients are in their >own address spaces. But, then, MGR is linked with svgalib to actually >control the graphics card, so that's adopting the other rule. > >The other big question is state management. Multiplexing is one (thus, mgr >has its own process). But even in a single client case, the complexity of >state and requirements for cleanup (i.e., on a segv hardware needs to be >un-programmed) might argue for a distinct process. > >Any rule can be applied in such a way that it doesn't make sense. I don't >see any problem with your arguments. If graphics were in server, would that enable network transparent graphics? Since the graphics server would be replying to messages on it's port, it doesn't matter where those messages are coming from. Couldn't those messages simply be sent to a graphics server across a network instead of locally? Would that require much extra effort/coding, or would it happen automatically? Am I off base? Some serious security issues also come to mind. With more thought, the whole distributed graphics server idea seems dubious. What would be the point of allowing access to your graphics hardware to another computer on the network? This is a driver issue right? (I was thinking on a higher level ala X-Windows) But it brings another question to mind. Is VSTa distributable in this manner(or is it already)? Can I mount a dos filesystem on another computer across the network on my own computer? I'm sure it can be done because of the flexibility of message passing, I'm just curious if VSTa is currently capable of it. Also, is there some place I could go for more info on the VSTa design(other than the source code)? Specifically, a somewhat high level overview of how things currently fit together. Thanks for your patience. ;-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Tue Feb 13 17:23:30 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1DHNUK03086 for vsta-xplod; Tue, 13 Feb 2001 17:23:30 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1DHNRE03066 for ; Tue, 13 Feb 2001 17:23:27 GMT Received: (qmail 20853 invoked by alias); 14 Feb 2001 01:40:31 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 20848 invoked by uid 0); 14 Feb 2001 01:40:30 -0000 Received: from dialupq173.ptld.uswest.net (HELO home) (216.161.86.173) by ptldpop1.ptld.uswest.net with SMTP; 14 Feb 2001 01:40:30 -0000 Message-ID: <003a01c09628$0ef6fde0$ad56a1d8@home> From: "Nymia" To: Subject: Limbo Date: Tue, 13 Feb 2001 17:47:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Just wondering how will I get a copy of Limbo from Plan9. I'm planning (if it is possible) to get it up and running on VSTA. Any ideas? From daemon Tue Feb 13 22:56:21 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1DMuL803502 for vsta-xplod; Tue, 13 Feb 2001 22:56:21 GMT Received: from nautilus.dat.escet.urjc.es (nautilus.dat.escet.urjc.es [212.128.1.37]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1DMuEE03482 for ; Tue, 13 Feb 2001 22:56:15 GMT Message-Id: <200102132256.f1DMuEE03482@bodhi.zendo.com> To: Nymia@uswest.net To: vsta@zendo.com Subject: Re: Limbo Date: Wed, 14 Feb 2001 08:26:58 -0500 From: nemo@gsyc.escet.urjc.es MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-bgpbttuyjpppaltjpojksiwwoe" This is a multi-part message in MIME format. --upas-bgpbttuyjpppaltjpojksiwwoe Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You can download a binary version from www.vitanuova.com Limbo runs on Inferno, not on Plan9, and Inferno is not open source, so unless you buy a license, that's all you can do. BTW, Both inferno and limbo are cool. hth --upas-bgpbttuyjpppaltjpojksiwwoe Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from bodhi.zendo.com (bodhi.zendo.com [205.187.71.2]) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id DAA02205 for ; Wed, 14 Feb 2001 03:05:00 +0100 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1DHNUK03086 for vsta-xplod; Tue, 13 Feb 2001 17:23:30 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1DHNRE03066 for ; Tue, 13 Feb 2001 17:23:27 GMT Received: (qmail 20853 invoked by alias); 14 Feb 2001 01:40:31 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 20848 invoked by uid 0); 14 Feb 2001 01:40:30 -0000 Received: from dialupq173.ptld.uswest.net (HELO home) (216.161.86.173) by ptldpop1.ptld.uswest.net with SMTP; 14 Feb 2001 01:40:30 -0000 Message-ID: <003a01c09628$0ef6fde0$ad56a1d8@home> From: "Nymia" To: Subject: Limbo Date: Tue, 13 Feb 2001 17:47:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Just wondering how will I get a copy of Limbo from Plan9. I'm planning (if it is possible) to get it up and running on VSTA. Any ideas? --upas-bgpbttuyjpppaltjpojksiwwoe-- From daemon Wed Feb 14 19:27:50 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1EJRoc05108 for vsta-xplod; Wed, 14 Feb 2001 19:27:50 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1EJRlE05088 for ; Wed, 14 Feb 2001 19:27:47 GMT Received: (qmail 8527 invoked by alias); 15 Feb 2001 03:44:49 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 8518 invoked by uid 0); 15 Feb 2001 03:44:48 -0000 Received: from dialupi228.ptld.uswest.net (HELO home) (207.225.89.228) by ptldpop1.ptld.uswest.net with SMTP; 15 Feb 2001 03:44:48 -0000 Message-ID: <004301c09702$9a433b40$e459e1cf@home> From: "Nymia" To: , Subject: Re: Limbo Date: Wed, 14 Feb 2001 19:51:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Ok, I guess I should stay away from it. Anyway, anybody working on a Ruby port? -----Original Message----- From: nemo@gsyc.escet.urjc.es To: Nymia@uswest.net ; vsta@zendo.com Date: Tuesday, February 13, 2001 11:13 PM Subject: Re: Limbo >You can download a binary version from www.vitanuova.com >Limbo runs on Inferno, not on Plan9, and Inferno is not >open source, so unless you buy a license, that's all you >can do. > >BTW, Both inferno and limbo are cool. > >hth > > From daemon Wed Feb 14 19:11:48 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1EJBmm05067 for vsta-xplod; Wed, 14 Feb 2001 19:11:48 GMT Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1EJBhE05047 for ; Wed, 14 Feb 2001 19:11:43 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Feb 2001 03:28:50 -0000 X-Apparently-From: From: "James Northrup" To: Subject: re: Servers vs. Libs Date: Wed, 14 Feb 2001 22:28:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 A former coworker of mine had a gig displaying 3d models rendered on a cray. As the story goes the cray rendered faster than they could process it. -----Original Message----- From: Sandro Magi [mailto:naasking@hotmail.com] Sent: Tuesday, February 13, 2001 7:29 PM To: vsta@zendo.com Subject: Re: Servers vs. Libs > >Personally I think things that can be put in servers should be put in > >servers. The graphics is a good example, In plan9 it is in a server > >providing a device to write to. The programs don't need to be aware at >all > >of which graphics hardware there is in the computer. > >But if it is put in a library instead, it can't be multiplexed (ala 8.5 > >and rio). But probably worse, you would have to code wrappers for the > >graphics library to each programming language you'd want to code graphics > >in. > >And for those that preffer coding graphics by calling functions instead >of > >writing data to a device, a library for drawing that uses the > >device(server) could be coded. > >Except that almost every "serious" graphics program does the inevitable >genesis to the point where it wants memory mapped access to the frame >buffer. And I'm not really arguing much, since the MGR port could call the >main mgr process the "graphics server", and then all clients are in their >own address spaces. But, then, MGR is linked with svgalib to actually >control the graphics card, so that's adopting the other rule. > >The other big question is state management. Multiplexing is one (thus, mgr >has its own process). But even in a single client case, the complexity of >state and requirements for cleanup (i.e., on a segv hardware needs to be >un-programmed) might argue for a distinct process. > >Any rule can be applied in such a way that it doesn't make sense. I don't >see any problem with your arguments. If graphics were in server, would that enable network transparent graphics? Since the graphics server would be replying to messages on it's port, it doesn't matter where those messages are coming from. Couldn't those messages simply be sent to a graphics server across a network instead of locally? Would that require much extra effort/coding, or would it happen automatically? Am I off base? Some serious security issues also come to mind. With more thought, the whole distributed graphics server idea seems dubious. What would be the point of allowing access to your graphics hardware to another computer on the network? This is a driver issue right? (I was thinking on a higher level ala X-Windows) But it brings another question to mind. Is VSTa distributable in this manner(or is it already)? Can I mount a dos filesystem on another computer across the network on my own computer? I'm sure it can be done because of the flexibility of message passing, I'm just curious if VSTa is currently capable of it. Also, is there some place I could go for more info on the VSTa design(other than the source code)? Specifically, a somewhat high level overview of how things currently fit together. Thanks for your patience. ;-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Thu Feb 15 19:06:21 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1FJ6L806983 for vsta-xplod; Thu, 15 Feb 2001 19:06:21 GMT Received: from hotmail.com (f22.law3.hotmail.com [209.185.241.22]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1FJ6GE06963 for ; Thu, 15 Feb 2001 19:06:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Feb 2001 19:23:21 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 16 Feb 2001 03:23:21 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Miscellaneous comments and questions Date: Thu, 15 Feb 2001 22:23:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2001 03:23:21.0945 (UTC) FILETIME=[D08B4C90:01C097C7] I've noticed that alot of VSTa's binaries and commands provide very little feedback as to their proper use or errors encountered while runnig. Some of the feedback is downright unhelpful. I was just wondering if this was done deliberately to keep the size of VSTa down to a minimum. Is size a spoken/unspoken goal in VSTa? Are there any set goals for VSTa at the moment? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Thu Feb 15 20:57:20 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1FKvKY07107 for vsta-xplod; Thu, 15 Feb 2001 20:57:20 GMT Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1FKvHE07087 for ; Thu, 15 Feb 2001 20:57:17 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Feb 2001 05:14:28 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: Miscellaneous comments and questions Date: Fri, 16 Feb 2001 00:14:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 I'm fascinated by a package called asmutils which includes a libc, most fundamental /bin utils, and rc6 hashing. The libc and everything built with it, with the exception of the crypto stuff, all fit happily within a single 4k l1 cache segment apiece. I haven't put these through their paces yet but I muse that shell scripts writtin with asm utils averaging 200+ bytes apiece could possibly compete with compiled scripts written on C foundations. These tools also exhibit bad user feedback manners, however, if there be room for improvement in x86 vsta distributions with speed and size in mind, perhaps its not out of the question to add a -help and -version to the spartan asmutils if they meet the desired featuresets in other areas. -----Original Message----- From: Sandro Magi [mailto:naasking@hotmail.com] Sent: Thursday, February 15, 2001 10:23 PM To: Subject: Miscellaneous comments and questions I've noticed that alot of VSTa's binaries and commands provide very little feedback as to their proper use or errors encountered while runnig. Some of the feedback is downright unhelpful. I was just wondering if this was done deliberately to keep the size of VSTa down to a minimum. Is size a spoken/unspoken goal in VSTa? Are there any set goals for VSTa at the moment? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Fri Feb 16 08:36:35 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1G8aZu08089 for vsta-xplod; Fri, 16 Feb 2001 08:36:35 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1G8aQE08077; Fri, 16 Feb 2001 08:36:26 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA12008; Fri, 16 Feb 2001 08:53:29 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102161653.IAA12008@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: Miscellaneous comments and questions In-reply-to: Your message of "Thu, 15 Feb 2001 22:23:21 EST." Date: Fri, 16 Feb 2001 08:53:29 -0800 From: Andy Valencia ["Sandro Magi" writes:] >I've noticed that alot of VSTa's binaries and commands provide very little >feedback as to their proper use or errors encountered while runnig. Some of >the feedback is downright unhelpful. I was just wondering if this was done >deliberately to keep the size of VSTa down to a minimum. Is size a >spoken/unspoken goal in VSTa? Are there any set goals for VSTa at the >moment? A lot of the binaries are ports, which, of course, provide whatever level of helpfullness they happen to provide. For VSTa unique binaries, the "small and simple" philosophy applied while coding, but I have nothing against a clear and timely error message from a utility. So if you have particular ones which drive you crazy, just let me know (or submit patches, whichever you prefer) and I'll fix it up. My philosophy of smallness is allowed to follow (but trail!) general sizes of things in the industry. So, since disk and memory have doubled in average size several times since VSTa was first written, I'm OK with some growth in both kernel and commands. But my litmus test is still to ask "is this small and simple?", so I'm not looking to double, say, the size of the kernel! Regards, Andy Valencia From daemon Fri Feb 16 09:51:46 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1G9pk808239 for vsta-xplod; Fri, 16 Feb 2001 09:51:46 GMT Received: from hotmail.com (f71.law3.hotmail.com [209.185.241.71]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1G9piE08219 for ; Fri, 16 Feb 2001 09:51:44 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Feb 2001 10:08:51 -0800 Received: from 128.100.8.133 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 16 Feb 2001 18:08:51 GMT X-Originating-IP: [128.100.8.133] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Miscellaneous comments and questions Date: Fri, 16 Feb 2001 13:08:51 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2001 18:08:51.0387 (UTC) FILETIME=[8428C8B0:01C09843] >A lot of the binaries are ports, which, of course, provide whatever level >of >helpfullness they happen to provide. > >For VSTa unique binaries, the "small and simple" philosophy applied while >coding, but I have nothing against a clear and timely error message from a >utility. So if you have particular ones which drive you crazy, just let me >know (or submit patches, whichever you prefer) and I'll fix it up. > >My philosophy of smallness is allowed to follow (but trail!) general sizes >of things in the industry. So, since disk and memory have doubled in >average size several times since VSTa was first written, I'm OK with some >growth in both kernel and commands. But my litmus test is still to ask "is >this small and simple?", so I'm not looking to double, say, the size of the >kernel! I wasn't planning on increasing kernel size(smaller is better :-)) and I wasn't even thinking about doubling the size of anything. :-) The 'perm' error messages that I sometimes get when working in VSTa were just frustrating. Add the fact that I have nowhere to check for command options and that their are few man pages(and the fact that the mailing list archives are not searchable) and I'm forced to post the most trivial questions to this list(like my very simple question a few months ago about starting the mouse server). GNU utilities have a --help option that (usually) self documents the use of that command. I was thinking something along those lines would be really helpful. --help could list options available, very brief summary of the options and other relevant parameters. Adding a --help option would probably also reduce the number of simple and repeat questions on the mailing list. I also had a thought about the network driver issue. You mentioned after someone created a 3com driver that you needed to devise some kind of scheme to enable ka9q to use the various different cards that may be available on a machine(I believe the name being looked up is currently hard coded in ka9q, right? -> 'net/ne2000'). Why not just have the driver/servers themselves register generic interface names? Instead of 'net/ne2000' (or something similar), register 'net/eth0' as the first network card, 'net/eth1' as the second, etc. A simple loop while registering a name for the server would simplify things greatly for ka9q(in semi-pseudo code): char *name = "net/eth0"; n = strlen(name)-1; while(name[n] <= '9') { /* attempt to register name here, if successful, break */ name[n]++; } printf("registered: %s\n",name); Something similar to this would enable ka9q(or any other applications) to use the drivers by just looking up the generic names instead of having to know the name of the actual driver. Just a thought. :-) Sincerely, Sandro _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Fri Feb 16 14:04:43 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1GE4hw08710 for vsta-xplod; Fri, 16 Feb 2001 14:04:43 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1GE4bE08703; Fri, 16 Feb 2001 14:04:37 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id OAA12528; Fri, 16 Feb 2001 14:21:44 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102162221.OAA12528@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: Miscellaneous comments and questions In-reply-to: Your message of "Fri, 16 Feb 2001 13:08:51 EST." Date: Fri, 16 Feb 2001 14:21:44 -0800 From: Andy Valencia ["Sandro Magi" writes:] >The 'perm' error messages that I sometimes get when working in VSTa were >just frustrating. Note that some of this went away recently, when I removed some non-portable decoding of return status and used the appropriate wait.h macros. >Add the fact that I have nowhere to check for command >options Except the source. :-> >and that their are few man pages Guilty as charged. It's just that I thought the truly VSTa unique stuff would need documenting before things which behaved much like any other UNIX would. >(and the fact that the mailing list >archives are not searchable) and I'm forced to post the most trivial >questions to this list(like my very simple question a few months ago about >starting the mouse server). Not that it's a problem to ask! But I wouldn't mind having the archives searchable. I thought some of the search engines could actually do that (search within a given WWW domain only)--I know our mail archives are picked up by a couple of the big search engines. Or if somebody has a good utility I could attach to CGI, I'd be happy to look into it. >GNU utilities have a --help option that (usually) self documents the use of >that command. I was thinking something along those lines would be really >helpful. --help could list options available, very brief summary of the >options and other relevant parameters. I've also been wondering if we shouldn't head off the well-beaten UNIX track and do a Tenex-style UI instead? Still with distinct utilities in their own processes beneath, but with command completion and context sensitive help integrated. >Adding a --help option would probably also reduce the number of simple and >repeat questions on the mailing list. I really don't remember that many of these, as opposed to stuff which runs deeper and is more unique to VSTa. But I agree the mouse server could be a little more helpful. >Why not just have the driver/servers themselves register generic interface >names? Instead of 'net/ne2000' (or something similar), register 'net/eth0' >as the first network card, 'net/eth1' as the second, etc. How does the first know it's supposed to be first? Also, this isn't at all what a UNIX-ish environment does (not that this is a guarantee that it's the right way to go). >A simple loop while registering a name for the server would simplify things >greatly for ka9q(in semi-pseudo code): >char *name = "net/eth0"; >n = strlen(name)-1; >while(name[n] <= '9') { > /* attempt to register name here, if successful, break */ > name[n]++; >} >printf("registered: %s\n",name); Well, that would *find* them, but in pretty much every IP network I've ever used you need to relate a deterministic IP address and netmask to the physical interface. >Something similar to this would enable ka9q(or any other applications) to >use the drivers by just looking up the generic names instead of having to >know the name of the actual driver. Just a thought. :-) I'm open to suggestions, but in even non-UNIX environments (like, say, IOS) you want to name a specific physical interface, because there's a specific physical network attached to it. Andy Valencia From daemon Fri Feb 16 19:50:12 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1GJoCW09213 for vsta-xplod; Fri, 16 Feb 2001 19:50:12 GMT Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1GJo8E09193 for ; Fri, 16 Feb 2001 19:50:08 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Feb 2001 04:07:21 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: Miscellaneous comments and questions Date: Fri, 16 Feb 2001 23:07:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200102162221.OAA12528@vandys-pc.zendo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 -----Original Message----- From: Andy Valencia [mailto:vandys@zendo.com] Sent: Friday, February 16, 2001 5:22 PM To: Sandro Magi Cc: vsta@zendo.com Subject: Re: Miscellaneous comments and questions [...] Or if somebody has a good utility I could attach to CGI, I'd be happy to look into it. glint [..] your philosophy essay references a preference for memory remapping in the tasker and kernel if im not mistaken. I have some curiousity about your present day view looking back on what is presently in place; Do you still feel that you have a relative freedom from copy operations particularly from one io buffer to the other? I wouldn't know how to obtain a reference that gives an idea of cycles involved with block copying vs. hardware remapping; nor do I quite understand the role of all the devices in the mmu of intel, and I understand that sun4 and sun3 architectures have a software mmu. Suns have context switch registers, and in faq I ran across regarding linux there was a mention that the linux kernel can be boiled down to about 3 context entries whereas slowaris can easily usurp the majority of these context slots and roll the cache entries off the edge, the cost of exporting the context maps is apparently quite high. Is it typical practice to write queus of block operations that are linked together and serviced in a chain under a single context where possible? Possibly even a single instruction to dispatch with many merged pipelined block operations with multiple segments being written in the same refresh? Does vsta for intel have equivalent hardware support for context switching or would this be a benefit of having a hardware MMU that can recv and handle context info via the caching and paging hardware? Does vsta context switch particularly better or worse that you had hoped in any areas? What sort of span of time are we to expect on a page fault or context switch operation ? If I were to indulge in wanton memory remapping excercises on the intel platform, what sort of alignment or block minimum addressing is available to the hardware mmu? What keen microcode can we take advantage of that would take the place of small asm byte moves? Is this essentially stuff that is pushed onto gcc for scheduling, pipelining? how much faster is it to call a p5 4M block move remap operation than the equivalent [1-4]k block remaps? can motherboard resources be taken advantage of for asynchronous move/copy/remapping operations? Do certain chipsets make a big difference in these kind of areas or is everyone vending pretty much identical featuresets throughout the entire cost range of a given bus classification. (by this I mean, are all pci32 busses the same general speed, all eisa, all isa, all bridge devices all created pretty much equal to their competitors, no matter what kind of registers you can tweak) sorry for the deluge. One will never get a good feel for the hardware contours living and working around high level languages _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Fri Feb 16 20:00:01 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1GK01a09251 for vsta-xplod; Fri, 16 Feb 2001 20:00:01 GMT Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1GJxwE09228 for ; Fri, 16 Feb 2001 19:59:58 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Feb 2001 04:17:12 -0000 X-Apparently-From: From: "James Northrup" To: Subject: RE: Miscellaneous comments and questions Date: Fri, 16 Feb 2001 23:17:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200102162221.OAA12528@vandys-pc.zendo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Oops glimpse, not glint _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Fri Feb 16 23:10:21 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1GNALN09486 for vsta-xplod; Fri, 16 Feb 2001 23:10:21 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1GNAGE09466 for ; Fri, 16 Feb 2001 23:10:17 GMT Received: (qmail 14742 invoked by alias); 17 Feb 2001 07:27:30 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 14737 invoked by uid 0); 17 Feb 2001 07:27:29 -0000 Received: from dialupp219.ptld.uswest.net (HELO home) (216.161.85.219) by ptldpop1.ptld.uswest.net with SMTP; 17 Feb 2001 07:27:29 -0000 Message-ID: <001a01c098b4$0fd18b20$db55a1d8@home> From: "Nymia" To: Subject: PCI Date: Fri, 16 Feb 2001 23:34:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Just wondering what is the status of PCI on VSTa? Any news would be greatly appreciated. If it is not yet written, then, will it be written as a FS or is it going to be something else? Also, made some research about PCI and found that it can be reached directly or from the BIOS. One good source code I found was on Linux, located on pci-pc.c and one on AtheOS on pci.c. On Linux, the code fragment that directly checks for the PCI is posted below: static struct pci_ops * __init pci_check_direct(void) { unsigned int tmp; unsigned long flags; __save_flags(flags); __cli(); /* * Check if configuration type 1 works. */ if (pci_probe & PCI_PROBE_CONF1) { outb (0x01, 0xCFB); tmp = inl (0xCF8); outl (0x80000000, 0xCF8); if (inl (0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) { outl (tmp, 0xCF8); __restore_flags(flags); printk("PCI: Using configuration type 1\n"); request_region(0xCF8, 8, "PCI conf1"); return &pci_direct_conf1; } outl (tmp, 0xCF8); } /* * Check if configuration type 2 works. */ if (pci_probe & PCI_PROBE_CONF2) { outb (0x00, 0xCFB); outb (0x00, 0xCF8); outb (0x00, 0xCFA); if (inb (0xCF8) == 0x00 && inb (0xCFA) == 0x00 && pci_sanity_check(&pci_direct_conf2)) { __restore_flags(flags); printk("PCI: Using configuration type 2\n"); request_region(0xCF8, 4, "PCI conf2"); return &pci_direct_conf2; } } __restore_flags(flags); return NULL; } Here's one that reads the config using the BIOS which is taken from AtheOS: uint32 read_pci_config( int nBusNum, int nDevNum, int nFncNum, int nOffset, int nSize ) { struct RMREGS rm; if ( 2 == nSize || 4 == nSize || 1 == nSize ) { int anCmd[] = { 0xb108, 0xb109, 0x000, 0xb10a }; uint32 anMasks[] = { 0x000000ff, 0x0000ffff, 0x00000000, 0xffffffff }; memset( &rm, 0, sizeof( rm ) ); rm.EAX = anCmd[nSize - 1]; rm.EBX = (nBusNum << 8) | (((nDevNum << 3) | nFncNum)); rm.EDI = nOffset; realint( 0x1a, &rm ); if ( 0 == ((rm.EAX >> 8) & 0xff) ) { return( rm.ECX & anMasks[ nSize- 1 ] ); } else { return( anMasks[ nSize- 1 ] ); } } else { printk( "ERROR : Invalid size %d passed to read_pci_config()\n", nSize ); return( 0 ); } } From daemon Fri Feb 16 23:24:14 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1GNOEL09529 for vsta-xplod; Fri, 16 Feb 2001 23:24:14 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1GNOBE09509 for ; Fri, 16 Feb 2001 23:24:11 GMT Received: (qmail 15525 invoked by alias); 17 Feb 2001 07:41:25 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 15520 invoked by uid 0); 17 Feb 2001 07:41:24 -0000 Received: from dialupp219.ptld.uswest.net (HELO home) (216.161.85.219) by ptldpop1.ptld.uswest.net with SMTP; 17 Feb 2001 07:41:24 -0000 Message-ID: <002801c098b6$0199cb60$db55a1d8@home> From: "Nymia" To: Subject: PCI Date: Fri, 16 Feb 2001 23:48:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Please ignore my question on how the PCI code will be packaged. I just found the answer on the mailing list. http://www.vsta.org/mail/12/0191.html Thx. From daemon Sat Feb 17 05:33:29 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1H5XTN12298 for vsta-xplod; Sat, 17 Feb 2001 05:33:29 GMT Received: from hotmail.com (f122.law3.hotmail.com [209.185.241.122]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1H5XOE12278 for ; Sat, 17 Feb 2001 05:33:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 17 Feb 2001 05:50:34 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 17 Feb 2001 13:50:33 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Miscellaneous comments and questions Date: Sat, 17 Feb 2001 08:50:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Feb 2001 13:50:34.0004 (UTC) FILETIME=[99698D40:01C098E8] > >The 'perm' error messages that I sometimes get when working in VSTa were > >just frustrating. > >Note that some of this went away recently, when I removed some non-portable >decoding of return status and used the appropriate wait.h macros. Yes, I noticed it was a little more helpful recently. :-) > >Add the fact that I have nowhere to check for command > >options > >Except the source. :-> Yup. :-) > >and that their are few man pages > >Guilty as charged. It's just that I thought the truly VSTa unique stuff >would need documenting before things which behaved much like any other UNIX >would. Oh, definitely! The common commands are not really the problems I was having much trouble with(though some command options are different than in Linux). But you're right, the esoteric stuff first, the common stuff later. >Not that it's a problem to ask! > >But I wouldn't mind having the archives searchable. I thought some of the >search engines could actually do that (search within a given WWW domain >only)--I know our mail archives are picked up by a couple of the big search >engines. Hmmm, I suppose that might work. I'll try google next time I have a problem and see how that works out. Thanks for the tip. :-) >Or if somebody has a good utility I could attach to CGI, I'd be happy to >look into it. I can't recommend one, but I'll keep an eye out. >I've also been wondering if we shouldn't head off the well-beaten UNIX >track >and do a Tenex-style UI instead? Still with distinct utilities in their >own >processes beneath, but with command completion and context sensitive help >integrated. I'm not too familiar with Tenex. Is there some info you could point me to? > >Why not just have the driver/servers themselves register generic >interface > >names? Instead of 'net/ne2000' (or something similar), register >'net/eth0' > >as the first network card, 'net/eth1' as the second, etc. > >How does the first know it's supposed to be first? Well, I figured it would just try registering the first and if namer returned an error saying it was already taken, then it try the second and so on. The drivers would simply need to be started in the proper order(in reading your message I realized a problem with this which I'll illustrate later). >Also, this isn't at all >what a UNIX-ish environment does (not that this is a guarantee that it's >the >right way to go). Well, I don't claim to know that much about this subject. Perhaps I just misunderstood the problem. > >A simple loop while registering a name for the server would simplify >things > >greatly for ka9q(in semi-pseudo code): > >char *name = "net/eth0"; > >n = strlen(name)-1; > >while(name[n] <= '9') { > > /* attempt to register name here, if successful, break */ > > name[n]++; > >} > >printf("registered: %s\n",name); > >Well, that would *find* them, but in pretty much every IP network I've ever >used you need to relate a deterministic IP address and netmask to the >physical interface. Isn't that ka9q;s problem? Does the server, or ka9q determine addressing for the interfaces? (I'm under the impression that ka9q takes care of that) If ka9q does it then it has to find what drivers are running in the first place, that's the problem I'm addressing. If not, then I'm totally off my rocker. :-) This is my current understanding of the problem: ethernet servers register names that identify the particular server that is running(and hence what card is in the machine), ie. 'net/ne2000'. Now ka9q needs to obtain the port an ethernet server is listening on in order to communicate with it, configure it with an ip, etc. However, in order to find a server, you need the name it registered with so namer can return the port it serves requests on. The current problem (as I understand it) is that the registered name that is searched for is currently hard-coded into ka9q since it's impossible to know ahead of time what ethernet server might be running(given the fact that there are alot of different possibilities - not the case now, but hopefully will be in the future :-). A brute force solution would be to check every possibility, but that's not very flexible since you would have to either change the source for each additional driver, or add an entry in a configuration file which is read in at run time. The option I suggested was to have the server register a generic name for itself so it doesn't matter what driver is running. The first driver to be started will always be 'net/eth0', the second 'net/eth1'(or some similar naimg scheme). This has two benefits that I can see: a) it only requires the addition of a simple loop in registering a name and searching for the port(so just simple additions in the drivers and ka9q source), and b) enforces principle of least priviledge(albeit in a somewhat superficial way) since it's not possible to find out what hardware the machine has by examining the running drivers(probably not that big a deal, but you never know; prevention is the best way - not that I'm any security expert). Now, the problem would be more complicated if each driver didn't have a standard interface, ie. the message for sending a packet for 3com cards was different than ne2000 cards, but that's not the case right? > >Something similar to this would enable ka9q(or any other applications) to > >use the drivers by just looking up the generic names instead of having to > >know the name of the actual driver. Just a thought. :-) > >I'm open to suggestions, but in even non-UNIX environments (like, say, IOS) >you want to name a specific physical interface, because there's a specific >physical network attached to it. Hmmm... Maybe I AM misunderstanding the issue. Say you have two network cards('net/eth0' being a 3com, and 'net/eth1' being a ne2000), and you configure them with a setup for a particular network. Then say you remove the first one(3com card), the ne2000 will then register as 'net/eth0' instead of its original 'net/eth1' and the configuration options for the 3com will be used for the ne2000; obviously a completely incorrect situation. That is a serious problem with my idea. I'll have to think about that, unless you already have a better solution to this problem(I'm very curious how it's done, or how you're going to do it). Thanks for your patience. :-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 17 08:27:41 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1H8RfW12468 for vsta-xplod; Sat, 17 Feb 2001 08:27:41 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1H8RcE12461; Sat, 17 Feb 2001 08:27:38 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA16835; Sat, 17 Feb 2001 08:44:48 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102171644.IAA16835@vandys-pc.zendo.com> To: "Sandro Magi" cc: vsta@zendo.com Subject: Re: Miscellaneous comments and questions In-reply-to: Your message of "Sat, 17 Feb 2001 08:50:33 EST." Date: Sat, 17 Feb 2001 08:44:48 -0800 From: Andy Valencia ["Sandro Magi" writes:] >Hmmm... Maybe I AM misunderstanding the issue. Say you have two network >cards('net/eth0' being a 3com, and 'net/eth1' being a ne2000), and you >configure them with a setup for a particular network. Then say you remove >the first one(3com card), the ne2000 will then register as 'net/eth0' >instead of its original 'net/eth1' and the configuration options for the >3com will be used for the ne2000; obviously a completely incorrect >situation. That is a serious problem with my idea. I'll have to think about >that, unless you already have a better solution to this problem(I'm very >curious how it's done, or how you're going to do it). The most common "auto config" technique in IP is to use DHCP (and, if it's a PPP link, IPCP). This works OK for hosts, but not so well for routers. Even for host mode, it's pretty common to not have DHCP available. In the next release, KA9Q interface setup for the "generic ethernet" interface type takes a new argument, which is the registry name of the driver. This should help somewhat (and command lines in KA9Q do have help available!). Andy Valencia From daemon Sat Feb 17 10:08:35 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1HA8Z012655 for vsta-xplod; Sat, 17 Feb 2001 10:08:35 GMT Received: from hotmail.com (f244.law3.hotmail.com [209.185.241.244]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1HA8WE12632 for ; Sat, 17 Feb 2001 10:08:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 17 Feb 2001 10:25:42 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 17 Feb 2001 18:25:42 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Miscellaneous comments and questions Date: Sat, 17 Feb 2001 13:25:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Feb 2001 18:25:42.0700 (UTC) FILETIME=[095CA6C0:01C0990F] >The most common "auto config" technique in IP is to use DHCP (and, if it's >a >PPP link, IPCP). This works OK for hosts, but not so well for routers. >Even for host mode, it's pretty common to not have DHCP available. I don't. :-) >In the next release, KA9Q interface setup for the "generic ethernet" >interface type takes a new argument, which is the registry name of the >driver. This should help somewhat (and command lines in KA9Q do have help >available!). So will the registry name for all the network drivers simply be 'net/' the driver name? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 17 10:12:18 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1HACIY12684 for vsta-xplod; Sat, 17 Feb 2001 10:12:18 GMT Received: from hotmail.com (f268.law3.hotmail.com [209.185.240.46]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1HACGE12664 for ; Sat, 17 Feb 2001 10:12:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 17 Feb 2001 10:29:26 -0800 Received: from 64.229.104.114 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 17 Feb 2001 18:29:26 GMT X-Originating-IP: [64.229.104.114] From: "Sandro Magi" To: vsta@zendo.com Subject: Re: Miscellaneous comments and questions Date: Sat, 17 Feb 2001 13:29:26 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Feb 2001 18:29:26.0721 (UTC) FILETIME=[8EE38B10:01C0990F] >In the next release, KA9Q interface setup for the "generic ethernet" >interface type takes a new argument, which is the registry name of the >driver. This should help somewhat (and command lines in KA9Q do have help >available!). This just occurred to me. What if you have more than one ne2000 network card. You need two servers then right? One for each card? But they both can't register 'net/ne2000'. How would you be able to distinguish between the two? How is this resolved? This situation would be quite common for routers. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From daemon Sat Feb 17 17:33:38 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1HHXcC13272 for vsta-xplod; Sat, 17 Feb 2001 17:33:38 GMT Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1HHXYE13252 for ; Sat, 17 Feb 2001 17:33:34 GMT Received: (qmail 22745 invoked by alias); 18 Feb 2001 01:50:50 -0000 Delivered-To: fixup-vsta@zendo.com@fixme Received: (qmail 22740 invoked by uid 0); 18 Feb 2001 01:50:49 -0000 Received: from dialupo246.ptld.uswest.net (HELO home) (216.161.84.246) by ptldpop1.ptld.uswest.net with SMTP; 18 Feb 2001 01:50:49 -0000 Message-ID: <001001c0994e$3387a3c0$f654a1d8@home> From: "Nymia" To: Subject: Doxygen generated documentation Date: Sat, 17 Feb 2001 17:57:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 I have prepared a simple Doxygen generated documentation of VSTa. The link is at http://members.fortunecity.com/nymia/vsta/doc/ I'm currently adding more definitions to it so it can have links. It's only my first stab at documenting VSTa using Doxygen though, so be kind to it. From daemon Sun Feb 18 10:38:04 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1IAc4j14612 for vsta-xplod; Sun, 18 Feb 2001 10:38:04 GMT Received: from mel-b.jpl.nu (root@[194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1IAbxE14592 for ; Sun, 18 Feb 2001 10:37:59 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1IIvhS31528 for ; Sun, 18 Feb 2001 19:57:43 +0100 Date: Sun, 18 Feb 2001 19:57:35 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: Re: Servers vs. Libs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Feb 2001, Sandro Magi wrote: > > > >Except that almost every "serious" graphics program does the inevitable > >genesis to the point where it wants memory mapped access to the frame > >buffer. And I'm not really arguing much, since the MGR port could call the > >main mgr process the "graphics server", and then all clients are in their > >own address spaces. But, then, MGR is linked with svgalib to actually > >control the graphics card, so that's adopting the other rule. > > well, I don't see anything that wouldn't let the graphics server negotiate a shared memory frame buffer with a graphics intensitive program running on top of it. That frame buffer wouldn't use the acceleration in the card though... But the graphics server would of course have line drawing commands and such and use the card acceleration for them. If there is any that is, otherwise the server should emulate them. And I suppose MGR isn't going the be the only windowing system for VSTa forever. and I would be nice to have different windowing systems use the same graphics drivers. and you wouldn't need to update the windowing system just because the driver for the card is updated. > >The other big question is state management. Multiplexing is one (thus, mgr > >has its own process). But even in a single client case, the complexity of > >state and requirements for cleanup (i.e., on a segv hardware needs to be > >un-programmed) might argue for a distinct process. > > Yes, that's very true > >Any rule can be applied in such a way that it doesn't make sense. I don't > >see any problem with your arguments. > > If graphics were in server, would that enable network transparent graphics? > Since the graphics server would be replying to messages on it's port, it > doesn't matter where those messages are coming from. Couldn't those messages > simply be sent to a graphics server across a network instead of locally? > Would that require much extra effort/coding, or would it happen > automatically? Am I off base? Some serious security issues also come to > mind. > Yes, and that would basically happen automatically. Or, just as automatically as with all other filesystems. > With more thought, the whole distributed graphics server idea seems dubious. > What would be the point of allowing access to your graphics hardware to > another computer on the network? This is a driver issue right? (I was > thinking on a higher level ala X-Windows) well, you could multihead X usign two computers :) /Erik From daemon Sun Feb 18 17:44:45 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1IHijC15170 for vsta-xplod; Sun, 18 Feb 2001 17:44:45 GMT Received: from perntexc01.iluka.com (mail.iluka.com [203.38.111.137]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1IHicE15150 for ; Sun, 18 Feb 2001 17:44:38 GMT Received: by PERNTEXC01 with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Feb 2001 10:01:47 +0800 Message-ID: <3FC96A0BD509D411930500062950DFB73C1B49@GERNT002> From: "Dines, Eric" To: "'Nymia'" , vsta@zendo.com Subject: RE: Doxygen generated documentation Date: Mon, 19 Feb 2001 10:13:43 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" >I have prepared a simple Doxygen generated documentation >of VSTa. The link >is at http://members.fortunecity.com/nymia/vsta/doc/ >I'm currently adding more definitions to it so it can >have links. It's only >my first stab at documenting VSTa using Doxygen though, >so be kind to it. I like it fine. Is a tarball (or something) available? ------------------------------------------------------------------------- From daemon Mon Feb 19 00:16:13 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1J0GDb15671 for vsta-xplod; Mon, 19 Feb 2001 00:16:13 GMT Received: from mozart.chat.net (IDENT:qmailr@[216.103.193.237]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1J0G8E15651 for ; Mon, 19 Feb 2001 00:16:08 GMT Received: (qmail 30178 invoked by uid 120); 19 Feb 2001 08:55:42 -0000 Date: Mon, 19 Feb 2001 00:55:42 -0800 From: David Jeske To: vsta@zendo.com Subject: Re: Servers vs. Libs Message-ID: <20010219005542.A22749@mozart.chat.net> Mail-Followup-To: vsta@zendo.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Regarding this graphics 'servers vs. libs' discussion. I recommend taking a look at what the linux libGGI did with a creative library stuff. It certainly had a server component (in the form of X, or a kernel driver), however, they did some neat stuff by making the libggi library the focus of the user-level programs. They could easily be retargeted to different displays by GGI changing the way the library was bound. ..back to lurking. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net From daemon Mon Feb 19 11:17:55 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1JBHtH16610 for vsta-xplod; Mon, 19 Feb 2001 11:17:55 GMT Received: from lain.internal.chaoticdreams.org ([64.162.95.164]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1JBHnE16590 for ; Mon, 19 Feb 2001 11:17:49 GMT Received: (from major@localhost) by lain.internal.chaoticdreams.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f1JJZ8w04530; Mon, 19 Feb 2001 11:35:08 -0800 Date: Mon, 19 Feb 2001 11:35:08 -0800 From: Major Trips To: vsta@zendo.com Cc: lethal@chaoticdreams.org Subject: Re: Servers vs. Libs Message-ID: <20010219113508.A30593@chaoticdreams.org> Mail-Followup-To: Major Trips , vsta@zendo.com, lethal@chaoticdreams.org References: <20010219005542.A22749@mozart.chat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <20010219005542.A22749@mozart.chat.net>; from jeske@chat.net on Mon, Feb 19, 2001 at 12:55:42AM -0800 Organization: Chaotic Dreams Development I for one would find it interesting to support the linux FB interface and possible port over the libfbx that the U4X developers have been creating. I have been talking with Paul Mundt, one of the u5x developers on the subject, and I believe he is growing more interested in getting libfbx onto VSTa. The libfbx is more a hacked up collection of acceleration routines for various graphics adapters (MGA, 3DFX, ect..), and is designed to work with the FB interface. At the moment I believe Stampede Linux and the linux arm project are using the libfbx, and word has it that some developers of debian are looking at adopting it. Both GGI and FB would be nice though, as it should be fairly easy to port over the SDL after that point and a good deal of applications are already designed to work with the SDL. Also, the linux FB layer seems to be heading for a very big rewrite for linux 2.5 in regards to capabilities. Though I am not really clear on everything it is supposed to do. Paul or someone else working with it could give better input on that. On Mon, Feb 19, 2001 at 12:55:42AM -0800, David Jeske wrote: > Regarding this graphics 'servers vs. libs' discussion. I recommend > taking a look at what the linux libGGI did with a creative library > stuff. It certainly had a server component (in the form of X, or a > kernel driver), however, they did some neat stuff by making the libggi > library the focus of the user-level programs. They could easily be > retargeted to different displays by GGI changing the way the library > was bound. > > ..back to lurking. > > -- > David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net > -- "That is precisely what common sense is for, to be jarred into uncommon sense." ++ Eric Temple Bell, Mathmatics: Queen of the Sciences Mark Ferrell : Major'Trips' Programmer : Chaotic Dreams Development Team URL : http://www.chaoticdreams.org E-Mail : major@chaoticdreams.org From daemon Mon Feb 19 14:02:37 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1JE2bB16934 for vsta-xplod; Mon, 19 Feb 2001 14:02:37 GMT Received: from mel-b.jpl.nu (root@[194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1JE2XE16914 for ; Mon, 19 Feb 2001 14:02:33 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1JMMOg03239 for ; Mon, 19 Feb 2001 23:22:24 +0100 Date: Mon, 19 Feb 2001 23:22:24 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: problems with vstafs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi, I've been having a lot of trouble with vstafs. I've created a vstafs according to the faq and it mounts in all right. But when I copy big files(like >100bytes) to it the wd server dies (and the vstafs server dies subsequently of course). I can create directories and copy very small files to it and it works. but it's quite unusable... I've tried it on 3 different computers and both LBA drives and non-lba drives. So I don't think it's a hardware problem. /Erik From daemon Tue Feb 20 09:04:43 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1K94h618423 for vsta-xplod; Tue, 20 Feb 2001 09:04:43 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1K94ZE18416; Tue, 20 Feb 2001 09:04:37 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA21477; Tue, 20 Feb 2001 09:21:17 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102201721.JAA21477@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: problems with vstafs In-reply-to: Your message of "Mon, 19 Feb 2001 23:22:24 +0100." Date: Tue, 20 Feb 2001 09:21:17 -0800 From: Andy Valencia [Erik Dalen writes:] >I've been having a lot of trouble with vstafs. I've created a vstafs >according to the faq and it mounts in all right. But when I copy big >files(like >100bytes) to it the wd server dies (and the vstafs server >dies subsequently of course). I can create directories >and copy very small files to it and it works. but it's quite unusable... >I've tried it on 3 different computers and both LBA drives and non-lba >drives. So I don't think it's a hardware problem. I have an idea of what this is... can you go into the vstafs source and re-build it? Let me know if that version of the executable still shows the problem. Thanks, Andy From daemon Tue Feb 20 11:58:05 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1KBw5Y22283 for vsta-xplod; Tue, 20 Feb 2001 11:58:05 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1KBw1E22263; Tue, 20 Feb 2001 11:58:01 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1KKHsW03259; Tue, 20 Feb 2001 21:17:54 +0100 Date: Tue, 20 Feb 2001 21:17:46 +0100 (CET) From: Erik Dalen To: Andy Valencia cc: vsta@zendo.com Subject: Re: problems with vstafs In-Reply-To: <200102201721.JAA21477@vandys-pc.zendo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Feb 2001, Andy Valencia wrote: > I have an idea of what this is... can you go into the vstafs source and > re-build it? Let me know if that version of the executable still shows the > problem. > Nope, now it works just fine :) Kristoffer has updated the vstafs grup patch to the newest version of gnu grub (0.5.96.1), so we can even boot from the vstafs partition now. We're going to send the patch to the main grub developers so they might include it in coming releases of grub. Until then you can download at: http://www.jpl.nu/~erik/vsta/grub-0.5.96.1.vstafs.patch.gz after you have patched it you have to run automake and autoconf so the makefiles are updated. /Erik From daemon Tue Feb 20 12:20:08 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1KCK8C22346 for vsta-xplod; Tue, 20 Feb 2001 12:20:08 GMT Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by bodhi.zendo.com (8.10.1/8.10.1) with SMTP id f1KCK5E22326 for ; Tue, 20 Feb 2001 12:20:05 GMT Received: from 103bus37.tampabay.rr.com (HELO jim) (24.94.103.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Feb 2001 20:37:29 -0000 X-Apparently-From: From: "James Northrup" To: Subject: re: Servers vs. Libs Date: Tue, 20 Feb 2001 15:37:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 My take on remote displays is to, at least once, achieve the fascist minimum latency of a distributed display operation. I'm considering the far server extremity, which is to interface the packet inbound and reassembly queue directly with the graphics pipelines and dma. I'm guessing packets arriving in a packet reassembly queue are aligned but the ensuing stripped data buffers are merely copies that have been re-aligned . Routers may in fact re-map a packet entirely for an outbound packet queue. When a library or user space program recv's a buffer of data it has not had the privilege of insuring the data's alignment. By tapping into kernel mode operations and building a stovepipe from the network to the graphics subsystems we may bypass the context switch of user-space and simply apply buffers that have been scheduled and pre-arranged by the user-space code running at a very high frame rate with very small needs relative to the volume of data being moved. I wouldn't suggest that a small pc firewall would like to insert a graphics packet filter into its reassembly queue. But who needs to service disk, if audio and display data is pouring in unencumbered and intercepted before context switch is invoked. Finally, for portability concerns, there is no doubt in my mind that a lock-tight hardware description of a graphics context -- be it a 3d rendering pipeline or a bitmap staging area, GGI stream or otherwise can be described by a corba namespace which accounts for a driver,platform,and version, and register information. I would consider the fallback to a hardware-optimized remote display to be a very convenient VNC, GGI, or X11 alternative, but I don't imagine that any user space solution could address the specialized network considerations as efficiently without breaking some eggs. It may be a breakthrough in game engines to build a kernel with such a bias, and a rendering engine with a very complete vocabulary of network primitives to render high speed openGL by directing network traffic. it could possibly render java Swing components faster on a 200mhz switched network than on a 200 mhz Pentium mmx with a decent display adapter. Network Switches are sub-$100. Late model CPU and RAM and disks are $$$++; Back to the devil's advocacy for me.. -----Original Message----- From: David Jeske [mailto:jeske@chat.net] Sent: Monday, February 19, 2001 3:56 AM To: vsta@zendo.com Subject: Re: Servers vs. Libs Regarding this graphics 'servers vs. libs' discussion. I recommend taking a look at what the linux libGGI did with a creative library stuff. It certainly had a server component (in the form of X, or a kernel driver), however, they did some neat stuff by making the libggi library the focus of the user-level programs. They could easily be retargeted to different displays by GGI changing the way the library was bound. ..back to lurking. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From daemon Tue Feb 20 19:27:06 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1KJR6P22919 for vsta-xplod; Tue, 20 Feb 2001 19:27:06 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1KJR3E22912 for ; Tue, 20 Feb 2001 19:27:04 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id TAA22424 for ; Tue, 20 Feb 2001 19:44:23 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102210344.TAA22424@vandys-pc.zendo.com> To: vsta@vsta.org Subject: New WWW site is up and running Date: Tue, 20 Feb 2001 19:44:23 -0800 From: Andy Valencia Courtesy of Erik Dalen, the newly redesigned web site has been switched on. Please have a look and tell us about anything which is broken or missing. And many thanks, of course, to Erik for his work on this project! Enjoy, Andy Valencia From daemon Wed Feb 21 19:48:16 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1LJmG325424 for vsta-xplod; Wed, 21 Feb 2001 19:48:16 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1LJm9E25416; Wed, 21 Feb 2001 19:48:10 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id UAA24264; Wed, 21 Feb 2001 20:05:32 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102220405.UAA24264@vandys-pc.zendo.com> To: "nymia" cc: vsta@zendo.com Subject: Re: Doxygen Doc of VSTa In-reply-to: Your message of "Tue, 20 Feb 2001 20:52:01 PST." <00c401c09bc2$09caa4d0$ed41e1cf@adpquqv2q96s9h> Date: Wed, 21 Feb 2001 20:05:32 -0800 From: Andy Valencia ["nymia" writes:] >I just uploaded a zip copy of the documentation. It's at: >http://members.fortunecity.com/nymia/vsta/html.zip While this location isn't reachable for the world, I've placed a copy at: ftp://ftp.vsta.org/pickup/doxygen.tz for general consumption. Enjoy! Andy Valencia From daemon Fri Feb 23 01:19:29 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1N1JTK28151 for vsta-xplod; Fri, 23 Feb 2001 01:19:29 GMT Received: from mel-b.jpl.nu (root@lgh11.nornan.ac.se [194.165.252.37]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1N1JPE28131 for ; Fri, 23 Feb 2001 01:19:25 GMT Received: from localhost (erik@localhost) by mel-b.jpl.nu (8.11.2/8.11.2) with ESMTP id f1N9dcM20256 for ; Fri, 23 Feb 2001 10:39:38 +0100 Date: Fri, 23 Feb 2001 10:39:38 +0100 (CET) From: Erik Dalen To: vsta@zendo.com Subject: QNX for download now as well Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi QNX has released the QNX realtime platform for non-commercial use. (Binaries only). but I suppose some of you might be interested in checking it out as it's a very neat microkernel OS. (Don't abandon VSTa though!) /Erik From daemon Fri Feb 23 09:30:15 2001 Received: (from daemon@localhost) by bodhi.zendo.com (8.10.1/8.10.1) id f1N9UFT28745 for vsta-xplod; Fri, 23 Feb 2001 09:30:15 GMT Received: from vandys-pc.zendo.com (vandy-frame1.cisco.com [171.70.231.18]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id f1N9U7E28738; Fri, 23 Feb 2001 09:30:07 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id JAA28306; Fri, 23 Feb 2001 09:47:34 -0800 (PST) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200102231747.JAA28306@vandys-pc.zendo.com> To: Erik Dalen cc: vsta@zendo.com Subject: Re: QNX for download now as well In-reply-to: Your message of "Fri, 23 Feb 2001 10:39:38 +0100." Date: Fri, 23 Feb 2001 09:47:34 -0800 From: Andy Valencia [Erik Dalen writes:] >QNX has released the QNX realtime platform for non-commercial use. >(Binaries only). but I suppose some of you might be interested in checking >it out as it's a very neat microkernel OS. (Don't abandon VSTa though!) Speaking as the guy who first ported Neutrino to a non-x86 platform (it was MIPS, and I was sitting in a cubicle at their site in Kenata), I can honestly say that their system has some amazing innovations, especially in the area of real time operating system design. Out of consideration for Intellectual Property, and out of simple respect for a really neat group of people at QNX, I've actively avoided even a hint of putting their approaches to problems into VSTa. If you don't mind closed source, and especially if you need to license something for a commercial environment, you could do far, far worse than going with QNX's products. On a side note, one of QNX's early employees and the author of many of their most prominent technical papers, Dan Hildebrand, was a long-time reader of this list. It was a great honor to work with him. Sadly, Dan passed away a couple years ago, but by a fortunate coincidence I was in Canada around that time and was able to attend his funeral. His keen and kindly mind is missed by many. Regards, Andy Valencia