From vandys@glare.cisco.com Wed May 4 09:03:54 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA08689; Wed, 4 May 1994 09:03:53 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA04763; Wed, 4 May 1994 08:49:11 -0700 Message-Id: <199405041549.IAA04763@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: dos server deaths In-Reply-To: Your message of "Wed, 04 May 1994 14:33:30 BST." Date: Wed, 04 May 1994 08:49:10 -0700 From: Andrew Valencia [Dave Hudson writes:] > Boot process 8 dies >Process 8 is my dos server :-( >If I then use q I go back to the command prompt and the dos server is still >there quite happily :-) Aha! No, everything is quite peachy, I just need to fix my debug code. You see, filesystem servers need to tell the kernel to uncache executable images when they're trying to delete them (the kernel holds an open port to the image while it's cached). So, the server wants to make a kernel request, but the kernel, as a part of trying to uncache the executable, turns around and sends a MSG_DISCONNECT back to the server. But the server is busy making the uncache request call, so you deadlock. The way I deal with this is to start a new thread, and have *him* make the uncache request. Thus, the main server thread gets to continue, sees the MSG_DISCONNECT and cleans up, and that other thread then dies. I guess the trap to kernel debugger should only be for the case of the *last* thread dying inside a boot server. I'll correct this for the next release. For now, either let the kernel continue or go take the debug code (I think it's in os/kern/proc.c) out. If you look at the code for the C library unlink() call, it checks for EAGAIN and does indeed sleep and retry. It does this so it can leave time for the uncache to happen, if needed. Andy From vandys@glare.cisco.com Wed May 4 10:17:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA08697; Wed, 4 May 1994 10:17:47 -0700 Received: from hof (root@hof.daimi.aau.dk [130.225.16.167]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA07217 for ; Wed, 4 May 1994 10:03:11 -0700 Received: by hof (Linux Smail3.1.28.1 #1) id m0pykNb-0002fxC; Wed, 4 May 94 19:05 MET DST Message-Id: Date: Wed, 4 May 94 19:05 MET DST From: tthorn@daimi.aau.dk (Tommy Thorn) To: vsta@cisco.com Subject: Re: dos server deaths In-Reply-To: <199405041549.IAA04763@glare.cisco.com> References: <199405041549.IAA04763@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Andrew Valencia writes: > [Dave Hudson writes:] > > > Boot process 8 dies > >Process 8 is my dos server :-( > >If I then use q I go back to the command prompt and the dos server is still > >there quite happily :-) Strange. For me the dos server *really* dies, just as soon as I do anything non-trivial, say: $ cd /vsta $ echo 'main(){printf("HW\n");}' hw.c $ gcc -v hw.c ... ld /vsta/lib/crt0.o hw.o -lc Boot process 8 dies [Kernel debugger] >pr ... 8 dos 9 ONPROC kstack ... wchan 0 / ... >q [Returning from debugger] (nothing happens) ^Z [Kernel debugger] >pr ... 8 dos 6 swap ... >pr 8 8 dos vas .... threads 0 runq ... ... This is on a freshly formatted ms-filesystem which only contains command.com, two .sys file, vsta.tz and vsta_bin.tz (both unpacked as directed in the roadmap.txt). The computer is a 386 sx/16 Mhz w. 4 Mb. The ms-dos filesystem is of size 10 Mb. I runs Linux daily w/o prob. I know it's a lousy help, as I'm currently unable to recompile VSTa, and thus, debug it further. If someone did setup a Linux cross- compilation environment, I would love a copy. /Tommy From vandys@glare.cisco.com Fri May 6 16:53:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00104; Fri, 6 May 1994 16:53:31 -0700 Received: from mail.swip.net (mail.swip.net [192.71.220.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id RAA08193 for ; Fri, 6 May 1994 17:40:18 -0700 Received: by mail.swip.net (8.6.8/2.01) id CAA13331; Sat, 7 May 1994 02:40:10 +0200 Received: by distinct.se (4.1/KTH-1.1) id AA01477; Sat, 7 May 94 02:36:48 +0100 From: lars@distinct.se (Lars Pensjo) Message-Id: <9405070136.AA01477@distinct.se> Subject: tty and more To: vsta@cisco.com Date: Sat, 7 May 94 2:36:47 BST X-Mailer: ELM [version 2.3 PL0] I have looked a little at the way the tty is handled, and have some questions. I haven't looked very thorough, so please be patient with misunderstandings. It seems a lot of input and output processing is handled by libc instead of a driver. Is this a temporary solution, or the way it is supposed to be ? There will be problems, like no echo when typing characters ahead. I like the SYSV model, using STREAMS. The idea is to have a "basic" device driver, which only does the hardware communication. On this driver, you push another protocol which implements other things. In the tty case, the pushed handler would take care of CR-NL mapping, echo, erasing characters etc. This model seems to be close to the way VSTa is working, or could be working. The filesystem for example, consists of a low level hardware device driver, with a filesystem manager "pushed" onto it. Communication is done through messages. Another benefit of having a special server taking care of input and output processing, is that it can be used elsewhere. For example, when defining pseudo ttys. A pseudo tty could maybe simply be created by pushing such a handler on a pipe ? The Gnu readline functionality could be implemented as a server to be pushed onto a tty, instead of building it into the shell or libc. The STREAMS mechanism in SYSV is very fast. Would a similar mechanism based on messages involve too much overhead ? Now to another thing: The kernel is small and nice, as it only has a limited number of responsibilities. Among these are process management and memory management. It seems there are no general ways to access these informations. Implementing a 'ps' program would need some kind of access. Of course, implementing 'ps' using a /proc filesystem is even better, but that driver will need the kernel information access instead. It seems the kerner doesn't accept any messages by itself. I don't very much like the old unix idea of a /dev/kmem. It is flexible, not a pretty solution. Is there maybe a more general solution ? Yet another discussion: some people wants automatic backups of files, with maybe a whole series with version number like VMS. Could this be implemented through a server that is pushed onto another file system ? ---- Lars Pensj| lars@distinct.se From vandys@glare.cisco.com Fri May 6 20:46:01 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00115; Fri, 6 May 1994 19:25:00 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA06276; Fri, 6 May 1994 20:11:48 -0700 Message-Id: <199405070311.UAA06276@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: lars@distinct.se (Lars Pensjo) Cc: vsta@cisco.com Subject: Re: tty and more In-Reply-To: Your message of "Sat, 07 May 1994 02:36:47 -0000." <9405070136.AA01477@distinct.se> Date: Fri, 06 May 1994 20:11:48 -0700 From: Andrew Valencia [lars@distinct.se (Lars Pensjo) writes:] >It seems a lot of input and output processing is handled by libc instead of >a driver. Is this a temporary solution, or the way it is supposed to be ? >There will be problems, like no echo when typing characters ahead. This is the way I intended it. Deviating from UNIX's typeahead echo behavior is not that big a deal--for instance, you don't get typeahead echoing in most applications these days anyway, since most applications seem to run in raw/cbreak/noecho modes. I decided that I could live with incompatibility in this area. >I like the SYSV model, using STREAMS. I hate streams. It is complex, especially in the areas of flow control and out-of-band messages. I also hate code in the kernel--I'm assuming that you didn't mean you wanted VSTa to emulate that part of streams! I've supported streams stuff for a living in past lives, and--like the Plan 9 folks--don't particularly like it. >The idea is to have a "basic" device >driver, which only does the hardware communication. On this driver, you >push another protocol which implements other things. In the tty case, the >pushed handler would take care of CR-NL mapping, echo, erasing characters etc. Such layered functionality be easy enough to emulate in VSTa, since the TTY processing is in a library in ring 3. Code it up and then add it as a new file descriptor layer. >This model seems to be close to the way VSTa is working, or could be working. >The filesystem for example, consists of a low level hardware device driver, >with a filesystem manager "pushed" onto it. Communication is done through >messages. You *could* push all of it out to another server. There sort of needs to be such a server anyway--to map ^C and stuff to events. But VSTa's design philosophy was to push the code as far "forward" in ring 3 as possible. Thus, code in your address space in preference to code in your own server, in preference to a system server, in preference to the kernel. >Another benefit of having a special server taking care of input and output >processing, is that it can be used elsewhere. For example, when defining >pseudo ttys. A pseudo tty could maybe simply be created by pushing such a >handler on a pipe ? Since the C library takes a raw data stream (with type=c) and puts a TTY interpretation onto it, pty's are even easier since all they have to present is a raw data stream. >The Gnu readline functionality could be implemented as a server to be pushed >onto a tty, instead of building it into the shell or libc. Why a different server? It works pretty well in a library. It isn't built into the shell; it's in the library. The intent has always been to use shared libraries; it's pretty much known how to do this, it's just that nobody has gotten around to it--yet. We might have to agree to disagree here--I put things in the library in preference to in another server. Libraries are fast to call, easy to debug, and easy to replace. >The STREAMS mechanism in SYSV is very fast. Would a similar mechanism based >on messages involve too much overhead ? Streams is very slow and clunky. Sequent multiprocessor streams with a couple CPUs tossed in worked pretty smoothly (would that we could all afford such hardware!). It's also *very* easy to break, and it has tons of painful edge conditions. >Now to another thing: The kernel is small and nice, as it only has a limited >number of responsibilities. Among these are process management and memory >management. It seems there are no general ways to access these >informations. Implementing a 'ps' program would need some kind of access. >Of course, implementing 'ps' using a /proc filesystem is even better, but that >driver will need the kernel information access instead. Someone is working on a pstat() system call which will use a defined interface to extract state. He is indeed planning on doing a /proc server to then provide this information to the rest of the system. I helped create pstat() for HP/UX, and it worked out pretty well. >It seems the kerner doesn't accept any messages by itself. I don't very much >like the old unix idea of a /dev/kmem. It is flexible, not a pretty >solution. Right. Where practical, the kernel provides mechanism. The server provide policy. Interpreting messages is policy, and pstat() should really suffice. /dev/kmem would never fly anyway--too many race conditions in accessing values, especially in a kernel where most data structures are allocated dynamically. VSTa is coded for symmetric multiprocessing, which makes it even worse. >Yet another discussion: some people wants automatic backups of files, with >maybe a whole series with version number like VMS. Could this be implemented >through a server that is pushed onto another file system ? Backups are a part of a number of related storage management issues. It would easy to provide virtual disks ("volumes") with one or more storage entities ("plexes") below them. Plexes are then made of ranges of subdisks, which are parts of real physical disks. So if you have two plexes under a volume, you have a mirror. If you then disassociate one, you have taken a snapshot. You can put it under some other volume and dump it off to tape. A cool variation is where you don't really have all that disk, but the volume management uses copy-on-write tricks to provide the illusion of a second plex long enough to write it to tape. This is fun to implement until you start hitting exceptional conditions (I/O errors and power hits) during changes in configuration. Like you add a second plex to a volume, and it starts pulling a copy of the current data from the first plex to get up to date, and then the power goes out. You have to keep state so the right plex's data gets honored for the volume on restart, and the second plex picks up (roughly) where it left off. You might be happy with the Berkeley RAID code, at least as a starting point. I've never worked with this code myself--most of my experience is with Veritas. But I've read a lot about it and you may as well steal from it if the source is unencumbered. Regards, Andy From vandys@glare.cisco.com Sat May 7 03:27:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA00084; Sat, 7 May 1994 03:27:32 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA25072 for ; Sat, 7 May 1994 04:14:22 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08032; 7 May 94 12:11 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pzjTw-0003OmC; Sat, 7 May 94 11:19 BST Message-Id: From: Dave Hudson Subject: Re: tty and more To: Lars Pensjo Date: Sat, 7 May 1994 11:19:40 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <9405070136.AA01477@distinct.se> from "Lars Pensjo" at May 7, 94 02:36:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2269 I'll leave the tty bit for now - I've taken a quick look at the top level libc code, but after some recent discussions with Andy I think that there needs to be some more work to get a more complete implementation. I submitted a small patch to get non-blocking I/O to run OK to the rs232 server (which is what I was really working on), but other than that I guess there's still some code to be written. Lars Pensjo wrote: > > Now to another thing: The kernel is small and nice, as it only has a limited > number of responsibilities. Among these are process management and memory > management. It seems there are no general ways to access these > informations. Implementing a 'ps' program would need some kind of access. > Of course, implementing 'ps' using a /proc filesystem is even better, but that > driver will need the kernel information access instead. > > It seems the kerner doesn't accept any messages by itself. I don't very much > like the old unix idea of a /dev/kmem. It is flexible, not a pretty > solution. > > Is there maybe a more general solution ? I believe Robert Mayer is looking at adding the necessary system call to get these sort of details back into user space. This would then allow a proc fs to be written. One advantage with VSTa's structure is that any other process stats (above and beyond kernel data) can be provided by the servers themselves. > Yet another discussion: some people wants automatic backups of files, with > maybe a whole series with version number like VMS. Could this be implemented > through a server that is pushed onto another file system ? I don't see why this should be a problem. Plan 9 has a mechanism to do exactly this. I think that the pathnames provided by the Plan 9 server are based on the date (I don't have the docs handy) - I believe the idea's something like: /arc/09JAN94/fred/abcd.c /arc/10APR94/fred/abcd.c The first path would give "abcd.c" as it was on the 9th January and the second would give "abcd.c" as it was on the 10th April. Perhaps in a VSTa implementation there could be a "stat" field that could record exactly which version of a file we have once we open it. Certainly layering fs's shouldn't be problem - I do exactly this when I'm working of bfs. Regards, Dave From vandys@glare.cisco.com Sat May 7 15:12:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA00174; Sat, 7 May 1994 15:12:18 -0700 Received: from mail.swip.net (mail.swip.net [192.71.220.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id PAA04861 for ; Sat, 7 May 1994 15:59:11 -0700 Received: by mail.swip.net (8.6.8/2.01) id AAA26268; Sun, 8 May 1994 00:59:09 +0200 Received: by distinct.se (4.1/KTH-1.1) id AA03145; Sat, 7 May 94 23:44:24 +0100 From: lars@distinct.se (Lars Pensjo) Message-Id: <9405072244.AA03145@distinct.se> Subject: Re: tty and more To: vsta@cisco.com Date: Sat, 7 May 94 23:44:23 BST In-Reply-To: <199405070311.UAA06276@glare.cisco.com>; from "Andrew Valencia" at May 6, 94 8:11 pm X-Mailer: ELM [version 2.3 PL0] >>It seems a lot of input and output processing is handled by libc instead of >>a driver. Is this a temporary solution, or the way it is supposed to be ? > > This is the way I intended it. Deviating from UNIX's typeahead echo > behavior is not that big a deal--for instance, you don't get typeahead > echoing in most applications these days anyway, since most applications seem > to run in raw/cbreak/noecho modes. I use maybe 'sh' most of all, and it is not running in raw mode. I am playing with VSTa remotely from my home through a modem to a PC at my job, using a COM port. This works quite good, except I can't reboot VSTa if needed. >>I like the SYSV model, using STREAMS. > ... > I also hate code in the kernel--I'm assuming that you > didn't mean you wanted VSTa to emulate that part of streams! Oh no, I really agree that all code should be pushed as far out as possible. I didn't mean I liked the STREAMS implementation, but rather the idea of layering. > ... > There sort of needs to be > such a [tty] server anyway--to map ^C and stuff to events. But VSTa's design > philosophy was to push the code as far "forward" in ring 3 as possible. But a server is needed for some stuff, isn't it ? If that is the case, it might as well handle all signals generated by the keyboard. Then we have the question of where to put other input and output processing. The benefit of putting it in libc is that it is pushed out as far as possible, and servers are kept as small as possible. The benefit of having input and output processing in this extra server would be that it is much easier for a user to create and replace it with his favorite processing. The processing would also be asynchronous, enabling you to use typeahead. There is a standard list of signals possible to generate by the keyboard. It is probably possible to change this list ! It seems VSTa has defined signals as strings, making it possible to add and define your own types ? >>The Gnu readline functionality could be implemented as a server to be pushed >>onto a tty, instead of building it into the shell or libc. > > Why a different server? It works pretty well in a library. It isn't built > into the shell; it's in the library. The intent has always been to use > shared libraries; it's pretty much known how to do this, it's just that > nobody has gotten around to it--yet. I don't claim the readline interface is the one and true thing, but it is interesting as a reference for how to solve similar problems. If you put the readline functionality in libc, then all programs as well as all users get it, either they want it or not. Someone wanting something similar but not exactly the same would have to change the libc and recompile a lot. This also implies that a user wanting to add a different kind of readline interface would have to have access to the libc source code, as well as be able to recompile all programs using the tty interface in cooked mode. Best regards, Lars Pensj| From vandys@glare.cisco.com Tue May 10 03:36:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA00727; Tue, 10 May 1994 03:36:15 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA08544 for ; Tue, 10 May 1994 04:23:13 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa14396; 10 May 94 12:15 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q0pl4-0002psC; Tue, 10 May 94 12:13 BST Message-Id: From: Dave Hudson Subject: Manual pages To: VSTa mailing list Date: Tue, 10 May 1994 12:13:53 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 801 Hi All, I don't think there's been any discussion of which sections are used for which types of manual page. Have I missed anything? I guess the section numbers will be something like Plan 9: 1) General commands 2) Library functions 3) Kernel devices 4) File services 5) Plan 9 file protocol 6) File formats 7) Databases and database access 8) Administative commands 9) Raster image software 10) Cct design software I'd guess something similar would be good, perhaps: 1) General commands 2) Library functions 3) Machine specific device servers 4) Machine independent servers 5) VSTa file protocol 6) File formats 7) Database files 8) Administrative commands Does anyone have any comments? Has anyone (apart from Andy) started writing manual pages yet :-) Regards, Dave From vandys@glare.cisco.com Tue May 10 04:48:02 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00736; Tue, 10 May 1994 04:48:01 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA10890 for ; Tue, 10 May 1994 05:35:08 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA04062; Tue, 10 May 94 08:34:27 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA17493; Tue, 10 May 94 08:34:27 EDT Date: Tue, 10 May 94 08:34:27 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405101234.AA17493@ebt.com> To: vsta@cisco.com In-Reply-To: Dave Hudson's message of Tue, 10 May 1994 12:13:53 +0100 (BST) Subject: Manual pages I certainly haven't written any manual pages yet. Actually, I question whether the normal nroff format is a good or bad idea. I think we have the technology available now to do something a little better. Anyway, I think the basic organisation Dave outlined would be OK; it's close enough to Unix to be easy to understand... From vandys@glare.cisco.com Tue May 10 05:11:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00739; Tue, 10 May 1994 05:11:56 -0700 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA11439 for ; Tue, 10 May 1994 05:59:05 -0700 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 10 May 94 14:59:03+0200 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 10 May 94 14:59:28-0100 Date: 10 May 94 14:59:28-0100 From: Basile STARYNKEVITCH Message-Id: <9405101259.AA00780@rosser.serma.cea.fr> To: gtn@ebt.com Cc: vsta@cisco.com In-Reply-To: <9405101234.AA17493@ebt.com> Subject: Re: Manual pages Content-Length: 1263 Gavin Nicol wrote: #> References: <"Dave Hudson(039)s message of Tue*"@MHS> #> #> I certainly haven't written any manual pages yet. Actually, I question #> whether the normal nroff format is a good or bad idea. I think we have #> the technology available now to do something a little better. Perhaps HTML would be an interesting candidate. Also, gnu texi or info files could be ok. I do agree than nroff is not a very interesting online documentation format. My biaised opinion is for GNU texinfo format --but it is just because i know it better. I don't know much about HTML (but did read books on SGML upon which, as i understand, is based HTML; i found SGML much too complex to be really interesting!). Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 Not yet VSTa-ling but already linuxing at home only. I hope to try VSTa in a month or two (after buying a 1gb disk). N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. From vandys@glare.cisco.com Tue May 10 07:08:28 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00752; Tue, 10 May 1994 07:08:26 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA15015 for ; Tue, 10 May 1994 07:55:34 -0700 Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.4/8.6.4) with SMTP id HAA01003; Tue, 10 May 1994 07:55:30 -0700 Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA09778; Tue, 10 May 94 08:55:26 MDT Message-Id: <9405101455.AA09778@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 10 May 1994 08:55:26 MDT In-Reply-To: Basile STARYNKEVITCH ' <9405101259.AA00780@rosser.serma.cea.fr> Re: Manual pages Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Basile STARYNKEVITCH , gtn@ebt.com Subject: Re: Manual pages Cc: vsta@cisco.com From: Basile STARYNKEVITCH Subject: Re: Manual pages > Gavin Nicol wrote: > > #> References: <"Dave Hudson(039)s message of Tue*"@MHS> > #> > #> I certainly haven't written any manual pages yet. Actually, I question > #> whether the normal nroff format is a good or bad idea. I think we have > #> the technology available now to do something a little better. > > Perhaps HTML would be an interesting candidate. Also, gnu texi or info > files could be ok. I do agree than nroff is not a very interesting > online documentation format. At Cygnus we're using texinfo. This single source we translate using filters to info, dvi, ps, and now html. We're putting all the GNU docs up under WWW. URL=http://www.cygnus.com/ I'd suggest we use info for online docs. [tng]roff is tolerable for exisiting man pages, but I just started trying "RosettaMan" which translates nroff to html. (works good too). > My biaised opinion is for GNU texinfo format --but it is just because > i know it better. I don't know much about HTML (but did read books on > SGML upon which, as i understand, is based HTML; i found SGML much too > complex to be really interesting!). I just learned HTML last week, I find it generally *much* easier to write than raw nroff. Nroff is pretty dense to write in, at least in HTML it's easier to read the doc source and figure out what it does. - rob - From vandys@glare.cisco.com Tue May 10 08:22:25 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00766; Tue, 10 May 1994 08:22:23 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA18071; Tue, 10 May 1994 09:09:32 -0700 Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.4/8.6.4) with SMTP id JAA06063; Tue, 10 May 1994 09:09:29 -0700 Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA10002; Tue, 10 May 94 10:09:25 MDT Message-Id: <9405101609.AA10002@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 10 May 1994 10:09:25 MDT In-Reply-To: Andrew Valencia ' <199405101533.IAA18608@glare.cisco.com> Re: Manual pages Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia Subject: Re: Manual pages Cc: vsta@cisco.com From: Andrew Valencia Subject: Re: Manual pages > a text formatting system whose ability to generate readable output from > source approximates a "cat" of a file. groff was rejected on this basis. I > have little experience with TeX (did I capitalize it correctly?) but I seem > to recall that it was HUGE. Tex *is* huge, but that's only needed for camera ready output. The "makeinfo" program is pretty small. I processes the .texi source to be an ASCII flat file called an "info' file. Then use use the "info" program, (also small or as part of emacs). Info is a pusedo hypertext based reader, you cam search for things too. Much easier and smaller than the [ntg]roff mess. Just compiling groff is a pain in the ass. (it breaks G++ weekly it seems) > pages are meant to be viewed quickly, so whatever technology we use should Info pages are *always* processed, and can be gzipped. The best thing is that if the VSTa docs are in texinfo format, we'd be able to easily produce multiple outputs from *one* source. For an example of HTML produced from Texinfo, look at my Home Page URL=http://darkstar.cygnus.com/rob.html under the "DejaGnu" link. That's the DejaGnu manual in HTML as made by texi2html. (still needs a little hand tweaking) Also look at http://www.cygnus.com/ for other examples. - rob - From vandys@glare.cisco.com Tue May 10 08:58:45 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00772; Tue, 10 May 1994 08:58:44 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA19973 for ; Tue, 10 May 1994 09:45:53 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA06621; Tue, 10 May 94 12:45:12 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA19751; Tue, 10 May 94 12:45:11 EDT Date: Tue, 10 May 94 12:45:11 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405101645.AA19751@ebt.com> To: vsta@cisco.com In-Reply-To: Rob Savoye's message of Tue, 10 May 1994 10:09:25 MDT <9405101609.AA10002@darkstar.cygnus.com> Subject: Manual pages Yeeks. It seems that I have started a religous war. For what it's worth, I know a fair bit about all the systems mentioned. DOing man pages in HTML is out for 2 reasons: 1) There are no good TTY HTML browsers available (lynx is not "good") 2) HTML is not good SGML. HTML is kind of like a readable ROFF in that it specifies formattting over structure. My experiences with both techinfo have been good. The only major gripes I have with it are about navigation, and the info browser UI. If all the man pages were justsingle pages, I think we might be able to get a reasonable output, and reasonable speed. I also have a man page to texinfo converter (rough but workable on a lot of man pages). The other alternative is to define an SGML DTD for man pages for VSTa, and use that. The result would be something like an easily parsable LaTeX. Something that could be formatted on the fly easily, or used to produce printed pages if needed. Thoughts? From vandys@glare.cisco.com Tue May 10 07:46:02 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00756; Tue, 10 May 1994 07:46:00 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA18608; Tue, 10 May 1994 08:33:10 -0700 Message-Id: <199405101533.IAA18608@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: rob@cygnus.com Cc: vsta@cisco.com Subject: Re: Manual pages In-Reply-To: Your message of "Tue, 10 May 1994 08:55:26 MDT." <9405101455.AA09778@darkstar.cygnus.com> Date: Tue, 10 May 1994 08:33:10 -0700 From: Andrew Valencia [rob@darkstar.cygnus.com (Rob Savoye) writes:] > At Cygnus we're using texinfo. I'm not tremendously attached to roff-ish text formatting, but I *do* want a text formatting system whose ability to generate readable output from source approximates a "cat" of a file. groff was rejected on this basis. I have little experience with TeX (did I capitalize it correctly?) but I seem to recall that it was HUGE. I also want to avoid the complexity of the manX/catX for caching text. Man pages are meant to be viewed quickly, so whatever technology we use should generate its output quickly, not generate it so slowly that you have to go back and add kludges to make up for its (lack of) performance. Note, these comments apply exclusively to man pages. The requirements of a "tip of the finger" documentation reference system are unique, and I think the choices you've outlined here are great for README, Info, papers, and so forth. Andy From vandys@glare.cisco.com Tue May 10 09:12:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00775; Tue, 10 May 1994 09:12:05 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA20629 for ; Tue, 10 May 1994 09:59:15 -0700 Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.4/8.6.4) with SMTP id JAA09366; Tue, 10 May 1994 09:59:13 -0700 Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA10097; Tue, 10 May 94 10:59:11 MDT Message-Id: <9405101659.AA10097@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 10 May 1994 10:59:11 MDT In-Reply-To: gtn@ebt.com (Gavin Nicol)' <9405101645.AA19751@ebt.com> Manual pages Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: gtn@ebt.com (Gavin Nicol), vsta@cisco.com Subject: Re: Manual pages From: gtn@ebt.com (Gavin Nicol) Subject: Manual pages > If all the man pages were justsingle pages, I think we might be able > to get a reasonable output, and reasonable speed. I also have a man > page to texinfo converter (rough but workable on a lot of man pages). As far as info browsers go, you can choose from info, emacs, Tkinfo. We use info for hypertext in a tty, and then TkWWW, chimera, xmosaic for HTML. I just think that ussing texinfo is as close as we can get at this time to a portable doc format. We can decide on which output format to use later... - rob - From vandys@glare.cisco.com Tue May 10 11:01:20 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00796; Tue, 10 May 1994 11:01:19 -0700 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA25999 for ; Tue, 10 May 1994 11:45:35 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA11077; Tue, 10 May 1994 20:44:02 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA19630; Tue, 10 May 1994 20:43:42 +0200 Date: Tue, 10 May 1994 20:43:42 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9405101843.AA19630@ibch50.inf.tu-dresden.de> To: vsta@cisco.com Subject: Re: Manual Pages Rob wrote: > Yeeks. It seems that I have started a religous war. For what it's [stuff deleted] > The other alternative is to define an SGML DTD for man pages for VSTa, > and use that. The result would be something like an easily parsable [stuff deleted] >Thoughts I would strongly recomend going this way. 1) For the author SGML is more as simple. 2) A SGML-dokument can be *easy* automatical transformed in almost evrything else. (like roff, TeXinfo...) The applications for that are free avialable. 3) The structure of a man-page is simple, so a small tag-set would be sufficient. 4) For speed it would be a simple task to write a parser, accepting a small SGML-tag-set of point 3) and format it for a tty. But I think the existing applications are as fast as needed. ----------------------------------------------------------------------------- Joerg Wittenberger Rietzstr. 32b 01139 Dresden Germany email: jw@ibch50.inf.tu-dresden.de jw6@mail.inf.tu-dresden.de WWW: jerry PGP PUBLIC KEY: avialable on request or by finger From vandys@glare.cisco.com Tue May 10 12:11:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00839; Tue, 10 May 1994 12:11:53 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA29273; Tue, 10 May 1994 12:59:03 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08157; 10 May 94 20:52 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q0vBg-0002qHC; Tue, 10 May 94 18:01 BST Message-Id: From: Dave Hudson Subject: Re: Manual pages To: Andrew Valencia Date: Tue, 10 May 1994 18:01:44 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199405101533.IAA18608@glare.cisco.com> from "Andrew Valencia" at May 10, 94 08:33:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1077 Andrew Valencia wrote: > > Note, these comments apply exclusively to man pages. The requirements of a > "tip of the finger" documentation reference system are unique, and I think > the choices you've outlined here are great for README, Info, papers, and so > forth. Having written a few man pages for Linux I found I could pick up roff formats reasonably well - the other's all look huge. I just downloaded the SGML tools that the Linux document crowd are using to convert SGML to just about everything else (HTML coming soon apparently) and the compressed sources alone were 340k :-( I think there'd be a practical difficulty there as well as I think it uses flex/lex to build some of the sources (I've no idea about lex so I don't know how easy/difficult it would be to get it running on VSTa). I like the idea that maybe we could find or build a utility to convert roff to one of these more general (I think) formatting systems. Anyway if there are no overriding objections to the locations I suggested I'll start writing a few server man pages. Regards, Dave From vandys@glare.cisco.com Tue May 10 12:44:56 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00846; Tue, 10 May 1994 12:44:55 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id NAA01417; Tue, 10 May 1994 13:32:05 -0700 Received: from darkstar.cygnus.com (darkstar.cygnus.com [192.203.188.2]) by cygnus.com (8.6.4/8.6.4) with SMTP id NAA01429; Tue, 10 May 1994 13:31:59 -0700 Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA10818; Tue, 10 May 94 14:31:56 MDT Message-Id: <9405102031.AA10818@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 10 May 1994 14:31:55 MDT In-Reply-To: Dave Hudson ' Re: Manual pages Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Dave Hudson , Andrew Valencia Subject: Re: Manual pages Cc: VSTa mailing list From: Dave Hudson Subject: Re: Manual pages > I like the idea that maybe we could find or build a utility to convert roff > to one of these more general (I think) formatting systems. I have one, it's called RosettaMan. It translates nroff to html, sgml, ascii, or roff. It's also *really* tiny. You can get it from: ftp.cs.berkeley.edu:/ucb/people/phelps/tcl/rman.tar.Z. - rob - From vandys@glare.cisco.com Tue May 10 12:43:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00843; Tue, 10 May 1994 12:43:05 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA01287; Tue, 10 May 1994 13:30:12 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15806; 10 May 94 21:15 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q0vBg-0002qHC; Tue, 10 May 94 18:01 BST Message-Id: From: Dave Hudson Subject: Re: Manual pages To: Andrew Valencia Date: Tue, 10 May 1994 18:01:44 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199405101533.IAA18608@glare.cisco.com> from "Andrew Valencia" at May 10, 94 08:33:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1077 Andrew Valencia wrote: > > Note, these comments apply exclusively to man pages. The requirements of a > "tip of the finger" documentation reference system are unique, and I think > the choices you've outlined here are great for README, Info, papers, and so > forth. Having written a few man pages for Linux I found I could pick up roff formats reasonably well - the other's all look huge. I just downloaded the SGML tools that the Linux document crowd are using to convert SGML to just about everything else (HTML coming soon apparently) and the compressed sources alone were 340k :-( I think there'd be a practical difficulty there as well as I think it uses flex/lex to build some of the sources (I've no idea about lex so I don't know how easy/difficult it would be to get it running on VSTa). I like the idea that maybe we could find or build a utility to convert roff to one of these more general (I think) formatting systems. Anyway if there are no overriding objections to the locations I suggested I'll start writing a few server man pages. Regards, Dave From vandys@glare.cisco.com Wed May 11 00:19:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA00922; Wed, 11 May 1994 00:19:58 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA24246 for ; Wed, 11 May 1994 01:05:18 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA20517; Wed, 11 May 1994 10:03:22 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA17762; Wed, 11 May 1994 10:02:30 +0200 Date: Wed, 11 May 1994 10:02:30 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9405110802.AA17762@ibch50.inf.tu-dresden.de> To: vsta@cisco.com Subject: Re: Manual pages Dave Hudson wrote: >Having written a few man pages for Linux I found I could pick up roff formats >reasonably well - the other's all look huge. I just downloaded the SGML Maybe the formatter would be reasonable, but for example I can't write roff. It's too complex and unreadable. >tools that the Linux document crowd are using to convert SGML to just about >everything else (HTML coming soon apparently) and the compressed sources >alone were 340k :-( I think there'd be a practical difficulty there as well Me too. That's not the place to explain, but they are on the wrong way. Therefor the system is exploding. >as I think it uses flex/lex to build some of the sources (I've no idea about Wrong. No lex or similar. >lex so I don't know how easy/difficult it would be to get it running on >VSTa). I can't see any problem. >I like the idea that maybe we could find or build a utility to convert roff >to one of these more general (I think) formatting systems. No chance. SGML for example describes the structure of the doc, as the Name of the programm, the synopsis, the references. But it is no formatting system at all. A separete system has to be used to describe, how the parts are to be formatted (like name is in tt font, synopsis is separated by blank line and has a heading SYNOPSIS) >Anyway if there are no overriding objections to the locations I suggested >I'll start writing a few server man pages. Many Thanks for that. Dave Hudson wrote: > I have one, it's called RosettaMan. It translates nroff to html, sgml, >ascii, or roff. It's also *really* tiny. You can get it from: >ftp.cs.berkeley.edu:/ucb/people/phelps/tcl/rman.tar.Z. Sound's interesting. But I can't believe that it translates to SGML. That would require to be intelligent, course it would transform to a higher level of abstraction (or it uses non-good DTD like HTML). From vandys@glare.cisco.com Wed May 11 02:03:22 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA00931; Wed, 11 May 1994 02:03:21 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA26258 for ; Wed, 11 May 1994 02:50:34 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa06937; 11 May 94 10:45 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q1App-0002oZC; Wed, 11 May 94 10:44 BST Message-Id: From: Dave Hudson Subject: Re: Manual pages To: Wittenberger Date: Wed, 11 May 1994 10:44:12 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <9405110802.AA17762@ibch50.inf.tu-dresden.de> from "Wittenberger" at May 11, 94 10:02:30 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 958 Wittenberger wrote: > > No chance. SGML for example describes the structure of the doc, as the > Name of the programm, the synopsis, the references. But it is no > formatting system at all. A separete system has to be used to > describe, how the parts are to be formatted (like name is in tt font, > synopsis is separated by blank line and has a heading SYNOPSIS) Is there a good guide to SGML/HTML, etc on the net anywhere? It sounds like maybe I've misunderstood quite how it fits in? > >Anyway if there are no overriding objections to the locations I suggested > >I'll start writing a few server man pages. > > Many Thanks for that. They're in roff format for now :-) > Dave Hudson wrote: Hmm I think that was Rob actually :-) > > I have one, it's called RosettaMan. It translates nroff to html, sgml, > >ascii, or roff. It's also *really* tiny. You can get it from: > >ftp.cs.berkeley.edu:/ucb/people/phelps/tcl/rman.tar.Z. Regards, Dave From vandys@glare.cisco.com Wed May 11 05:44:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00944; Wed, 11 May 1994 05:44:53 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA07416 for ; Wed, 11 May 1994 06:32:05 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA19022; Wed, 11 May 94 09:31:21 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA28227; Wed, 11 May 94 09:31:20 EDT Date: Wed, 11 May 94 09:31:20 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405111331.AA28227@ebt.com> To: vsta@cisco.com In-Reply-To: Dave Hudson's message of Wed, 11 May 1994 10:44:12 +0100 (BST) Subject: Manual pages >Is there a good guide to SGML/HTML, etc on the net anywhere? It >sounds like maybe I've misunderstood quite how it fits in? No, there are no SGML tutorials that I know of. HTML is very poor SGML because it emphasises format over structure, so it is a poor learning point. If you are really interested, look at "Practical SGML" or "SGML, an authors guide". Basically, SGML is a meta-language, like YACC, but it allows you to write document structure grammars. For example: says that a document contains 0 or more sections, which consist of a title and zero or more paragraphs. titles and paragraphs do not require end tags. An example document:
The Standard IO Library <PARA> The standard IO library .... <PARA> Also, the .... </SECTION> </DOCUMENT> so, if we decided to use SGML for man pages, I, or someone else could write up a really small DTD, which would define the structure of a man page. The formatter would only need to be able to recognise the start and end tags, and perform whatever formatting it desires based on those. For normalised SGML, a simple stack-based formatter suffices because all SGML documents should form a tree when parsed. The beauty is that such documents are entirely formatter independent, and can be converted into almost anything. Converting TROFF to SGMl on the other hand is much harder because TROFF hides a lot of the structure, unless you can rely upon certain constructs (macros) marking sections etc. Oh, BTW, elements in SGML can also have attributes, so you can also attach some semantics to elements, like: <SECTION FONT="helvetica"> Though in general, this is not a good thing to do. However, you could use this to produce something like: <!ELEMENT emph - - (#EMPTY) > <!ATTLIST emph TYPE (bold|italic|underlined|slanted|roman) > I'm not keen on this either.... From vandys@glare.cisco.com Wed May 11 10:05:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00973; Wed, 11 May 1994 10:05:26 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA18883 for <vsta@cisco.com>; Wed, 11 May 1994 10:52:41 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA21854; Wed, 11 May 94 13:51:58 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA01385; Wed, 11 May 94 13:51:56 EDT Date: Wed, 11 May 94 13:51:56 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405111751.AA01385@ebt.com> To: vsta@cisco.com In-Reply-To: Gary Shea's message of Wed, 11 May 1994 11:36:23 -0500 <9405111136.aa04787@cs.ukans.edu> Subject: Manual pages Gary Shea writes: >Gavin Nicol writes: >>>Is there a good guide to SGML/HTML, etc on the net anywhere? It >>>sounds like maybe I've misunderstood quite how it fits in? >> >>No, there are no SGML tutorials that I know of. HTML is very poor SGML >>because it emphasises format over structure, so it is a poor learning >>point. If you are really interested, look at "Practical SGML" or >>"SGML, an authors guide". > >If there are no SGML tutorials, then what are these things you >reference? I'm very confused.... These are not available on the net. You can buy them in bookstores though... > Gary nick From vandys@glare.cisco.com Thu May 12 12:38:48 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01202; Thu, 12 May 1994 12:38:46 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA18111 for <vsta@cisco.com>; Thu, 12 May 1994 13:26:08 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa07523; 12 May 94 21:25 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q1hHS-0003IlC; Thu, 12 May 94 21:22 BST Message-Id: <m0q1hHS-0003IlC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Mirror server? To: VSTa mailing list <vsta@cisco.com> Date: Thu, 12 May 1994 21:22:53 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1846 Hi all, Whilst I was patching "wd" yesterday (to support a second IDE controller card) I had an idea about getting disk mirroring in software (a soft RAID idea). I know that there are some relatively cheap ways of doing this in hardware, but I think a soft solution would offer some possible advantages since it should be possible to mirror to just about any device in software (maybe even a network). Here are a few of my original ideas (I've no idea if they're at all practical- I think they are though): Device 1 Device 2 IDE HDD IDE HDD SCSI HDD SCSI HDD IDE HDD SCSI HDD any HDD network drive I got to thinking that maybe it would be possible to guard against some data loss by mirroring data on the same physical device as well (two copies, maybe one in each of two disk partitions). Finally I thought it should be possible to "stripe" data across a number of devices - ie we provide a mechanism to allow multiple partitions/devices to be joined together via a server to provide one logically larger device. There's no reason (that I can think of) why such a server couldn't handle maybe 3 or 4 devices rather than just 2. The implementation I was thinking of would connect to all of the devices/partitions/files that we'd like to store data on and provide a mechanism whereby these would be seen as one logical device. The server would advertise a port that to all intents and purposes would appear to be any other block device. I know there'd be issues with handling fails (I haven't really looked around to see if there are any good papers on this), but I'd think that VSTa must be a superb environment to tinker with this sort of code. I haven't got time just at the moment to start coding such a server, but it's something that I think would be quite interesting to develop. Any comments? Regards, Dave From vandys@glare.cisco.com Fri May 13 05:20:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01258; Fri, 13 May 1994 05:20:18 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA21428 for <vsta@cisco.com>; Fri, 13 May 1994 06:07:43 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA17766; Fri, 13 May 94 09:06:51 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA00678; Fri, 13 May 94 09:06:51 EDT Date: Fri, 13 May 94 09:06:51 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405131306.AA00678@ebt.com> To: vsta@cisco.com In-Reply-To: Dave Hudson's message of Thu, 12 May 1994 21:22:53 +0100 (BST) <m0q1hHS-0003IlC@humbug.demon.co.uk> Subject: Mirror server? As usual, Dave has some good ideas. I think VSTa is perfect for this kind of "tinkering" as you put it, because with the VSTa server architecture, we can create "pipelines" of servers. This disk mirroring idea could be achieved by having the server equivalent of a "tee" utility. If we could design some protocol for block device messages, we could make this *entirely* transparent, and as simple to use as: bdevtee block_device_1 block_device_2 Sounds neat. From vandys@glare.cisco.com Fri May 13 08:13:49 1994 Received: from dustbin.cisco.com (dustbin.cisco.com [131.108.1.27]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01269; Fri, 13 May 1994 08:13:48 -0700 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by dustbin.cisco.com (8.6.8+c/CISCO.SUB_GATE.1.1) with ESMTP id JAA21762 for <vsta@cisco.com>; Fri, 13 May 1994 09:01:17 -0700 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id LAA22826; Fri, 13 May 1994 11:56:13 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA10997; Fri, 13 May 1994 11:56:10 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199405131556.AA10997@world.std.com> Subject: Re: Mirror server? To: vsta@cisco.com Date: Fri, 13 May 1994 11:56:10 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1822 Hi all, [Dave Hudson <dave@humbug.demon.co.uk> writes:] > The implementation I was thinking of would connect to all of the > devices/partitions/files that we'd like to store data on and provide a > mechanism whereby these would be seen as one logical device. The server > would advertise a port that to all intents and purposes would appear to be > any other block device. I think its important to decide what the end goal is when combining multiple physical devices into a single logical device, as this greatly affects the way the server is implemented and how data is organized. Some goals are: 1. data replication 2. performance 3. the ability to extend logical data storage by adding new physical devices Note that the goals aren't independent of each other. For example, replicating data in some fashion may affect performance. You also have to be careful that you don't create more problems than you solve. For example, one decides that to increase the effective disk transfer rate by stripeing two disks, but discovers that the average rotational latency just increased (assuming the disks aren't spindle locked) or that the I/O bus is a bottle neck, etc. > I know there'd be issues with handling fails There also needs to be system-management level software that, among other things, does the following: 1) builds up and tears down stripe/mirror sets. 2) brings new disk members on-line 3) sets policies > ... but I'd think that VSTa must > be a superb environment to tinker with this sort of code. I agree. The ability to put this stuff into a server along with VSTa's ability to connect servers together is much better than, for example, having to link a new pseudo driver into the kernel that has to jump through a number of hoops to get thing working properly. Mike Larson From vandys@glare.cisco.com Fri May 13 14:40:21 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01300; Fri, 13 May 1994 14:40:19 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA16788 for <vsta@cisco.com>; Fri, 13 May 1994 15:27:44 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa28177; 13 May 94 23:24 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q23Ob-0003JgC; Fri, 13 May 94 20:59 BST Message-Id: <m0q23Ob-0003JgC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Mirror server? To: Mike A Larson <larz@world.std.com> Date: Fri, 13 May 1994 20:59:45 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199405131556.AA10997@world.std.com> from "Mike A Larson" at May 13, 94 11:56:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3886 Hi, Mike A Larson wrote: > > I think its important to decide what the end goal is when combining > multiple physical devices into a single logical device, as this greatly > affects the way the server is implemented and how data is organized. I agree that there'd need to be a lot of thought about how to do things before any code's written - this was just one of my "that looks like a good idea" moments :-) > 1. data replication > > 2. performance > > 3. the ability to extend logical data storage by adding > new physical devices 1 and 2 were my original ideas - I've always liked the Unixish idea of mounting new filesystems into the current fs rather than having a single fs. I can see that 3 would be a real advantage to many people who have potential disk capacity problems. > Note that the goals aren't independent of each other. For example, > replicating data in some fashion may affect performance. Yes, I've heard of striping and mirroring being used to give about 90% of standard performance. I'd not really been thinking about performance when I had the idea; I'd been thinking more about a mechanism for replicating critical data without having to build it in hardware. One particular idea was that I run a couple of development systems that are mirrors of each other (this involves a QIC150 tape and about 80 MBytes of data a day) - I thought it might be a neat idea to have all writes automatically go over a network link to the other machine and "mirror" the data there. Initially I wasn't too concerned with speed, as I'd simply assumed that I work at the speed of the fastest device and let buffer memories worry about the rest (I'd guessed it would only be as much of a risk as say a normal Unix write back caching operation) > You also have to be careful that you don't create more problems than > you solve. For example, one decides that to increase the effective > disk transfer rate by stripeing two disks, but discovers that the > average rotational latency just increased (assuming the disks aren't > spindle locked) or that the I/O bus is a bottle neck, etc. I think a lot would depend on what the aim of the system really was - for absolute data integrity I'd think that we'd simply have to live with waiting for both drives in a pair to finish. If we're less concerned I'd probably be happy to work at the speed of the faster device. Striping presents more of a problem, but I remember running utilities that worked out the optimum interleave on my old XT - I guess something similar could be done here? > There also needs to be system-management level software that, among > other things, does the following: > > 1) builds up and tears down stripe/mirror sets. > > 2) brings new disk members on-line > > 3) sets policies I'm all for system-management software :-) Hopefully I'll be writing some before too long! > > ... but I'd think that VSTa must > > be a superb environment to tinker with this sort of code. > > I agree. The ability to put this stuff into a server along with VSTa's > ability to connect servers together is much better than, for example, > having to link a new pseudo driver into the kernel that has to jump > through a number of hoops to get thing working properly. I wouldn't have even *suggested* the idea for a monolithic kernel :-) As much as anything else I think we have an opportunity to look at lots of possibilities that standard kernels make very difficult. I suspect that if something like this mirror idea was implemented and didn't prove successful there'd be a lot of code that could be reused somewhere else (in maybe a more specialised hardware enviroment where spindle syncs were available say). There will always be a few uses where performance won't be so much of an issue though. Anyone for a compressed filesystem layer? (file by file - slow but it'd work) Regards, Dave From vandys@glare.cisco.com Sat May 14 05:00:45 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01376; Sat, 14 May 1994 05:00:43 -0700 Received: from hacke8.dtek.chalmers.se (d7stfax@hacke8.dtek.chalmers.se [129.16.30.18]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA10287 for <vsta@cisco.com>; Sat, 14 May 1994 05:48:15 -0700 Received: (from d7stfax@localhost) by hacke8.dtek.chalmers.se (8.6.8/8.6.6) id OAA05056 for vsta@cisco.com; Sat, 14 May 1994 14:48:00 +0200 From: Stefan Axelsson <d7stfax@dtek.chalmers.se> Message-Id: <199405141248.OAA05056@hacke8.dtek.chalmers.se> Subject: Re: Manual pages To: vsta@cisco.com Date: Sat, 14 May 1994 14:47:58 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 562 While there is no guide to SGML per se there are a couple of introductory documents on: ftp.ifi.uio.no in /pub/SGML. Read the FAQ.readme file. As to which format, I'm all in favour of some SGML based system, but I haven't got the time to think of something right now (car broke down, shouldn't have touched it on Friday 13:th... ;-) As is common when doing things on the net, the one who gets started first, and does the actual work will set the standard... Regards, -- Stefan Axelsson, Chalmers University of Technology, d7stfax@dtek.chalmers.se Sweden From vandys@glare.cisco.com Tue May 17 08:08:33 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01754; Tue, 17 May 1994 08:08:32 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA12939 for <vsta@cisco.com>; Tue, 17 May 1994 08:56:18 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa28065; 17 May 94 16:38 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q3RB7-0002mqC; Tue, 17 May 94 16:35 BST Message-Id: <m0q3RB7-0002mqC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Patches to build GNU sed-2.05 under VSTa To: VSTa mailing list <vsta@cisco.com> Date: Tue, 17 May 1994 16:35:33 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 668 Hi All, I've just got the latest version of GNU sed (2.05) and patched it to build under VSTa. Unfortunately I can't get the VSTa version of GCC to build it, but I've cross compiled under Linux (using GCC 2.5.7). The patches are really trivial - a new makefile (based on my Linux one), a minor patch to handle "errno" correctly and a small mod to "rx.c" that removes some floating point code and replaces it with integer maths instead (anyone care to write an FPU emulator?). I'm really pleased with how little effort it took :-) I guess it'll be in the next release, but if anyone want's the patches or the binary beforehand, please mail me. Regards, Dave From vandys@glare.cisco.com Tue May 17 09:36:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01770; Tue, 17 May 1994 09:36:39 -0700 Received: from styx.vmars.tuwien.ac.at ([128.130.39.28]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA17398 for <vsta@cisco.com>; Tue, 17 May 1994 10:24:22 -0700 Received: by styx.vmars.tuwien.ac.at; id AA17930; Tue, 17 May 1994 19:23:56 +0200 From: Peter Holzer <hp@vmars.tuwien.ac.at> Message-Id: <9405171723.AA17930@styx.vmars.tuwien.ac.at> Subject: floating point (was: GNU sed 2.05) To: vsta@cisco.com (VSTa mailing list) Date: Tue, 17 May 1994 19:23:56 +0200 (MET DST) In-Reply-To: <m0q3RB7-0002mqC@humbug.demon.co.uk> from "Dave Hudson" at May 17, 94 04:35:33 pm Reply-To: hp@vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 786 You (Dave Hudson) wrote: > anyone care to write an FPU emulator? Not an emulator, but I have a soft-FP library lying around. It was originally written for the Minix bcc compiler, and I added some glue for the c386 compiler. Adding glue for gcc would be trivial (just compile the libgcc?.c-files with c386 -gas). I haven't much time to play with VSTa currently, but the library is in /pub/minix/hp/alpha/{bcc,c386}fp.tar.Z on ftp.vmars.tuwien.ac.at, and I could produce the necessary glue, too. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Tue May 17 10:50:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01779; Tue, 17 May 1994 10:50:24 -0700 Received: from sophie.par.univie.ac.at (sophie.par.univie.ac.at [131.130.70.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA21800 for <vsta@cisco.com>; Tue, 17 May 1994 11:38:08 -0700 Received: from jeanine.par.univie.ac.at (jeanine.par.univie.ac.at [131.130.70.23]) by sophie.par.univie.ac.at (8.6.8/8.6.6) with ESMTP id UAA07047 for <vsta@cisco.com>; Tue, 17 May 1994 20:38:00 +0200 From: Robert Mayer - Student <robert@par.univie.ac.at> Received: (robert@localhost) by jeanine.par.univie.ac.at (8.6.8/8.6.6) id UAA29586 for vsta@cisco.com; Tue, 17 May 1994 20:37:59 +0200 Date: Tue, 17 May 1994 20:37:59 +0200 Message-Id: <199405171837.UAA29586@jeanine.par.univie.ac.at> To: vsta@cisco.com Subject: Re: floating point (was: GNU sed 2.05) You (Peter Holzer) wrote: > You (Dave Hudson) wrote: > > > anyone care to write an FPU emulator? > > Not an emulator, but I have a soft-FP library lying around. It was > originally written for the Minix bcc compiler, and I added some glue > for the c386 compiler. Adding glue for gcc would be trivial (just > compile the libgcc?.c-files with c386 -gas). > > I haven't much time to play with VSTa currently, but the library is in > /pub/minix/hp/alpha/{bcc,c386}fp.tar.Z on ftp.vmars.tuwien.ac.at, and I > could produce the necessary glue, too. > > hp > > -- > _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems > |_|_) |------------------------------------------------------------------------ > | | | It's not what we don't know that gets us into trouble, it's > __/ | what we know that ain't so. -- Will Rogers > I don't think it is that easy. If you e.g. multiply two reals, then gcc generates floating point instructions to do this, and not a function call to libgcc.a. One would have to modify gcc's code generator to make your scheme work. Regards Robert From vandys@glare.cisco.com Tue May 17 11:15:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01782; Tue, 17 May 1994 11:15:26 -0700 Received: from styx.vmars.tuwien.ac.at (styx.vmars.tuwien.ac.at [128.130.39.28]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA23088 for <vsta@cisco.com>; Tue, 17 May 1994 12:03:11 -0700 Received: by styx.vmars.tuwien.ac.at; id AA18441; Tue, 17 May 1994 21:02:46 +0200 From: Peter Holzer <hp@vmars.tuwien.ac.at> Message-Id: <9405171902.AA18441@styx.vmars.tuwien.ac.at> Subject: Re: floating point (was: GNU sed 2.05) To: vsta@cisco.com Date: Tue, 17 May 1994 21:02:45 +0200 (MET DST) In-Reply-To: <199405171837.UAA29586@jeanine.par.univie.ac.at> from "Robert Mayer - Student" at May 17, 94 08:37:59 pm Reply-To: hp@vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 979 You (Robert Mayer - Student) wrote: > > You (Peter Holzer) wrote: > > > > Not an emulator, but I have a soft-FP library lying around. It was > > originally written for the Minix bcc compiler, and I added some glue > > for the c386 compiler. Adding glue for gcc would be trivial (just > > compile the libgcc?.c-files with c386 -gas). > > > > I don't think it is that easy. If you e.g. multiply two reals, then gcc > generates floating point instructions to do this, and not a function call to > libgcc.a. One would have to modify gcc's code generator to make your scheme > work. You also have to use the -msoft-float and -mno-fp-ret-in-387 flags (or recompile gcc to make them default). hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Tue May 17 20:37:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA01826; Tue, 17 May 1994 20:37:33 -0700 Received: from uhunix.uhcc.Hawaii.Edu (uhunix4.uhcc.Hawaii.Edu [128.171.44.54]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA23520 for <vsta@cisco.com>; Tue, 17 May 1994 21:25:27 -0700 From: newsham@uhunix.uhcc.Hawaii.Edu Received: from (uhunix.uhcc.Hawaii.Edu) by uhunix.uhcc.Hawaii.Edu (4.1/Sun690) id AA23485; Tue, 17 May 94 18:20:26 HST Received: by (4.1/uhunix) id AA25518; Tue, 17 May 94 18:25:25 HST Message-Id: <9405180425.AA25518@> Subject: VM system To: vsta@cisco.com Date: Tue, 17 May 94 18:25:24 HST X-Mailer: ELM [version 2.3 PL11] Hi, Been reading through the kernel sources a bit. Mostly the stuff in os/mach. I'm trying to understand the VM stuff in particular. As usual with VM systems its not extremely easy to understand. Worse I don't know much about the i386's MMU support (besides that it is supposed to be similar to the 68k's). Would anyone be kind enough to give me a quick overview of the VM system? Such things as the VAS, the HAT, physical to virtual and virtual to physical translations and the i386's support (what are the functions of cr2 and cr3 for example). Thanks in advance... Tim N. newsham@uhunix.uhcc.hawaii.edu From vandys@glare.cisco.com Wed May 18 10:02:42 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01861; Wed, 18 May 1994 10:02:40 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA24412; Wed, 18 May 1994 10:50:27 -0700 Message-Id: <199405181750.KAA24412@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@uhunix.uhcc.Hawaii.Edu Cc: vsta@cisco.com Subject: Re: VM system In-Reply-To: Your message of "Tue, 17 May 1994 18:25:24 -1000." <9405180425.AA25518@> Date: Wed, 18 May 1994 10:50:26 -0700 From: Andrew Valencia <vandys@cisco.com> [newsham@uhunix.uhcc.Hawaii.Edu writes:] > Worse I don't know much about the i386's >MMU support (besides that it is supposed to be similar to >the 68k's). Would anyone be kind enough to give me a quick >overview of the VM system? The Intel reference manual for the i486 has a pretty good description of the x86 VM facilities. >Such things as the VAS, the HAT, >physical to virtual and virtual to physical translations and >the i386's support (what are the functions of cr2 and cr3 >for example). I'll write something up concerning the vas, hat, pset, pview, atl and friends, but I think Intel did a better and more thorough job on the x86 than I'd care to do. Drop me a note if you want their phone # for ordering a copy. The "root" of the memory system is the "vas" struct, which stands for Virtual Address Space. A vas hangs off the proc struct, as do thread structs. Thus, a proc has a 1:1 connection to a virtual address space, and all threads under a proc share the same address space. A vas is mostly just a place list one or more pviews. It provides a mutex (mutual exclusion mechanism) to coordinate changes made to the address space, and it leaves room for the "hatvas", which is any hardware-specific state which needs to be kept per address space. "hat" stands for Hardware Address Translation. It refers to processor-dependent virtual memory system functions. Each pview exists under a single vas, and one or more pviews are linked together in a list. Each pview describes a virtual address, and a length. Thus, its name "Page View". The sum of all pview's address/length ranges describes the virtual addresses which are valid in a particular address space. The pview also describes protection (read-only, read-write, etc.). Finally, the pview also points downward to a pset. A pset is the first level which is not associated with a particular address space. In fact, pviews from many different address spaces can point down to a pset. The pset describes the state of a set of pages, and thus gets its name "Page Set". A pset describes a length but no virtual address; a set of pages can be mapped at different addresses in different address spaces. It describes where initial page contents are accessed (from a server, zero-filled, copy-on-write) and also maintains an array of per-page information. The "perpage" struct holds state for a particular page slot under a pset. If the slot is valid, it names the physical page number. It also records the pviews which currently have a mapping to this page. The "atl" ("Attach List") is a linked list data structure which then enumerates each such pview. The ability to enumerate mappings of a physical page is required by the two-handed clock algorithm used to age pages during memory pageout and reclaim. Finally, each physical page has a corresponding "struct core" entry. This entry records information needed to "wire" a page (keep it from being reclaimed--needed during DMA access, for instance). It also provides a back pointer to the pset which is currently using this page. The i386-specific portion of the VM data structures is minimal. The "hatvas" struct keep both the virtual and physical addresses for the root of the page tables for a given address space. It keeps a resource map to tabulate what addresses are available for dynamic memory. Finally, purely as an optimization, it keeps a bitmap to indicate which slots in the root page table have second level page tables. This is used to speed cleanup during exit(). Some brief notes on the mutex design. The vas has a spinlock which protects changes to the overall address space. The pview does not; cases where it needs to be protected are covered by acquiring the vas's spinlock. The pset has a of two mechanisms. For simple changes like reference count updates it has a straight spinlock "p_lock". For changes to some particular position under the pset, the effect of having a per-slot semaphore (sleeping mutex, not spin-oriented) is gained using a combination of the pset's p_lockwait semaphore and two bits in the pp_lock field of the perpage information. PP_LOCK in this field indicates the the slot is held. PP_WANT is an optimization which indicates that on release of PP_LOCK, if PP_WANT is set then sleepers on p_lockwait in the containing pset will be awaken. Thus, pageins of multiple positions within a pset can be done in parallel. Two threads racing to page in a single position will be serialized on the PP_LOCK of the slot. Removing a pview from a vas will be protected by the vas's spinlock. The fact that multiple threads can be changing a vas (and structures below) asynchronously adds complications. For instance, deleting a pview from a vas requires great care so that threads already active down in the pset are not hosed when a thread starts removing the pview form the vas, and tries to tear it down. Andy From vandys@glare.cisco.com Wed May 18 14:18:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01878; Wed, 18 May 1994 14:18:38 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA11093 for <vsta@cisco.com>; Wed, 18 May 1994 15:06:31 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04805; 18 May 94 22:57 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q3rTg-0002nCC; Wed, 18 May 94 20:40 BST Message-Id: <m0q3rTg-0002nCC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: gzip-1.2.4 running under VSTa To: VSTa mailing list <vsta@cisco.com> Date: Wed, 18 May 1994 20:40:27 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 369 Hi all, I now have gzip-1.2.4 running under VSTa. This again is cross built from Linux (for now). If anyone wants this before Andy's next release, please mail me. There's one extra string function needed for libc and a sequence defined to handle VSTa DOS FAT filesystems (to set the default extension). Otherwise, it's just a modified makefile. Regards, Dave From vandys@glare.cisco.com Wed May 18 23:52:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA01923; Wed, 18 May 1994 23:52:06 -0700 Received: from mail.swip.net (mail.swip.net [192.71.220.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id AAA29001 for <vsta@cisco.com>; Thu, 19 May 1994 00:40:06 -0700 Received: by mail.swip.net (8.6.8/2.01) id JAA13360; Thu, 19 May 1994 09:40:03 +0200 Received: by distinct.se (4.1/KTH-1.1) id AA06924; Thu, 19 May 94 09:20:57 +0100 From: lars@distinct.se (Lars Pensjo) Message-Id: <9405190820.AA06924@distinct.se> Subject: tty and login patch To: vsta@cisco.com Date: Thu, 19 May 94 9:20:56 BST X-Mailer: ELM [version 2.3 PL0] Two patches: 1. Patch login program so as to not ask for password if the user doesn't have any. 2. Patch for libc/tty.c so as to make ONLCR work. This means that NL is replaced with CR/NL if OPOST and ONLCR are enabled. =================================================================== RCS file: /usr/local/src/cvs.master/lars/vsta/bin.src/login/login.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 login.c --- 1.1.1.1 1994/05/05 23:23:16 +++ login.c 1994/05/17 07:51:44 @@ -241,11 +241,13 @@ printf("That account is disabled.\n"); return; } - printf("password: "); fflush(stdout); - get_str(passwd, sizeof(passwd), 0); - if (strcmp(uinfo.u_passwd, passwd)) { - printf("Incorrect password.\n"); - return; + if (uinfo.u_passwd[0] != '\0') { + printf("password: "); fflush(stdout); + get_str(passwd, sizeof(passwd), 0); + if (strcmp(uinfo.u_passwd, passwd)) { + printf("Incorrect password.\n"); + return; + } } login(&uinfo); } =================================================================== RCS file: /usr/local/src/cvs.master/lars/vsta/libc/tty.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 tty.c --- 1.1.1.1 1994/05/05 23:23:36 +++ tty.c 1994/05/07 11:38:50 @@ -318,18 +318,57 @@ * __tty_write() * Flush buffers to a TTY-type device * - * XXX add the needed CRNL conversion and such. + * XXX This should be rewritten so as to use several segments. */ __tty_write(struct port *port, void *buf, uint nbyte) { struct msg m; - + int start; + int offset; + char *p; + + p = buf; m.m_op = FS_WRITE; - m.m_buf = buf; - m.m_arg = m.m_buflen = nbyte; m.m_nseg = 1; m.m_arg1 = 0; - return(msg_send(port->p_port, &m)); + /* + * If no post outprocessing is done, or if NLs are not translated + * into LF-CR, then output all data immediately. + */ + if ((tty_state.c_oflag & (ONLCR|OPOST)) != (ONLCR|OPOST)) { + m.m_buf = buf; + m.m_arg = m.m_buflen = nbyte; + return(msg_send(port->p_port, &m)); + } + for (start=0, offset=0; start+offset < nbyte; offset++) { + if (p[start+offset] != '\n') + continue; + + m.m_buf = p+start; + m.m_arg = m.m_buflen = offset + 1; + if (msg_send(port->p_port, &m) == -1) + return start; + /* + * Now append a CR to the last NL. + */ + m.m_buf = "\r"; + m.m_arg = m.m_buflen = 1; + if (msg_send(port->p_port, &m) == -1) + return start+offset+1; + start += offset+1; + offset = -1; + } + /* + * Any remaining characters to be output ? + */ + if (start != nbyte) { + m.m_buf = buf + start; + m.m_arg = m.m_buflen = offset; + if (msg_send(port->p_port, &m) == -1) { + return start; + } + } + return nbyte; } /* From vandys@glare.cisco.com Thu May 19 14:39:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02041; Thu, 19 May 1994 14:39:02 -0700 Received: from max.tiac.net (root@max.tiac.net [199.0.65.4]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id PAA07454 for <vsta@cisco.com>; Thu, 19 May 1994 15:27:06 -0700 Received: (from chrisp@localhost) by max.tiac.net (8.6.8/8.6.6.Beta9) id SAA17457 for vsta@cisco.com; Thu, 19 May 1994 18:26:38 -0400 From: Chris Patti { Feoh } <chrisp@max.tiac.net> Message-Id: <199405192226.SAA17457@max.tiac.net> Subject: Getting line numbers in native GCC error messages To: vsta@cisco.com Date: Thu, 19 May 1994 18:26:37 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 626 Quick question.. Does anyone know if there's some sort of VSTA native switch that will turn on line numbers in the natively hosted GCC's error messages? I'm finding it hard to debug my apps when the only error I get is: No Entry With no indication of where the offending code might be.. I understand that VSTA is ultra bleeding edge alpha-ware or similar and thus this is just a curious query to see if anyone else had conquered this beast. I'm probably barking up a non existent tree, though since I'd bet that if you could get more verbose errors you would by default. Just wondering.. -Chris feoh@gnu.ai.mit.edu From vandys@glare.cisco.com Fri May 20 14:28:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02126; Fri, 20 May 1994 14:28:57 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA03064 for <vsta@cisco.com>; Fri, 20 May 1994 15:17:03 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa11409; 20 May 94 23:12 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q4cfN-0002obC; Fri, 20 May 94 23:03 BST Message-Id: <m0q4cfN-0002obC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Getting line numbers in native GCC error messages To: VSTa mailing list <vsta@cisco.com> Date: Fri, 20 May 1994 23:03:41 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 604 Chris Patti { Feoh } wrote: > > Has this been posted somewhere already? if not perhaps we should share the > wealth? > OK, to recap for the list, the problem was why do some compiles just die and report "no entry". After a suggestion from Andy I found that tmpfs seems to end up busy during large gcc runs (Invoking with gcc -v shows that the tmp file is busy). As a temporary workaround, removing tmpfs from inittab and fstab, and creating a /tmp directory allows things to continue (there's a performance hit though). I think this problem will be tracked down soon anyway :-) Regards, Dave From vandys@glare.cisco.com Sat May 21 10:20:00 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02228; Sat, 21 May 1994 10:19:58 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA26767 for <vsta@amri.cisco.com>; Sat, 21 May 1994 11:08:13 -0700 Message-Id: <199405211808.LAA26767@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: VSTa status Date: Sat, 21 May 1994 11:08:12 -0700 From: Andrew Valencia <vandys@cisco.com> Hello, all. Well, sorry for the slow-down on VSTa work, but I had to do a new router bringup and that takes time. I also had to mentor a new employee, which settled the issue. Anyway, the router is up and the employee is in good shape, so I'm finally getting some work done on VSTa! A couple folks have complained about gcc dying on large source files. It appears that cpp is using up all the stack, and dying on a stack growth attempt. There are parameters for stack growth which were never implemented--so it looks like it's time. tmpfs has at least two bugs which I've just fixed, including one which would cause him to die a horrible death. I also fixed the "boot process died" to only go off when the *last* thread dies. It's normal for threads to come and go, especially in filesystem processes. I also have a fix for the bug where /v/... would match a /vsta/... mount point. It isn't quite right yet, but it's close. On another front, I started a port of ka9q to VSTa. If somebody could give me a server for a LAN interface I can just worry about the portable code. If not, I might bootstrap it on PPP or SLIP so I can use my RS-232 driver without having to go back and put a LAN card driver together. ka9q should scale much better on VSTa than it did on Linux. The use of select() would show roughly an O(n^2) slowdown, I think I can fiddle things around so a simple msg_receive() on a central port will catch all events--network interface packet activity as well as clients. Andy From vandys@glare.cisco.com Sun May 22 02:26:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA02268; Sun, 22 May 1994 02:26:40 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA20605 for <vsta@cisco.com>; Sun, 22 May 1994 03:14:58 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa11746; 22 May 94 11:03 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q59wq-0002pTC; Sun, 22 May 94 10:35 BST Message-Id: <m0q59wq-0002pTC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Some more patches to VSTa To: VSTa mailing list <vsta@cisco.com> Date: Sun, 22 May 1994 10:35:55 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1178 Hi All, Having already generated (an albeit small) duplicate patch to someone else on the list, I thought I'd better send out a quick note on things I've done since 1.3.1 was released: * Added some more string functions to libc * Added va_args interface functions for the scanf and printf families * Modified syslog() to use the new va_args functions * Modified the rs232 server to handle different line settings (eg parity, databits, etc) and to make handshaking signals available * Modified the mouse server to add ps/2 support and revamped the serial mouse code to use the rs232 server instead of using polled I/O * Added an nvram/rtc server * Wrote an fstab utility that lists the currently mounted ports * Modified wd to support secondary controllers * Added new mount/umount builtin commands to rc, ash and testsh * Modified the stat utility to be able to stat a port as well as a file * Added support for non blocking reads from tty in libc * Ported gzip-1.2.4 and sed-2.05 I hope none of this duplicates anything anyone else is doing or has done. FWIW my next targets are to add utime() and chown() functions to libc and to port GNU tar 1.11.2 Regards, Dave From vandys@glare.cisco.com Tue May 24 05:43:51 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA03064; Tue, 24 May 1994 05:43:50 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA14850 for <vsta@cisco.com>; Tue, 24 May 1994 06:32:20 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa01177; 24 May 94 14:23 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q5vxq-0003GvC; Tue, 24 May 94 13:52 BST Message-Id: <m0q5vxq-0003GvC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Bug in dos server To: VSTa mailing list <vsta@cisco.com> Date: Tue, 24 May 1994 13:52:10 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 722 Hi All, I don't normally post patches to the list, but this one can avoid some accidental file deletions. As it stands, the dos server can unlink() a directory with files in it - it should only be able to unlink() empty directories. I found this as I've just added an rmdir() function to libc - there's an rmdir command to go with it. The patch is to srv/dos/dir.c Regards, Dave ------------------------------------------------------------------------------ --- dir.c.orig Wed May 11 09:53:26 1994 +++ dir.c Tue May 24 13:41:25 1994 @@ -383,13 +383,13 @@ } /* * Oops. Found a file. Not empty. */ bfree(handle); - return(1); + return(0); } bfree(handle); } return(1); } From vandys@glare.cisco.com Sat May 28 09:13:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03724; Sat, 28 May 1994 09:13:16 -0700 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA02029 for <vsta@cisco.com>; Sat, 28 May 1994 10:02:11 -0700 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id NAA09873; Sat, 28 May 1994 13:02:10 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA14997; Sat, 28 May 1994 13:02:07 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199405281702.AA14997@world.std.com> Subject: SCSI/CAM status, etc. To: vsta@cisco.com Date: Sat, 28 May 1994 13:02:07 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1625 Hi, I'd like to let everyone know about the current SCSI/CAM driver status and at the same time ask a couple of questions. I've been working on an application interface to the SCSI/CAM driver. The interface consists of a library of functions that format CCB's and send them to the driver. Using this interface, I've written a small utility, called camtalk, that allows the issuing of SCSI commands from the command line. So far, camtalk does some of the basic SCSI commands (INQUIRY, TUR, etc.) as well as some CDROM audio commands. New code has been added to the SCSI/CAM server to: a) handle the new application interface. b) to handle CDROM's. I've also added code to implement bounce buffers for SCSI/ISA systems with > 16MB of memory. This code doesn't actually work yet, as I need to integrate it with some new code that Andy is writing for VSTa. Right now, I'm planning on porting a CDROM filesystem to VSTa. Now for the questions: 1) I've found sources to two CDROM filesystems called isofs. One is from the BSD world and the other is from Linux. Both have heavy dependencies on *nix style kernel calls and header files. I think, however, with some conditional compilation and support functions, that the porting job shouldn't be too bad. Comments? 2) does it seem reasonable to, by default, to allow the following access to SCSI devices: a) sys.sys only: a.1) SCSI DIRECT devices (eg, hard disks) a.1) SCSI bus management functions (eg, BUS RESET) b) sys.something-else (perhaps sys.io or just sys) b.1) SCSI CDROM devices b.2) SCSI SEQUENTIAL devices (eg, tapes) Mike Larson From vandys@glare.cisco.com Sat May 28 13:59:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA03740; Sat, 28 May 1994 13:59:18 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA06854 for <vsta@cisco.com>; Sat, 28 May 1994 14:48:13 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa27842; 28 May 94 22:43 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q7W2G-0003psC; Sat, 28 May 94 22:35 BST Message-Id: <m0q7W2G-0003psC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: SCSI/CAM status, etc. To: Mike A Larson <larz@world.std.com> Date: Sat, 28 May 1994 22:35:15 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199405281702.AA14997@world.std.com> from "Mike A Larson" at May 28, 94 01:02:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1686 Hi Mike, > Now for the questions: > > 1) I've found sources to two CDROM filesystems called isofs. One is > from the BSD world and the other is from Linux. Both have heavy > dependencies on *nix style kernel calls and header files. I think, > however, with some conditional compilation and support functions, that > the porting job shouldn't be too bad. Comments? This sounds reasonable. I guess that the simplest way to go would be to take either the vstafs or dosfs code (probably not bfs as it's not hierarchical), strip out the fs dependencies and bolt new code around it. I've never looked too closely at the ISO9660 fs, but are there writeable versions or is it purely a read only fs - if it is I guess it should make life a lot simpler :-) > 2) does it seem reasonable to, by default, to allow the following > access to SCSI devices: > > a) sys.sys only: > > a.1) SCSI DIRECT devices (eg, hard disks) > > a.1) SCSI bus management functions (eg, BUS RESET) > > b) sys.something-else (perhaps sys.io or just sys) > > b.1) SCSI CDROM devices > > b.2) SCSI SEQUENTIAL devices (eg, tapes) Why not just make all of the devices sys.sys, but make the permissions changable by the initial owner. This makes it easy for an initialisation script to do something like: stat -w -p cam:scdrom0 "owner=..." or: stat -w /dev/scdrom "acc=..." (I'm not sure what the device names would actually be). This way we can specify whatever permissions are wanted by individual sysadms. FWIW I've been thinking about doing something similar, and allowing this sort of permission handling on a lot of the device servers I've been working with recently. Regards, Dave From vandys@glare.cisco.com Sun May 29 10:37:25 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA03817; Sun, 29 May 1994 10:37:24 -0700 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA02604 for <vsta@cisco.com>; Sun, 29 May 1994 11:26:25 -0700 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id OAA11862; Sun, 29 May 1994 14:26:24 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA26436; Sun, 29 May 1994 14:26:22 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199405291826.AA26436@world.std.com> Subject: Re: SCSI/CAM status, etc. To: vsta@cisco.com Date: Sun, 29 May 1994 14:26:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1872 Hi Dave, >> Now for the questions: >> >> 1) I've found sources to two CDROM filesystems called isofs. One is >> from the BSD world and the other is from Linux. Both have heavy >> dependencies on *nix style kernel calls and header files. I think, >> however, with some conditional compilation and support functions, that >> the porting job shouldn't be too bad. Comments? > >This sounds reasonable. I guess that the simplest way to go would be to >take either the vstafs or dosfs code (probably not bfs as it's not >hierarchical), strip out the fs dependencies and bolt new code around it. As far as support functions go, I'm thinking about doing is this: at the top, write a set of functions that convert from VSTa FS_ messages to VFS function calls, and convert the return values to the appropriate message replys. This code would borrow from vstafs and/or dosfs. At the bottom I would write a set of bio style functions. isofs would sit in the middle. The advantage of this approach is that it shouldn't require radical changes to isofs itself. This would make tracking changes to the code easier. >> 2) does it seem reasonable to, by default, to allow the following >> access to SCSI devices: >> : >> : > >Why not just make all of the devices sys.sys, but make the permissions >changable by the initial owner. This makes it easy for an initialisation >script to do something like: > > stat -w -p cam:scdrom0 "owner=..." > >or: > > stat -w /dev/scdrom "acc=..." The "stat -w" is a good idea. However, I'd also like to set up some reasonable defaults so, the sysadm wouldn't have to do this for the normal case. > FWIW I've been thinking about doing something similar, and allowing this > sort of permission handling on a lot of the device servers I've been working > with recently. Let me know if there's any common code we can share. Mike Larson From vandys@glare.cisco.com Sun May 29 14:28:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00156; Sun, 29 May 1994 14:28:06 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA06275 for <vsta@cisco.com>; Sun, 29 May 1994 15:19:08 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa17439; 29 May 94 23:15 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q7t3R-0003qEC; Sun, 29 May 94 23:10 BST Message-Id: <m0q7t3R-0003qEC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: SCSI/CAM status, etc. To: Mike A Larson <larz@world.std.com> Date: Sun, 29 May 1994 23:10:00 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199405291826.AA26436@world.std.com> from "Mike A Larson" at May 29, 94 02:26:22 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 992 Hi Mike, > As far as support functions go, I'm thinking about doing is this: > at the top, write a set of functions that convert from VSTa FS_ > messages to VFS function calls, and convert the return values to > the appropriate message replys. This code would borrow from vstafs > and/or dosfs. At the bottom I would write a set of bio style functions. > isofs would sit in the middle. > > The advantage of this approach is that it shouldn't require radical > changes to isofs itself. This would make tracking changes to the > code easier. Sounds like a good way to get this running quickly. I guess once it's working any performance issues can be looked at (I'm not sure if there are any). I assume that the low level requests will be handled as message requests from the SCSI server? It would be nice if this were the case as someone could write a server for say a Sony or Panasonic IDE CD-ROM (as used on lots of sound cards) and it could take the same requests. Regards, Dave From vandys@glare.cisco.com Sun May 29 18:40:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00192; Sun, 29 May 1994 18:40:12 -0700 Received: from TYO1.gate.nec.co.jp ([202.32.8.9]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA10296 for <vsta@cisco.com>; Sun, 29 May 1994 19:31:13 -0700 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO1.gate.nec.co.jp (8.6.8+2.4Wb/3.3Wb-NEC-TYO1) with SMTP id LAA08223 for <vsta@cisco.com>; Mon, 30 May 1994 11:31:11 +0900 Received: from mailsv.bs1.fc.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA27902; Mon, 30 May 1994 11:31:11 +0900 Received: from java.dbg.bs1.fc.nec.co.jp by mailsv.bs1.fc.nec.co.jp (4.1/6.4JAIN) id AA25768; Mon, 30 May 94 11:30:44 JST Received: from creta.dbg.bs1.fc.nec.co.jp (creta) by java.dbg.bs1.fc.nec.co.jp (5.67+1.6W/6.4J.6) id AA02855; Mon, 30 May 94 11:31:18 JST Received: by creta.dbg.bs1.fc.nec.co.jp (4.0/6.4J.6) id AA01071; Mon, 30 May 94 11:28:02 JST Message-Id: <9405300228.AA01071@creta.dbg.bs1.fc.nec.co.jp> To: vsta@cisco.com Subject: help on wd server Reply-To: kataoka@dbg.bs1.fc.nec.co.jp Date: Mon, 30 May 94 11:28:00 +0900 From: Masato Kataoka <kataoka@creta.dbg.bs1.fc.nec.co.jp> Hi all, I recently got VSTa 1.31 and joined this mailing list. Now I'm having some problems, maybe someone can help me out. The binary boots fine on my 486. The problem is that when I try to boot VSTa on my notebook, VST always fails, telling "boot process 4 died". The following is more detailed description: type go in /vsta/boot boot.exe reads in kernel and boot servers syslog prints: syslog: info: wd0: 41.1M - 8 heads, 619 cylinders, 17 sectors [some disk access going on] "boot process 4 died" displayed now I'm in kernel debugger >tf Trap type 255 err 0x0 eip 0x33:0x3e59 eax 0xffffffff ebx 0x3fc6 ecx 0x5 edx 0x0 esi 0x4007c4 edi 0x0 esp 0x2b:0x7fffff10 ebp 0x7fffff2c eflags 0x3246 I compiled wd server to see where it dies. The user stack looks like this: __notify _abort _assfail _wd_start _wd_isr _wd_main ... The only ASSERT in wd_start is: ASSERT((inportb(WD_PORT+WD_STATUS) & WDS_BUSY) == 0, "wd_start: busy"); It's strange since in wd_isr(), a check is made to make sure the drive is not BUSY. but I know practically nothing about disk controller things. so I'm hoping some one can help me out of this situation. here's my notebook spec: 386SX 12Mhz (I know, I know, it's the slowest any 386 can get :-< 6MB ram (80nsec) 41MB HD (35MB for dos primary, 6MB for extended) BTW Linux used to run fine on this poor machine. Thanks in advance. --- Masato Kataoka kataoka@dbg.bs1.fc.nec.co.jp From vandys@glare.cisco.com Mon May 30 05:25:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00312; Mon, 30 May 1994 05:25:04 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA28715 for <vsta@cisco.com>; Mon, 30 May 1994 06:16:08 -0700 Received: from ebt-inc.ebt.com by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA03405; Mon, 30 May 94 09:14:33 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA19566; Mon, 30 May 1994 09:14:32 +0500 Date: Mon, 30 May 1994 09:14:32 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9405301314.AA19566@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <9405300228.AA01071@creta.dbg.bs1.fc.nec.co.jp> (message from Masato Kataoka on Mon, 30 May 94 11:28:00 +0900) Subject: Re: help on wd server Content-Length: 253 What kind of machine is your notebook? Dave would know better than me, about the HW, but I belive that some IDE drives might generate spurious interrupts when queried about size etc. BTW. I have a PC9801 port of VSTa 1.1, or 1.2 (I forget which)... From vandys@glare.cisco.com Mon May 30 07:33:39 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00322; Mon, 30 May 1994 07:33:37 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA15581; Mon, 30 May 1994 08:25:02 -0700 Message-Id: <199405301525.IAA15581@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: kataoka@dbg.bs1.fc.nec.co.jp Cc: vsta@cisco.com Subject: Re: help on wd server In-Reply-To: Your message of "Mon, 30 May 1994 11:28:00 +0900." <9405300228.AA01071@creta.dbg.bs1.fc.nec.co.jp> Date: Mon, 30 May 1994 08:25:01 -0700 From: Andrew Valencia <vandys@cisco.com> [Masato Kataoka <kataoka@creta.dbg.bs1.fc.nec.co.jp> writes:] >_assfail >_wd_start >_wd_isr >_wd_main Hmmm... looks like a stray interrupt from the WD controller. You might try turning that assert into: while (inportb(WD_PORT+WD_STATUS) & WDS_BUSY) ; and see if that helps your system. More efficient might be: if (...) return; which assumes that another interrupt will arrive for the true completion of the I/O. I have a 386sx laptop too, and yes, they aren't very fast by today's standards! We've also seen the occasional machine which can't do automatic head select. You might try removing the "#define AUTO_HEAD" from wd.h before you play around with the interrupt handling. It generally won't fail with your symptoms, but you never know. Regards, Andy From vandys@glare.cisco.com Mon May 30 23:42:13 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA00211; Mon, 30 May 1994 23:42:11 -0700 Received: from TYO1.gate.nec.co.jp ([202.32.8.9]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id AAA21356 for <vsta@cisco.com>; Tue, 31 May 1994 00:33:21 -0700 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO1.gate.nec.co.jp (8.6.8+2.4Wb/3.3Wb-NEC-TYO1) with SMTP id QAA19305 for <vsta@cisco.com>; Tue, 31 May 1994 16:33:18 +0900 Received: from mailsv.bs1.fc.nec.co.jp (venus.d2.bs1.fc.nec.co.jp) by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA07524; Tue, 31 May 1994 16:33:17 +0900 Received: from java.dbg.bs1.fc.nec.co.jp by mailsv.bs1.fc.nec.co.jp (4.1/6.4JAIN) id AA24499; Tue, 31 May 94 16:32:48 JST Received: from creta.dbg.bs1.fc.nec.co.jp (creta) by java.dbg.bs1.fc.nec.co.jp (5.67+1.6W/6.4J.6) id AA12530; Tue, 31 May 94 16:33:25 JST Received: by creta.dbg.bs1.fc.nec.co.jp (4.0/6.4J.6) id AA07772; Tue, 31 May 94 16:30:07 JST Message-Id: <9405310730.AA07772@creta.dbg.bs1.fc.nec.co.jp> To: vsta@cisco.com Subject: Re: help on wd server In-Reply-To: Your message of Mon, 30 May 94 08:25:01 -0700. <199405301525.IAA15581@glare.cisco.com> Reply-To: kataoka@dbg.bs1.fc.nec.co.jp Date: Tue, 31 May 94 16:30:03 +0900 From: Masato Kataoka <kataoka@creta.dbg.bs1.fc.nec.co.jp> First, thanks for your advices to all who replied. Andy Valencia said: >> while (inportb(WD_PORT+WD_STATUS) & WDS_BUSY) >> ; >> >> and see if that helps your system. More efficient might be: >> >> if (...) >> return; >> which assumes that another interrupt will arrive for the true completion of >> the I/O. Dave Hudson said: >> You may find it worth adding: >> >> __msleep(10); >> >> just before the failing ASSERT. Last night, I tried inserting the following line right before calling wd_start(). if (inportb(WD_PORT+WD_STATUS) & WDS_BUSY) syslog("something"); After syslog displayed "something" four times or so, VSTa booted and printed "login:" ! It may be the case that the above line produced the delay that hd controller needs. I don't know how HD controller works (the technical reference for the notebook doesn't tell me the basics of programming a device), but I will go with Andy's suggestion that waits until BUSY is low, and see if it works every time. (BTW, I tried undef'ing AUTOHEAD, without success.) As a matter of fact, there's more to the story. VSTa boots now, but keyboard just freezes! I think (I hope) this is unrelated to wd-server, since NetBSD-0.[89] boot failed with the same symptom. I'm going to add the code to initialize the keyboard, and see if it solves the symptom. Or, maybe I should just forget about the notebook, and start writing a keyboard mapping program on my 486 box. (CapsLock next to 'A' is killing me :-< ) Gavin Nicol said: >> What kind of machine is your notebook? Dave would know better than >> me, about the HW, but I belive that some IDE drives might generate >> spurious interrupts when queried about size etc. It's called PS55NOTE, manufactured by Japan IBM three or four years ago. I think it's an ancestor of ThinkPad series. >> >> BTW. I have a PC9801 port of VSTa 1.1, or 1.2 (I forget which)... Hmm, interesting. but I've never bought a PC9801 personally. I wish someone with a 98 could keep the port up to date for the time when VSTa becomes widespread. (assuming, of course, that 98 series won't die out :-) Well, thanks again folks. --- Masato Kataoka kataoka@dbg.bs1.fc.nec.co.jp From vandys@glare.cisco.com Tue May 31 08:55:23 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00256; Tue, 31 May 1994 08:55:21 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA03179; Tue, 31 May 1994 09:47:01 -0700 Message-Id: <199405311647.JAA03179@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: kataoka@dbg.bs1.fc.nec.co.jp Cc: vsta@cisco.com Subject: Re: help on wd server In-Reply-To: Your message of "Tue, 31 May 1994 16:30:03 +0900." <9405310730.AA07772@creta.dbg.bs1.fc.nec.co.jp> Date: Tue, 31 May 1994 09:46:59 -0700 From: Andrew Valencia <vandys@cisco.com> [Masato Kataoka <kataoka@creta.dbg.bs1.fc.nec.co.jp> writes:] >... >VSTa boots now, but keyboard just freezes! >I think (I hope) this is unrelated to wd-server, Probably. They're completely distinct processes, using distinct interrupt vectors and I/O ports. If you wanted to debug it, you could start the RS-232 server and log in through that (assuming serial I/O works on your PC...). Then attach the debugger to the keyboard task and see what it's doing. You'll need a cons2 server a.out with symbols, but you can again log in through the serial port and make one that way. Andy From vandys@glare.cisco.com Wed Jun 1 08:55:25 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00461; Wed, 1 Jun 1994 08:55:23 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA13269 for <vsta@cisco.com>; Wed, 1 Jun 1994 09:46:45 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa03244; 1 Jun 94 17:27 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q8se9-0003d5C; Wed, 1 Jun 94 16:56 BST Message-Id: <m0q8se9-0003d5C@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: VSTa port of Bison-1.22 To: VSTa mailing list <vsta@cisco.com> Date: Wed, 1 Jun 1994 16:56:01 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 467 Hi All, Just a quick note that I now have a working port of GNU bison-1.22 running under VSTa and an almost completely working port of GNU tar-1.11.2. Hopefully these should be in the 1.4 release. I can probably put some patches together if anyone would like these beforehand, but there are a few libc mods, and Andy may not implement them quite the same way as the patches I've sent him. If you just want the binaries though, that's easy :-) Regards, Dave From vandys@glare.cisco.com Wed Jun 1 16:23:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00519; Wed, 1 Jun 1994 16:23:26 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA06333 for <vsta@cisco.com>; Wed, 1 Jun 1994 17:14:48 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa28481; 2 Jun 94 1:07 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q90BC-0003czC; Thu, 2 Jun 94 00:58 BST Message-Id: <m0q90BC-0003czC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Ported flex-2.4.6 :-) To: VSTa mailing list <vsta@cisco.com> Date: Thu, 2 Jun 1994 00:58:38 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 400 Hi All, After being told that flex should be an easy porting target having done bison (thanks Nick!), I've ported flex-2.4.6. I've been unable to test flex++ as I can't find any suitable source files (I don't think it's that important at the moment anyway) Again, hopefully this should be in release 1.4, and again, if anyone wants the binaries, I'll be happy to send them on. Regards, Dave From vandys@glare.cisco.com Thu Jun 2 08:26:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA02368; Thu, 2 Jun 1994 08:26:18 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA08570 for <vsta@cisco.com>; Thu, 2 Jun 1994 09:17:46 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa18975; 2 Jun 94 16:50 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q99sr-0003icC; Thu, 2 Jun 94 11:20 BST Message-Id: <m0q99sr-0003icC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: New port - Berkley yacc To: VSTa mailing list <vsta@cisco.com> Date: Thu, 2 Jun 1994 11:20:21 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 810 Hi All, I've just ported a version of Berkley yacc - I suspect it's not the latest one, it just happened to be one I had on my Linux system (the timestamps indicate it was April last year). I think it generates slightly smaller output files than bison, and doesn't come with the insistence that all programs using it must be GPL'd. Actually to call this a port is a slight overstatment - it requried a modified makefile and one #ifdef VSTADOSFS to cope with naming output files as say y_tab.c instead of y.tab.c. If it's compiled without the matching #define it should use the normal y.tab.c format - useful if we move to a fs that supports longer filenames than dos. Again, I'm pretty sure it's working OK, but at the moment I can only really test it on a few files from rc and flex. Regards, Dave From vandys@glare.cisco.com Thu Jun 2 12:32:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02653; Thu, 2 Jun 1994 12:32:30 -0700 Received: from plg.uwaterloo.ca (plg.uwaterloo.ca [129.97.140.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA20916 for <vsta@cisco.com>; Thu, 2 Jun 1994 13:23:48 -0700 Received: by plg.uwaterloo.ca id <185300>; Thu, 2 Jun 1994 16:23:28 -0400 From: Dave Mason <dmason@plg.uwaterloo.ca> To: vsta@cisco.com In-Reply-To: <m0q99sr-0003icC@humbug.demon.co.uk> (message from Dave Hudson on Thu, 2 Jun 1994 06:20:21 -0400) Subject: questions about porting and reality (was Re: New port - Berkley yacc) X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP<lkW*7FT|:Dm 9ejO^{)GHJdPQaa"C\<Ak`K27?328'V(u*|jAEZR9-z!o\^j:Cb&*tx_9\KbXD*2 Message-Id: <94Jun2.162328edt.185300@plg.uwaterloo.ca> Date: Thu, 2 Jun 1994 16:23:26 -0400 > From: Dave Hudson <dave@humbug.demon.co.uk> > Date: Thu, 2 Jun 1994 06:20:21 -0400 > > I've just ported a version of Berkley yacc - I suspect it's not the latest > one, it just happened to be one I had on my Linux system (the timestamps > indicate it was April last year). > > I think it generates slightly smaller output files than bison, and doesn't > come with the insistence that all programs using it must be GPL'd. This is great! (non GPL'd is important to a lot of people) I'm wondering what the general state of porting is. How many people are actually using VSTa for production work, as opposed to having fun hacking on it? I've been swamped, so haven't installed VSTa yet, but I have a laptop that is currently running Linux that I am thinking of switching to VSTa (it only has 120MB of disk and 4MB of ram, so small is good). Here are the tools I use a lot: TeX - should be easy to port, only uses open, close, read, write. dvi previewer - need access to display as bitplane GNUemacs - mg is nice, but I really need shell-mode. Any idea what problems there are in porting it? I've thought of writing a Xlib fake so I could run lemacs scm - (Jaffer's Scheme interpreter) should be easy I also have a 486DLC that is going to become my main production machine. I've been tossing around the idea of linux, netbsd and VSTa. In addition to the above, I'd also need: sc - spreadsheet - should be easy except for curses uucp - could be somewhat tricky - messes around with keyboard modes etc. cnews - I can read the news using emacs, but I need to unpack it. Should be very easy to port. mawk - or equivalent for sysadmin scripts network - there's also a couple other machines that will be connected to an Ethernet and in the longer term I'd need remote file access I'm willing to put time into getting some of this working. I also have a NS32532 board (different instruction set, but same byte ordering) that I want to be running the same operating system (which is why I'm thinking about netbsd). I guess this would be the first non Intel architecture - but it's the closest in a lot of ways. Any ideas? Comments? Thanks ../Dave From vandys@glare.cisco.com Thu Jun 2 12:53:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02656; Thu, 2 Jun 1994 12:53:54 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA22013 for <vsta@cisco.com>; Thu, 2 Jun 1994 13:45:23 -0700 Received: from ebt-inc.ebt.com by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA16491; Thu, 2 Jun 94 16:43:48 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA07966; Thu, 2 Jun 1994 16:43:46 +0500 Date: Thu, 2 Jun 1994 16:43:46 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9406022043.AA07966@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <94Jun2.162328edt.185300@plg.uwaterloo.ca> (message from Dave Mason on Thu, 2 Jun 1994 16:23:26 -0400) Subject: Re: questions about porting and reality (was Re: New port - Berkley yacc) Comments: Hyperbole mail buttons accepted, v3.09. Content-Length: 325 Once I get back into the "real" world, I'll be swining back to working on MADO and BITBLT (a windowing system, and graphics server), and other stuff as well. I think most of the people here are interested in the hack value as much as anything else, but I also intend to use it as a development environment once I'm able to. From vandys@glare.cisco.com Thu Jun 2 14:47:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02677; Thu, 2 Jun 1994 14:47:09 -0700 Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA27567 for <vsta@cisco.com>; Thu, 2 Jun 1994 15:38:38 -0700 Received: from sbi.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA29155 for vsta@cisco.com; Thu, 2 Jun 94 18:40:45 -0400 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA03873; Thu, 2 Jun 94 18:38:35 EDT Received: from std.sbi.com by sbi.sbi.com (4.1/SMI-4.1) id AA07229; Thu, 2 Jun 94 18:38:29 EDT Received: by std.sbi.com (4.1/SMI-4.1) id AA11064; Thu, 2 Jun 94 18:38:28 EDT From: bet@std.sbi.com (Bennett Todd) Message-Id: <9406022238.AA11064@std.sbi.com> Subject: Re: questions about porting and reality (was Re: New port - Berkley yacc) To: dmason@plg.uwaterloo.ca (Dave Mason) Date: Thu, 2 Jun 1994 18:38:27 -0400 (EDT) Cc: vsta@cisco.com In-Reply-To: <94Jun2.162328edt.185300@plg.uwaterloo.ca> from "Dave Mason" at Jun 2, 94 04:23:26 pm X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2181 > GNUemacs - mg is nice, but I really need shell-mode. Any idea > what problems there are in porting it? I've thought > of writing a Xlib fake so I could run lemacs I don't know enough to comment one way or another on GNU emacs, and the ease or difficulty of porting it to VSTA. It has been ported to many, many systems, which one would hope would make the job easier, but it is also large and complex. My favourite emacs-like editor is Jove. If anybody wants to port it to VSTA, let me know and I'll point you at the current beta version. While the jovehacks don't want this version widely advertised, as they are hoping to stabilize a new public release Real Soon Now, the current beta snapshot is still vastly more stable and portable than the previous public release --- most of the intervening work has been cleanup, rather than hacking in new features. Jove has interactive shell windows, filter-region (though a command), shell-command, and compile-it (with friends parse-errors, next-error, previous-error, and so on). It has keyboard macros, which can be recorded, saved to files, edited, reloaded, bound to keys, etc. It has a moderately parameterizable c-mode, as well as a lisp-mode. It does not have an extension programming language. It weighs in at about 200K for the executable, which is quite usable with no other run-time files at all; the complete set of run-time files that comes with it adds another 180K, including an analogue to /usr/lib/exrecover, keycharts that display the keyboard bindings on many supported terminals, jove.rc scripts that initialize special features for many known terminals, and some 90K of reference manual accessible through the builtin help facilities. I think it might be a better size match to VSTA than GNU Emacs:-). Also, since its internals are currently on the operating table, there's a collection of experts on the jovehacks mailing list that can take your output from "make 2>&1 | tee make.out" and help you do the port. I'd undertake the port myself, but my PC is in the middle of a protracted hardware upgrade downtime and is in pieces, so I don't have a VSTA-capable platform right now. -Bennett bet@sbi.com From vandys@glare.cisco.com Thu Jun 2 14:55:30 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02680; Thu, 2 Jun 1994 14:55:28 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA27915 for <vsta@cisco.com>; Thu, 2 Jun 1994 15:46:58 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04999; 2 Jun 94 23:38 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q9LMh-0003icC; Thu, 2 Jun 94 23:35 BST Message-Id: <m0q9LMh-0003icC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: questions about porting and reality (was Re: New port - Berkley yacc) To: Dave Mason <dmason@plg.uwaterloo.ca> Date: Thu, 2 Jun 1994 23:35:55 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <94Jun2.162328edt.185300@plg.uwaterloo.ca> from "Dave Mason" at Jun 2, 94 04:23:26 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1487 > This is great! (non GPL'd is important to a lot of people) I realised this after a year of Linuxing :-) > I'm wondering what the general state of porting is. How many people > are actually using VSTa for production work, as opposed to having fun > hacking on it? I think Andy's probably the best one to comment, but I think 5 or 6 people have some sort of attribution in the current code - I think that there are a few more who've done stuff recently, but I've not been keeping track (I only know who I created email aliases for :-)) > I've been swamped, so haven't installed VSTa yet, but I have a laptop > that is currently running Linux that I am thinking of switching to > VSTa (it only has 120MB of disk and 4MB of ram, so small is good). > Here are the tools I use a lot: [...packages deleted...] I have a few more to add to the list: GNU awk, GDB, GCC-2.5.8, diffutils, patch, bash, tcsh, shellutils, textutils. find (I've nearly got this one done), joe and cpio. > I'm willing to put time into getting some of this working. I also > have a NS32532 board (different instruction set, but same byte > ordering) that I want to be running the same operating system (which > is why I'm thinking about netbsd). I guess this would be the first > non Intel architecture - but it's the closest in a lot of ways. I'd really like to see a non-intel port. I thought I was going to get chence to do one a couple of months back, but the project fell through. Regards, Dave From vandys@glare.cisco.com Thu Jun 2 15:12:35 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA02699; Thu, 2 Jun 1994 15:12:34 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA14838; Thu, 2 Jun 1994 16:04:38 -0700 Message-Id: <199406022304.QAA14838@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson <dave@humbug.demon.co.uk> Cc: Dave Mason <dmason@plg.uwaterloo.ca>, VSTa mailing list <vsta@cisco.com> Subject: Re: questions about porting and reality (was Re: New port - Berkley yacc) In-Reply-To: Your message of "Thu, 02 Jun 1994 23:35:55 BST." <m0q9LMh-0003icC@humbug.demon.co.uk> Date: Thu, 02 Jun 1994 16:04:37 -0700 From: Andrew Valencia <vandys@cisco.com> [Dave Hudson <dave@humbug.demon.co.uk> writes:] >I think Andy's probably the best one to comment, but I think 5 or 6 people >have some sort of attribution in the current code - I think that there are a >few more who've done stuff recently, but I've not been keeping track (I only >know who I created email aliases for :-)) This sounds about right. We're roughly on the second wave of hackers, although Gavin is hopefully on the rebound! :-) >I'd really like to see a non-intel port. I thought I was going to get >chence to do one a couple of months back, but the project fell through. I have an HP 300 (68030 based) available to me. I'm slowly clawing my way back from router bringup mode here, and then will give it a spin. Really, the kernel won't take that much time, it's the device driver servers. I'll beam a note when I get screen and keyboard up, anyway. Sigh, I also want to finish my KA9Q port, as telnet'ing to a VSTa system would be very convenient. So much to do, so little time. Andy From vandys@glare.cisco.com Fri Jun 3 07:08:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02753; Fri, 3 Jun 1994 07:08:40 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA01675 for <vsta@cisco.com>; Fri, 3 Jun 1994 08:00:12 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa20305; 3 Jun 94 15:45 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0q9aTF-0003jiC; Fri, 3 Jun 94 15:43 BST Message-Id: <m0q9aTF-0003jiC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Port of GNU find-3.8 To: VSTa mailing list <vsta@cisco.com> Date: Fri, 3 Jun 1994 15:43:40 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 468 Hi All, Whilst I seem to be on a roll at the moment (and I hate decorating - which is what I should be doing at the moment :-)) I now have a working find command (I'm reasonably sure 3.8 is the latest). There are now quite a lot of additions to libc, so I could try to put them together if necessary, but once again sending out binaries is easy. There aren't any source patches in this port (apart from the libc ones), just a few new makefiles. Regards, Dave From vandys@glare.cisco.com Fri Jun 3 10:10:52 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02773; Fri, 3 Jun 1994 10:10:51 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA15331 for <vsta@amri.cisco.com>; Fri, 3 Jun 1994 11:03:05 -0700 Message-Id: <199406031803.LAA15331@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Port of vi to VSTa Date: Fri, 03 Jun 1994 11:03:04 -0700 From: Andrew Valencia <vandys@cisco.com> I've got a port of "vim" (an excellent "vi" editor clone, better than the original with multi-level undo and other features) to VSTa. Now all I need is a port of RCS and I'll have virtually no reason to run DOS, ever. Oh yeah, except for Tubotax.... :-) Bugs found: missing "a" mode in fopen(), plus something I didn't know about strchr() and strrchr(): strchr("abc", '\0') returns a pointer to the terminating '\0' of the string "abc". Otherwise, it was mostly just a conversion to POSIX TTY handling. Andy From vandys@glare.cisco.com Fri Jun 3 12:52:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03027; Fri, 3 Jun 1994 12:52:18 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id NAA18803; Fri, 3 Jun 1994 13:43:50 -0700 Received: from uucp1.uu.net by relay3.UU.NET with SMTP (rama) id QQwssw04999; Fri, 3 Jun 1994 16:43:50 -0400 Received: from icad.UUCP by uucp1.uu.net with UUCP/RMAIL ; Fri, 3 Jun 1994 16:43:48 -0400 Received: from nowhere by icad.icad.com (4.1/LCS-1.3) id AA27476; Fri, 3 Jun 94 15:45:39 EDT From: Chris Patti <chrisp@icad.com> Received: by nowhere.icad.com (5.0/LCS-1.1-client) id AA02943; Fri, 3 Jun 1994 15:46:59 +0500 Date: Fri, 3 Jun 1994 15:46:59 +0500 Message-Id: <9406031946.AA02943@nowhere.icad.com> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Fri, 03 Jun 1994 11:03:04 -0700 <199406031803.LAA15331@glare.cisco.com> Subject: Port of vi to VSTa Content-Length: 939 X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol Date: Fri, 03 Jun 1994 11:03:04 -0700 From: Andrew Valencia <vandys@cisco.com> I've got a port of "vim" (an excellent "vi" editor clone, better than the original with multi-level undo and other features) to VSTa. Now all I need is a port of RCS and I'll have virtually no reason to run DOS, ever. Oh yeah, except for Tubotax.... :-) Bugs found: missing "a" mode in fopen(), plus something I didn't know about strchr() and strrchr(): strchr("abc", '\0') returns a pointer to the terminating '\0' of the string "abc". Otherwise, it was mostly just a conversion to POSIX TTY handling. Andy Out of curiosity, when you and other folks are compiling these large apps don't you run across that stack growth problem that keeps biting me ien the nose whenever I try to build anything under VSTa? -Chris From vandys@glare.cisco.com Fri Jun 3 12:59:25 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03031; Fri, 3 Jun 1994 12:59:23 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA27812; Fri, 3 Jun 1994 13:51:34 -0700 Message-Id: <199406032051.NAA27812@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Chris Patti <chrisp@icad.com> Cc: vsta@cisco.com Subject: Re: Port of vi to VSTa In-Reply-To: Your message of "Fri, 03 Jun 1994 15:46:59 +0500." <9406031946.AA02943@nowhere.icad.com> Date: Fri, 03 Jun 1994 13:51:34 -0700 From: Andrew Valencia <vandys@cisco.com> Hi, I have the digest format of the VSTa mailing list working now. This will generate AT MOST one digest per day, and will wait up to three days to gather at least three messages. If you'd prefer this format, please send a note to vsta-request@cisco.com, and I'll switch you over. Now... [Chris Patti <chrisp@icad.com> writes:] >Out of curiosity, when you and other folks are compiling these large apps > don't you run across that stack growth problem that keeps biting me ien the >nose whenever I try to build anything under VSTa? (Andy lurches into motion, one rcsdiff later:) *** c:/tmp/T0AA.AAA Fri Jun 03 13:40:42 1994 --- os/mach/trap.c Sat May 21 11:29:18 1994 *************** *** 98,109 **** --- 98,110 ---- * once it has figured out the faulting address and such. */ static void page_fault(struct trapframe *f) { ulong l; + struct vas *vas; extern ulong get_cr2(); ASSERT(curthread, "page_fault: no proc"); /* * Get fault address. Drop the high bit because the *************** *** 125,146 **** dbg_fault_addr = l; #endif /* * Let the portable code try to resolve it */ ! if (vas_fault(curthread->t_proc->p_vas, l, ! f->errcode & EC_WRITE)) { if (curthread->t_probe) { #ifdef DEBUG printf("cpfail\n"); dbg_enter(); #endif ASSERT((f->ecs & 3) == PRIV_KERN, "page_fault: probe from user"); f->eip = (ulong)(curthread->t_probe); } else { selfsig(EFAULT); } } } /* --- 126,162 ---- dbg_fault_addr = l; #endif /* * Let the portable code try to resolve it */ ! vas = curthread->t_proc->p_vas; ! if (vas_fault(vas, l, f->errcode & EC_WRITE)) { if (curthread->t_probe) { #ifdef DEBUG printf("cpfail\n"); dbg_enter(); #endif ASSERT((f->ecs & 3) == PRIV_KERN, "page_fault: probe from user"); f->eip = (ulong)(curthread->t_probe); } else { + /* + * Stack growth. We try to grow it if it's + * a "reasonable" depth below current stack. + */ + if ((l < USTACKADDR) && + (l > (USTACKADDR-UMINSTACK))) { + if (alloc_zfod_vaddr(vas, btop(UMAXSTACK), + USTACKADDR-UMAXSTACK)) { + return; + } + } + + /* + * Shoot him + */ selfsig(EFAULT); } } } /* From vandys@glare.cisco.com Mon Jun 6 19:43:18 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA03488; Mon, 6 Jun 1994 19:43:17 -0700 Received: from Trantor.DSO.gov.SG by dirt.cisco.com (8.6.8+c/CISCO.SUB_GATE.1.1) with SMTP id UAA08854 for <vsta@cisco.com>; Mon, 6 Jun 1994 20:35:10 -0700 Received: by Trantor.DSO.gov.SG (4.1/25-TRANTOR-eef) id AA14943; Tue, 7 Jun 94 11:36:19 SST From: Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> Message-Id: <9406070336.AA14943@Trantor.DSO.gov.SG> Subject: Time Function To: vsta@cisco.com Date: Tue, 7 Jun 94 11:36:18 WST X-Mailer: ELM [version 2.3 PL11] Hi, I have question about the time() function in the C library of VSTa. I noticed that it return time in sec since 1990 instead of the standard 1970. So my question is: does any body know what is the magic value of the no of sec from 1970 to 1990? I need this so that it will be consistance with values return by Linux. This is necessary because I am working on a EXT2FS server now. I have manage to re-used most of the codes from Linux, so writting a server is not too hard. Since the EXT2FS has a lot of time-stamp in it (both the supper block and the usual files), and I don't want to mess up these value when I access the FS from VSTa, I need to get the time value relative to 1970 instead of 1990. When I complete this server, we can share the fs between VSTa and Linux. I will than work on the LILO boot of VSTa - this would enable us to do some works on Linux and boot into VSTa for testing. -- Tan Pong Heng Defence Science Organization Project Leader 20 Science Park Drive, S(0511) From vandys@glare.cisco.com Tue Jun 7 02:16:50 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA03509; Tue, 7 Jun 1994 02:16:48 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA17111 for <vsta@cisco.com>; Tue, 7 Jun 1994 03:08:43 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa24680; 7 Jun 94 11:03 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qAxne-0003H2C; Tue, 7 Jun 94 10:50 BST Message-Id: <m0qAxne-0003H2C@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Port of GNU make 3.71 To: VSTa mailing list <vsta@cisco.com> Date: Tue, 7 Jun 1994 10:50:25 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 764 Hi All, Just another note to say that I've now got GNU make 3.71 ported to VSTa. Again, there are a few new functions and a bug fix, but if anyone would like the binary please let me know. I've hit a few problems building under VSTa (as opposed to Linux) with the original VSTa make utility as it doesn't seem to get bison handling quite right and it doesn't seem to handle doing say: MDEFINES = LDFLAGS='$(LDFLAGS)' all make MDEFINES when making subdirectories. FWIW, make has proved more difficult than the other ports as it doesn't have a DOS port included (this has simplified the others). It also needed some changes to use execv() instead of execve() as VSTa uses the external ENV server instead of having an environment string. Regards, Dave From vandys@glare.cisco.com Tue Jun 7 07:22:16 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03541; Tue, 7 Jun 1994 07:22:15 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA26556; Tue, 7 Jun 1994 08:15:10 -0700 Message-Id: <199406071515.IAA26556@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> Cc: vsta@cisco.com Subject: Re: Time Function In-Reply-To: Your message of "Tue, 07 Jun 1994 11:36:18 +0700." <9406070336.AA14943@Trantor.DSO.gov.SG> Date: Tue, 07 Jun 1994 08:15:10 -0700 From: Andrew Valencia <vandys@cisco.com> [Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> writes:] >... So my question is: does any body know what is the magic value of >the no of sec from 1970 to 1990? Dave Hudson added this to <time.h> for the next release: /* * The difference between VSTa time and UNIX time is 20 years. VSTa starts * ticking from 1990 not 1970. This constant handles the conversion. Note * that as well as 5 leap years there were 15 leap seconds as well :-) If * you're interested in the leap seconds, RFC1305 (NTP) provides more detail */ #define VSTA_UNIX_TDIFF (((20*365)+5)*24*60*60)+15) I have RCS mostly working now. It has all sorts of porting knobs and buttons to push, though, and I'm still cleaning up the edge cases. Regards, Andy From vandys@glare.cisco.com Thu Jun 9 00:21:38 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05152; Thu, 9 Jun 1994 00:21:37 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA10662 for <vsta@cisco.com>; Thu, 9 Jun 1994 01:13:36 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa19450; 9 Jun 94 8:58 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qBexV-0003FIC; Thu, 9 Jun 94 08:55 BST Message-Id: <m0qBexV-0003FIC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Port of GNU textutils 1.9 To: VSTa mailing list <vsta@cisco.com> Date: Thu, 9 Jun 1994 08:55:29 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 577 Hi All, I think this is the last one for a while (I've got some more code to get written now). I've just completed a port of GNU textutils version 1.9. (If you don't know this one, it has all of the little things like cut, head, tail, wc, etc that make shell scripting easier and will hopefully get us nearer to running the GNU autoconfig scripts). The only minor problem is with od as we don't support floating point yet. This one (as with find) requires GNU make to build. Again, binaries (and at a push sources) are available if anyone wants them. Regards, Dave From vandys@glare.cisco.com Mon Jun 13 07:38:36 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA05750; Mon, 13 Jun 1994 07:38:34 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA06982; Mon, 13 Jun 1994 08:30:56 -0700 Message-Id: <199406131530.IAA06982@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> Cc: vsta@amri.cisco.com Subject: Re: Error Msgs returned by kernel In-Reply-To: Your message of "Mon, 13 Jun 1994 10:50:08 +0700." <9406130250.AA18045@Trantor.DSO.gov.SG> Date: Mon, 13 Jun 1994 08:30:56 -0700 From: Andrew Valencia <vandys@cisco.com> [Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> writes:] >... I am current working on >a ext2fs server for VSTa, and is constantly running into this problem of >error codes handling. It is so inconvience to have a string as error code >instead of the normal integer codes. So my question is - is there any >reasons that you have decided on a string instead of integer that I don't see? Yes. Like the Plan 9 folks, I observed that binary numbers have an enormous inflexibility. You have to encode them to share them between architectures, they're hard to manipulate in a structured way, they're hard to view, and it's very hard to distribute out responsibility of them to reflect kernel, server, or even application specific values. So they're strings. 16 bytes might be a little stifling, but just the ability to have a networking stack say "tcp/retries" instead of 1432, makes it all worth it. Note that I also wanted to allow the strings to be common between events and errors. So "fault" is returned as an error or an event as appropriate. This interface was meant to reflect my beliefs of the interface between a server and a client. Within a server, it is entirely possible that you might encode your state and errors as integers, or enums, or (what the heck) floating point arrays. At worst, you should be able to map the number to the appropriate string just as the reply is built for the client. Andy From vandys@glare.cisco.com Tue Jun 14 08:48:01 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA05887; Tue, 14 Jun 1994 08:48:00 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA13276 for <vsta@cisco.com>; Tue, 14 Jun 1994 09:40:38 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa05258; 14 Jun 94 17:26 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qDZbp-0003IcC; Tue, 14 Jun 94 15:37 BST Message-Id: <m0qDZbp-0003IcC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Setting of HZ value To: VSTa mailing list <vsta@cisco.com> Date: Tue, 14 Jun 1994 15:37:00 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 537 Hi All, Has anyone tried playing with the HZ value in <mach/param.h> and increased it from it's default 20 to 50, 100, or higher. When I wrote the patch originally, 20 was picked because it was very close to the dos 18.6. I wondered if anyone's got any feeling of whether a larger value makes the system appear more responsive (of course it'll run marginally slower, but I suspect it may appear less jerky under heavy loads). I tried upping it to 50 Hz, but I couldn't really convince myself one way or another. Regards, Dave From vandys@glare.cisco.com Tue Jun 14 13:29:50 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA05944; Tue, 14 Jun 1994 13:29:49 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA22249; Tue, 14 Jun 1994 14:22:25 -0700 Message-Id: <199406142122.OAA22249@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Connin <johnc@manatee.oau.org> Cc: vsta@cisco.com Subject: Re: Newbie Problem -- I hope In-Reply-To: Your message of "Tue, 14 Jun 1994 16:25:48 EDT." <199406142025.AA06495@manatee.oau.org> Date: Tue, 14 Jun 1994 14:22:24 -0700 From: Andrew Valencia <vandys@cisco.com> [John Connin <johnc@manatee.oau.org> writes:] > syslog: error: CAM > syslog: error: can't register name > syslog: error: Unfortunately, somehow CAM tickled a latent bug where it can't connect with the namer server because the name server has not yet managed to start up and register its port. We fixed it for the next release by modifying the namer library to sleep and retry a couple times. Note that the bug could happen with the IDE driver as well, but it just happens to avoid it. In the meantime, Mike Larson (the owner of the driver) has a version which has the retry loop in the driver itself. Mike, should we put that on the FTP site? Andy From vandys@glare.cisco.com Tue Jun 14 13:21:30 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA05940; Tue, 14 Jun 1994 13:21:29 -0700 Received: from osceola.cs.ucf.edu (osceola.cs.ucf.edu [132.170.108.35]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA27579 for <vsta@cisco.com>; Tue, 14 Jun 1994 14:14:07 -0700 Received: from alfred.UUCP by osceola.cs.ucf.edu (4.1/1.34) id AA13214; Tue, 14 Jun 94 17:14:02 EDT Received: by alfred.oau.org (/\==/\ Smail3.1.28.1 #28.1) id <m0qDfeF-00004jC@alfred.oau.org>; Tue, 14 Jun 94 17:03 EDT Received: by tous.oau.org (/\==/\ Smail3.1.25.1 #25.6) id <m0qDfGK-0001KsC@tous.oau.org>; Tue, 14 Jun 94 16:39 EDT Received: by manatee.oau.org id AA06495 (5.65c/IDA-1.4.4 for vsta@cisco.com); Tue, 14 Jun 1994 16:25:50 -0400 From: John Connin <johnc@manatee.oau.org> Message-Id: <199406142025.AA06495@manatee.oau.org> Subject: Newbie Problem -- I hope To: vsta@cisco.com Date: Tue, 14 Jun 1994 16:25:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 381 I am having a problem booting vsta for the first time. The only modification I make was to edit 'boot.lst' is use 'cam' instead of 'wd'. Anyway, just after the various modules are loaded I get the following message: syslog: error: CAM syslog: error: can't register name syslog: error: then the system hangs. Any suggestions..?? best regards, johnc From vandys@glare.cisco.com Tue Jun 14 18:33:01 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA05987; Tue, 14 Jun 1994 18:32:59 -0700 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA10632; Tue, 14 Jun 1994 19:25:40 -0700 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id WAA17858; Tue, 14 Jun 1994 22:25:39 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA08450; Tue, 14 Jun 1994 22:25:37 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199406150225.AA08450@world.std.com> Subject: Re: Newbie Problem -- I hope To: vandys@cisco.com (Andrew Valencia) Date: Tue, 14 Jun 1994 22:25:37 -0400 (EDT) Cc: vsta@cisco.com In-Reply-To: <199406142122.OAA22249@glare.cisco.com> from "Andrew Valencia" at Jun 14, 94 02:22:24 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1709 Hi, [Andrew Valencia <vandys@cisco.com> writes:] ... > > In the meantime, Mike Larson (the owner of the driver) has a version which > has the retry loop in the driver itself. Mike, should we put that on the > FTP site? > Here are the diffs (from the VSTa 1.3.1 driver). Andy - if you want, I can send you a new CAM distribution. *** /vsta131/srv/mach/scsi/main.c Sun Apr 10 15:55:44 1994 --- main.c Tue Jun 14 15:55:52 1994 *************** *** 369,375 **** struct cam_file *file; struct cam_qmsg *qmsg; void (*handler)(); ! int ac, irq; long status; struct msg msg; static char *myname = "cam"; --- 369,375 ---- struct cam_file *file; struct cam_qmsg *qmsg; void (*handler)(); ! int ac, irq, retry; long status; struct msg msg; static char *myname = "cam"; *************** *** 405,411 **** * Register the CAM driver. * Move entry out of disk and change name to XPT. */ ! if (namer_register("cam", cam_port_name) < 0) { cam_error(0, "CAM", "can't register name"); exit(1); } --- 405,416 ---- * Register the CAM driver. * Move entry out of disk and change name to XPT. */ ! for(retry = 3; retry > 0; retry--) { ! if (namer_register("cam", cam_port_name) >= 0) ! break; ! cam_msleep(100); ! } ! if(retry <= 0) { cam_error(0, "CAM", "can't register name"); exit(1); } *************** *** 504,509 **** --- 509,521 ---- (file->devid == CAM_ROOTDIR)) { pdev_readdir(&msg, file); break; + } + /* + * Exit if message is M_ABORT. + */ + if(msg.m_op == M_ABORT) { + cam_error(0, myname, "exitting"); + exit(0); } /* * The peripheral device pointer must be valid at this point. From vandys@glare.cisco.com Thu Jun 16 01:44:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA06135; Thu, 16 Jun 1994 01:44:04 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA21059 for <vsta@cisco.com>; Thu, 16 Jun 1994 02:36:52 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa05556; 16 Jun 94 10:30 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qEDkX-0003FnC; Thu, 16 Jun 94 10:28 BST Message-Id: <m0qEDkX-0003FnC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Time Function To: tponghen@Trantor.DSO.gov.SG Date: Thu, 16 Jun 1994 10:28:40 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199406071515.IAA26556@glare.cisco.com> from "Andrew Valencia" at Jun 7, 94 08:15:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1841 Hi All, > > [Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> writes:] > > >... So my question is: does any body know what is the magic value of > >the no of sec from 1970 to 1990? > > Dave Hudson added this to <time.h> for the next release: > > /* > * The difference between VSTa time and UNIX time is 20 years. VSTa starts > * ticking from 1990 not 1970. This constant handles the conversion. Note > * that as well as 5 leap years there were 15 leap seconds as well :-) If > * you're interested in the leap seconds, RFC1305 (NTP) provides more detail > */ > #define VSTA_UNIX_TDIFF (((20*365)+5)*24*60*60)+15) Just to keep this straight, I've since added timezone support to the libc code. This defaults to POSIX support, and the leap seconds are ignored. This bit of code (latest I've sent to Andy) now looks like: /* * The difference between VSTa time and UNIX time is 20 years. VSTa starts * ticking from 1990 not 1970. Additionally, MS-DOS started ticking in 1980 * so we have a constant for the difference there as well. Note that as * well as leap years there were also leap seconds as well :-) If you're * interested in the leap seconds, RFC1305 (NTP) provides more detail (we * ignore them here though) */ #define VSTA_UNIX_TDIFF (631152000) #define VSTA_DOS_TDIFF (315619200) #define DOS_UNIX_TDIFF (VSTA_UNIX_TDIFF - VSTA_DOS_TDIFF) One of the other points that comes out of the mods to the time code are that negative time values are supported (time_t is a signed long) so we can now handle timestamps from before 1990. The only time that can't be reproduced is -1 (23:59:59 on 31st December 1989) as this is an error return value from mktime(). I've sent some diffs to the dos server to allow -ve timestamps (the -1 isn't even a problem as dos fs is only accurate to 2 seconds). Regards, Dave From vandys@glare.cisco.com Mon Jun 20 14:05:55 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA07821; Mon, 20 Jun 1994 14:05:53 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA01597 for <vsta@amri.cisco.com>; Mon, 20 Jun 1994 14:59:09 -0700 Message-Id: <199406202159.OAA01597@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Status of the mailing list, and a plea Date: Mon, 20 Jun 1994 14:59:08 -0700 From: Andrew Valencia <vandys@cisco.com> Hello, The mailing list had a problem reaching some parts of the world for the last 5 days or so. I believe the problem is resolved (it had to do with how my class C was advertised to the world) and I apologize for any inconvenience. Now, a plea. When you submit a patch for something, I'd really appreciate it if you would ONLY include one type of change for a patch. It's needlessly hard for me to work through a patch which fiddles indentation, moves routines around, and also adds a new feature. It's much easier for me to get it as two or more patches, each with a very specific purpose. Thanks! Andy From vandys@glare.cisco.com Fri Jun 24 07:46:31 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA09002; Fri, 24 Jun 1994 07:46:30 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA27578 for <vsta@cisco.com>; Fri, 24 Jun 1994 08:39:56 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa05911; 24 Jun 94 16:30 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qHDB7-00037IC; Fri, 24 Jun 94 16:28 BST Message-Id: <m0qHDB7-00037IC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Hardware floating point support To: VSTa mailing list <vsta@cisco.com> Date: Fri, 24 Jun 1994 16:28:29 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1367 Hi All, Just a quick note in case someone else was thinking of adding fp support to VSTa. I needed to use some floating point code, so I've added fp support to the VSTa kernel, and I've just about finished adding fp extensions to libc. I'll hopefully put together most of a libm by the next release. There's no software emulation support yet, but it should be easy enough to add. If no-one else does it first, I'll look at adding FPU emulation sometime in the future (probably mid August), but getting married will prevent me doing much more than I already have before then :-) In order to allow people to keep VSTa small and keep context switches slightly faster, the diffs I've sent in for the next release have the same #ifdef as some of the current libc code. The default is not to support fp, as GCC traps if fp instructions are executed and there's no FPU available. Whilst I've been doing this, I've also rewritten most of doprnt() to handle fp formats (if FLOAT_SUPPORT is defined) and added some of the previously unimplemented formatting FWIW, the lack of fp support in doprnt() means that the current VSTa port of GCC 1.42 doesn't generate fp code correctly - there's nothing wrong with the port, but it means that you can't build a version that handles fp under the current version. I've cross compiled a new one now though. Regards, Dave From vandys@glare.cisco.com Tue Jun 28 05:22:29 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA09747; Tue, 28 Jun 1994 05:22:28 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA18027 for <vsta@cisco.com>; Tue, 28 Jun 1994 06:16:27 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa27849; 28 Jun 94 14:10 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qIcQi-0003CUC; Tue, 28 Jun 94 13:38 BST Message-Id: <m0qIcQi-0003CUC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Floppy drive server problems To: VSTa mailing list <vsta@cisco.com> Date: Tue, 28 Jun 1994 13:38:24 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 267 Hi All, Has anyone looked at the floppy server recently. I'm finding that doing a lot of I/O breaks it fairly quickly. Before I start looking for the cause I thought I'd check I'm not redoing anything. FWIW I'm working with 1.44MByte floppies. Thanks, Dave From vandys@glare.cisco.com Tue Jul 5 19:59:59 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00213; Tue, 5 Jul 1994 19:59:58 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA13820 for <vsta@amri.cisco.com>; Tue, 5 Jul 1994 20:57:49 -0700 Message-Id: <199407060357.UAA13820@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: New pstat() VSTa interface Date: Tue, 05 Jul 1994 20:57:49 -0700 From: Andrew Valencia <vandys@cisco.com> Hi, The new pstat() system call for querying the kernel about processes is up and running. I have a small ps program which seems to be showing me the real information. Next up is a /proc server so that the state can be queried by programs in general. Thanks to Robert Mayer for writing much of the pstat code! Andy From vandys@glare.cisco.com Sun Jul 10 06:31:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00779; Sun, 10 Jul 1994 06:31:10 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA08082 for <vsta@cisco.com>; Sun, 10 Jul 1994 07:29:26 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04843; 10 Jul 94 15:12 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qMz4M-0003l1C; Sun, 10 Jul 94 14:37 BST Message-Id: <m0qMz4M-0003l1C@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Port of GNU fileutils-3.9 To: VSTa mailing list <vsta@cisco.com> Date: Sun, 10 Jul 1994 14:37:22 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 821 Hi All, Just a quick note to say that I now have a port of GNU fileutils 3.9. I haven't ported all of the commands as some (say mkfifo) are pretty meaningless under VSTa. The commands I have working are: cp, dd, du, install, mkdir, mv, rm, rmdir, touch and gls gls is a pretty straight version of ls, but it can't deal with all of the VSTa permission subtleties, although I've patched the stat() code to try and map more VSTa FS_STAT details to POSIX stat fields. There are already VSTa versions of cp, mkdir, mv, rm and rmdir, but the GNU utils have more options and handle some command lines a little more cleanly sometimes. Before 1.4 is released I'll try to get another version of ls done (say vls) that will provide the GNU ls functionality, but will understand VSTa permission handling. Regards, Dave From vandys@glare.cisco.com Tue Jul 12 04:44:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA01128; Tue, 12 Jul 1994 04:44:47 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA10382 for <vsta@cisco.com>; Tue, 12 Jul 1994 05:43:14 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10886; 12 Jul 94 13:14 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qNgPi-0002pkC; Tue, 12 Jul 94 12:54 BST Message-Id: <m0qNgPi-0002pkC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Booting without DOS To: VSTa mailing list <vsta@cisco.com> Date: Tue, 12 Jul 1994 12:54:17 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1112 Hi All, I finally got time (and a working copy of dd under VSTa) to allow me to move my floppy boot loader code over to VSTa. If you're familiar with Linux it'll seem very familiar as it's based on the same technique. I'm not sure if it'll be much use before the 1.4 release as it uses quite a bit of new stuff and bug fixes that aren't in 1.3.1. Basically the code creates a bootstrap loader, a setup routine and an image of the kernel/boot-time servers (much as the current DOS loader does). These are then dd'd to a floppy diskette which can then be booted. Once the floppy is booted, the boot servers are started and init will handle the remainder of the startup sequence, picking up the servers/start-time programs from the fixed disk. I've modified my earlier Linux hosted version so that it now defaults to finding "vsta", "boot.lst" and the boot-time servers in /vsta/boot. All of this can be overridden, however boot.lst must then provide the full path to any server/program it's going to run. I hope to be able to do some more work on booting direct from an HDD in August! Regards, Dave From vandys@glare.cisco.com Sun Jul 17 05:26:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01903; Sun, 17 Jul 1994 05:26:11 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA06371 for <vsta@cisco.com>; Sun, 17 Jul 1994 06:25:05 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa07104; 17 Jul 94 14:19 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qPW0n-0003JLC; Sun, 17 Jul 94 14:12 BST Message-Id: <m0qPW0n-0003JLC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: New floppy server code To: VSTa mailing list <vsta@cisco.com> Date: Sun, 17 Jul 1994 14:12:09 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1497 Hi All, I've just about finished a major rework of the floppy server, and I wondered if anyone would care to do some testing for me - I've run it against 1.44 MByte 3.5" and 1.2 MByte 5.25" drives, but I'd like to see how it runs on other people's hardware and maybe on a 720k, 360k or 2.88M drive (all of which *should* now work). Here's a quick summary of the changes: - Minor bug fixes - Handles 360k, 720k, 1.2M, 1.44M and 2.88M drives - Handles all of the media combinations I'm aware of for each drive type - Provides new device names for specific media in a drive, eg: /dev/fd/fd0_720 720k diskette in fd0 /dev/fd/fd0_1440 1.44M diskette in fd0 /dev/fd/fd1_1200 1.2M diskette in fd1 - Provides automatic sensing of media via /dev/fd/fd0 and /dev/fd/fd1 - Allows user defined diskette/media parameters via /dev/fd/fd0 and /dev/fd/fd1 - Selectable base I/O address for the floppy controller - Autodetection of controller types - should optimise performance on 82077 type controllers. - Diskette changed indication - Write protection handled - Per drive or per controller retry values - Per drive or per controller syslog warning control (eg do we see all messages, failures only, critical only, etc) I will be adding support for formatting diskettes in the near future, and I'll write a diskette formatting program when I do this. Selection of the params/options can be done via the "stat" utility, so there's no need for a special utility for that purpose. Regards, Dave From vandys@glare.cisco.com Tue Jul 19 14:18:18 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02230; Tue, 19 Jul 1994 14:18:16 -0700 Received: from wariat.org (wariat.org [192.147.147.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA08744 for <vsta@cisco.com>; Tue, 19 Jul 1994 15:17:23 -0700 Received: from fmsystm by wariat.org with uucp(/\==/\ Smail3.1.28.1 #28.5) id <m0qQNSQ-00023zC@wariat.org>; Tue, 19 Jul 94 18:16 EDT for cisco.com!vsta Received: from nightfly by fms.com with uucp (Smail3.1.28.1 #1) id m0qQMu0-0000isC; Tue, 19 Jul 94 17:40 EDT Received: by nightfly.telemax.com (4.1/SMI-4.1) id AA00260; Tue, 19 Jul 94 17:00:07 EDT From: matt@nightfly.telemax.com (Matt Emerson) Message-Id: <9407192100.AA00260@nightfly.telemax.com> Subject: sparc port To: vsta@cisco.com Date: Tue, 19 Jul 1994 17:00:07 -0400 (EDT) Content-Type: text Content-Length: 503 i'm starting to work on porting vsta to the sparc (sun4c). the hardware documentation i have is scanty, and i am basically finding things out by reading source code from the sparc operating systems i have collected. if anyone has connections at sun, i'd really like to know where to get some hardware manuals. i'm using a sparc 1+, and i've heard from a couple of sources that the "campus-1 programmer's model" is the book to get. it seems to be an internal top-secret sun document, though. -matt From vandys@glare.cisco.com Tue Jul 19 20:53:25 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA02262; Tue, 19 Jul 1994 20:53:24 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA04176; Tue, 19 Jul 1994 21:51:33 -0700 Message-Id: <199407200451.VAA04176@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: matt@nightfly.telemax.com (Matt Emerson) Cc: vsta@cisco.com Subject: Re: sparc port In-Reply-To: Your message of "Tue, 19 Jul 1994 17:00:07 EDT." <9407192100.AA00260@nightfly.telemax.com> Date: Tue, 19 Jul 1994 21:51:33 -0700 From: Andrew Valencia <vandys@cisco.com> [matt@nightfly.telemax.com (Matt Emerson) writes:] >I'm starting to work on porting vsta to the sparc (sun4c). Great! I wish I was more of a SPARC wizard, but it's really not a processor I've used, except as a plain UNIX user. Stay in touch, at least I can help you with the VSTa part of the port! I'm assuming your list of operating systems includes NetBSD. I don't know about their SPARC code, but I found their 68k port to be very clean; easy to borrow code to do all the nasty stuff. On another front, I'm starting to ponder how to move the VSTa central source out to a machine where a core team of developers could check in source changes without having me as a bottleneck. I'm thinking a FreeBSD machine using RCS on the Internet would be the ticket. I can probably assemble machine, RAM, and disk. Sadly, all of cisco is behind a firewall, so I'll have to find another point of presence. I wonder if I could rent some space on a net at Cygnus' "The Little Gargen"? Alternatively, I might be able to park my machine on an open net at a company I've been consulting for. Anyway, thoughts are welcome. Ultimately, the box would (of course) run VSTa! Hmmm, reminds me, I need to finish that dratted RCS port.... Regards, Andy From vandys@glare.cisco.com Tue Jul 19 22:16:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA02301; Tue, 19 Jul 1994 22:16:26 -0700 Received: from ceres (root@ceres.daimi.aau.dk [130.225.16.236]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA23724 for <vsta@cisco.com>; Tue, 19 Jul 1994 23:15:34 -0700 Received: by ceres (Linux Smail3.1.28.1 #1) id m0qQV3s-000DJwC; Wed, 20 Jul 94 08:23 MET DST Message-Id: <m0qQV3s-000DJwC@ceres> Date: Wed, 20 Jul 94 08:23 MET DST From: tthorn@daimi.aau.dk (Tommy Thorn) To: vsta@cisco.com Subject: Re: sparc port In-Reply-To: <199407200451.VAA04176@glare.cisco.com> References: <9407192100.AA00260@nightfly.telemax.com> <199407200451.VAA04176@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Andrew Valencia writes: > On another front, I'm starting to ponder how to move the VSTa central source > out to a machine where a core team of developers could check in source > changes without having me as a bottleneck. I'm thinking a FreeBSD machine > using RCS on the Internet would be the ticket. May I humbly suggest you use CVS (which works on top of RCS). It is designed for just this, and I have good experience with it. I think also the NetBSD group uses it. You can easily move all the existing RCS files into CVS. Just a suggestion. Regards, Tommy From vandys@glare.cisco.com Wed Jul 20 04:13:53 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA02351; Wed, 20 Jul 1994 04:13:51 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA07728 for <vsta@cisco.com>; Wed, 20 Jul 1994 05:13:02 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa23882; 20 Jul 94 12:24 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qQX20-00039aC; Wed, 20 Jul 94 09:29 BST Message-Id: <m0qQX20-00039aC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: sparc port To: VSTa mailing list <vsta@cisco.com> Date: Wed, 20 Jul 1994 09:29:36 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1168 Andrew Valencia wrote: > > On another front, I'm starting to ponder how to move the VSTa central source > out to a machine where a core team of developers could check in source > changes without having me as a bottleneck. I'm thinking a FreeBSD machine > using RCS on the Internet would be the ticket. I can probably assemble > machine, RAM, and disk. Sadly, all of cisco is behind a firewall, so I'll > have to find another point of presence. I wonder if I could rent some space > on a net at Cygnus' "The Little Gargen"? Alternatively, I might be able to > park my machine on an open net at a company I've been consulting for. This sounds a great idea - I've found it quite frustrating recently, trying to get odd bits and pieces of code to other developers who probably don't have the same libc and server code that I'm working with. > Anyway, thoughts are welcome. Ultimately, the box would (of course) run > VSTa! Hmmm, reminds me, I need to finish that dratted RCS port.... A lot of people seem to mention CVS (an extension to RCS if I understand this correctly) - can anyone give me a rundown on the major differences/advantages? Regards, Dave From vandys@glare.cisco.com Wed Jul 20 04:51:37 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA02355; Wed, 20 Jul 1994 04:51:36 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA08886 for <vsta@cisco.com>; Wed, 20 Jul 1994 05:50:16 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA26717; Wed, 20 Jul 1994 14:50:52 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA16552; Wed, 20 Jul 1994 14:49:42 +0200 Date: Wed, 20 Jul 1994 14:49:42 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9407201249.AA16552@ibch50.inf.tu-dresden.de> To: vsta@cisco.com Subject: GREAT SORRY While I was debugging a bad mail-filter I got a mail from this list. The filter re-send it with some non-sense stuff. Sorry for that. From vandys@glare.cisco.com Wed Jul 20 05:47:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA02366; Wed, 20 Jul 1994 05:47:40 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA10420 for <vsta@cisco.com>; Wed, 20 Jul 1994 06:46:51 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA18293; Wed, 20 Jul 94 09:47:22 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA09482; Wed, 20 Jul 1994 09:47:22 +0500 Date: Wed, 20 Jul 1994 09:47:22 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9407201347.AA09482@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <199407200451.VAA04176@glare.cisco.com> (message from Andrew Valencia on Tue, 19 Jul 1994 21:51:33 -0700) Subject: Re: sparc port Content-Length: 98 While I can't do any porting, I think I'll be able to do some testing. I have a SparcStation 5... From vandys@glare.cisco.com Wed Jul 20 05:47:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA02363; Wed, 20 Jul 1994 05:47:34 -0700 Received: from iesd.auc.dk (root@iesd.auc.dk [130.225.48.4]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id GAA10418 for <vsta@cisco.com>; Wed, 20 Jul 1994 06:46:46 -0700 Received: from verdande.iesd.auc.dk (herring@verdande.iesd.auc.dk [130.225.48.168]) by iesd.auc.dk (8.6.5/8.6.5) with SMTP id PAA14806; Wed, 20 Jul 1994 15:46:35 +0200 Received: by verdande.iesd.auc.dk id AA22913 (5.65c8/IDA-CLIENT/MD); Wed, 20 Jul 1994 15:46:31 +0200 From: Erick Herring <herring@iesd.auc.dk> Message-Id: <199407201346.AA22913@verdande.iesd.auc.dk> Subject: CVS (Re: sparc port) To: dave@humbug.demon.co.uk (Dave Hudson) Date: Wed, 20 Jul 1994 15:46:31 +0200 (MET DST) Cc: vsta@cisco.com In-Reply-To: <m0qQX20-00039aC@humbug.demon.co.uk> from "Dave Hudson" at Jul 20, 94 09:29:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1428 > > Anyway, thoughts are welcome. Ultimately, the box would (of course) run > > VSTa! Hmmm, reminds me, I need to finish that dratted RCS port.... I also think that making a reference site would be great for all. > A lot of people seem to mention CVS (an extension to RCS if I understand > this correctly) - can anyone give me a rundown on the major > differences/advantages? CVS is a versioning system which does, as you say, use RCS as its "librarian". The Big Idea (tm) is that one checks out an entire version of a package and works on that. Afterwards, the entire package is checked in again. The merge is really good, and manual intervention is a rarity. The benefits are that two developers can work on the same file at the same time. The disadvantages are that it requires diskspace linear to the number of developers and that it is pretty inflexible (IMO) as regards the addition and deletion of files after one has made a "version" ( a version, in this case, is a branch on the CVS source tree). Anyway, I hope that that wasn't too incoherent. More on request. Regards, Erick ----- Erick Herring | Computation is the art of carefully throwing H Data, Aalborg | away information [and] Life is the art of UNIX Consulting | carefully throwing away opportunities, an SysAdmin & Programming | interesting coincidental parallel. herring@iesd.auc.dk | - Guy L. Steele Jr. From vandys@glare.cisco.com Wed Jul 20 07:22:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02381; Wed, 20 Jul 1994 07:22:37 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA13937; Wed, 20 Jul 1994 08:21:52 -0700 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id IAA01668; Wed, 20 Jul 1994 08:21:51 -0700 Message-Id: <199407201521.IAA01668@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Wed, 20 Jul 1994 08:21:50 PDT In-Reply-To: Andrew Valencia <vandys@cisco.com>' <199407200451.VAA04176@glare.cisco.com> Re: sparc port Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia <vandys@cisco.com>, matt@nightfly.telemax.com (Matt Emerson) Subject: Re: sparc port Cc: vsta@cisco.com From: Andrew Valencia <vandys@cisco.com> Subject: Re: sparc port > On another front, I'm starting to ponder how to move the VSTa central source > out to a machine where a core team of developers could check in source We just did this for the DJGPP project. > have to find another point of presence. I wonder if I could rent some space > on a net at Cygnus' "The Little Gargen"? Alternatively, I might be able to I'll ask the "powers that be", although I could probably use either my Linux machine or my sun4 as well. > VSTa! Hmmm, reminds me, I need to finish that dratted RCS port.... We've been using a "heavily hacked" version of CVS with full remote support. Pretty cool. The repository is in CA, and I can do most CVS functions from here in CO. I'd think that's the way to go. - rob - From vandys@glare.cisco.com Tue Jul 26 11:58:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA03201; Tue, 26 Jul 1994 11:58:10 -0700 Received: from uhura.cc.rochester.edu (dd002b@uhura.cc.rochester.edu [128.151.224.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA25518 for <vsta@cisco.com>; Tue, 26 Jul 1994 12:58:01 -0700 Received: (dd002b@localhost) by uhura.cc.rochester.edu (8.6.9/8.6.4) id PAA26308 for vsta@cisco.com; Tue, 26 Jul 1994 15:57:43 -0400 From: yhcrana <dd002b@uhura.cc.rochester.edu> Message-Id: <199407261957.PAA26308@uhura.cc.rochester.edu> Subject: size and complexity To: vsta@cisco.com Date: Tue, 26 Jul 1994 15:57:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 847 I am looking at building a mutilprocessor machine, as a school project (maybe) and have been looking at OS's I am interested in VSTA as it appears to be a full OS that could handle all and more than I may require. My worry is that it might be too large. My initial processorss will probably only have about 128kb of ram. (I want to start with static ram to make my like easier). how small can VSTA be? what if the file system and all un-neccesary modules were droped? How hard would it be to implement on a message passing machine? thanx for any help, derek ------------------------------------------------------------------------------ You should fear any bureaucratic entity that claims to work for you. derek denny-brown (yhcrana) dd002b@uhura.cc.rochester.edu chief engineer, WRUR derdb@cs.rochester.edu From vandys@glare.cisco.com Tue Jul 26 12:10:42 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03205; Tue, 26 Jul 1994 12:10:40 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA16985; Tue, 26 Jul 1994 13:08:41 -0700 Message-Id: <199407262008.NAA16985@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yhcrana <dd002b@uhura.cc.rochester.edu> Cc: vsta@cisco.com Subject: Re: size and complexity In-Reply-To: Your message of "Tue, 26 Jul 1994 15:57:43 EDT." <199407261957.PAA26308@uhura.cc.rochester.edu> Date: Tue, 26 Jul 1994 13:08:40 -0700 From: Andrew Valencia <vandys@cisco.com> [yhcrana <dd002b@uhura.cc.rochester.edu> writes:] >how small can VSTA be? what if the file system and all un-neccesary modules >were droped? How hard would it be to implement on a message passing >machine? With process debugging and pstat left out (as well as all debug assertion instrumentation and kernel debugger) the VSTa kernel is about 40K. No servers are required by VSTa, although this will leave you with a kernel spinning in the idle loop. A large fraction of VSTa has to do with implementing message passing on a MIMD shared memory multiprocessor (with a uniprocessor x86 being a special case of this). The best way to pass messages across machines is to implement a network server to forward VSTa messages across whatever message-passing facility you have in hardware. This would simply be a user-level server which attaches to the message passing hardware to send across messages as appropriate. To get an idea of what this looks like, see Pike's paper on Plan 9 networking. It's available on research.att.com. Regards, Andy From vandys@glare.cisco.com Tue Jul 26 21:26:35 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA03266; Tue, 26 Jul 1994 21:26:33 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id WAA24972 for <vsta@amri.cisco.com>; Tue, 26 Jul 1994 22:24:35 -0700 Message-Id: <199407270524.WAA24972@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Administrivia Date: Tue, 26 Jul 1994 22:24:34 -0700 From: Andrew Valencia <vandys@cisco.com> I'm making progress in setting up VSTa development so more folks can work on the central source without having to funnel through me. I have a copy of CVS which purports to work over a network using rsh; I'm converting VSTa to reside under CVS storage as I type this. When this is all set up, it should be possible for an authorized person under Linux or BSD to commit changes to the repository without having to wait for me. It will also allow anyone to pull down a snapshot without having to wait for the next release. I will, of course, continue to accept patches and such from anybody who cares to work on VSTa! I'm on the home stretch for the birth of our new cisco router platform. Interestingly, my wife is also on the home stretch for the birth of our first (real life) child. One of the biggest reasons for me to pursue such a remote source system is that I want to allow development to continue even if my personal time gets preempted for a while. Regards, Andy From vandys@glare.cisco.com Sat Jul 30 05:50:38 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA03814; Sat, 30 Jul 1994 05:50:37 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA00646 for <vsta@cisco.com>; Sat, 30 Jul 1994 06:50:50 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA10800; Sat, 30 Jul 94 09:51:30 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA06622; Sat, 30 Jul 1994 09:51:28 +0500 Date: Sat, 30 Jul 1994 09:51:28 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9407301351.AA06622@ebt-inc.ebt.com> To: vsta@cisco.com Subject: Point Release Content-Length: 378 Andy, I'm ready to start work on VSTa again. My main problem is that I need to get the latest and greatest VSTa. Are you considering releasing 1.4 or a point version soon? Also, when you set up the CVS system, can we have it automatically generate a release, and a set of diffs once a week? BTW. If you remember, my wife is also about due now. Your first, my third. Good luck! From vandys@glare.cisco.com Fri Aug 5 09:18:24 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA04656; Fri, 5 Aug 1994 09:18:23 -0700 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA20328 for <vsta@cisco.com>; Fri, 5 Aug 1994 10:19:10 -0700 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id NAA27434; Fri, 5 Aug 1994 13:19:04 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA18728; Fri, 5 Aug 1994 13:19:02 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199408051719.AA18728@world.std.com> Subject: SCSI server alpha test To: vsta@cisco.com Date: Fri, 5 Aug 1994 13:19:01 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1627 Hi, I'd like to find one or two alpha test sites for the VSTa 1.4 SCSI/CAM driver, which includes CDROM support. If you're interested, please send me an email message. I should have a package ready by the middle of next week. Here's the README file that describes what's included in the alpha package: Welcome to the alpha test version of the VSTa 1.4 SCSI/CAM driver and CDROM filesystem server. This package includes binary versions and README files for the following: cam - the VSTa SCSI driver cameo - a command utility that communicates directly w/ cam cdfs - a ISO 9660 compatible CDROM filesystem server Note that sources for the above will of course be available in the next normal distribution of VSTa. What to Test ------------ I. cam - A. there's been some reorganization of the CAM code, so basic regression testing would be nice. B. CDROM support - hook up a SCSI CDROM drive to your SCSI bus, boot VSTa, and look for a boot message about the CDROM drive. If you get the boot message, proceed to II. II. cameo - A. look at the cameo README file for instructions on how to set devices and do various commands. B. try playing an audio CD III. cdfs - A. put an ISO 9660 formatted CDROM into the CDROM drive. B. look at the cdfs README file for instructions on how to mount a CDROM filesystem. C. try some ls's, cp's, etc. What Not to Test ---------------- I. >16MB support isn't quite hooked up yet. Problem Reports, Comments, etc. ------------------------------- Send them to larz@world.std.com. Thanks. Mike Larson From vandys@glare.cisco.com Fri Aug 5 16:27:12 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA04681; Fri, 5 Aug 1994 16:27:10 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA07875; Fri, 5 Aug 1994 17:10:46 -0700 Message-Id: <199408060010.RAA07875@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Debra_Knodel@3mail.3com.com, JKiefer@ucsd.edu, christej@cgrb.orst.edu, glkatz@cive.stanford.edu, tedfitz@crystald.com, vprice@adoc.xerox.com, chris.ebert@segaoa.com, SCHOCCAT%UREGINA1.BITNET@vm.utcc.utoronto.ca, scaggs@alchemy.com, nevdull@sequent.com, steve@ichips.intel.com, hf.jfk@forsythe.stanford.edu, gq.wck@forsythe.stanford.edu, rto@sequent.com, djg@swdc.stratus.com, meep@pyramid.com, mattbr@microsoft.com, VALENCIA_ANN@tandem.com, 75300.2772@CompuServe.COM, bbaer@sdd.hp.com, todd@psych.stanford.edu, gvaatveit@esri.com, jts@mri.com, lyle@hpda.cup.hp.com, drew@hpfcla.fc.hp.com, chapman@sco.com, jal%stella.sware.com@mathcs.emory.edu, ex-moto-list-request@grot.starconn.com, cn.ilb@forsythe.stanford.edu, cn.ils@forsythe.stanford.edu, cn.jen@forsythe.stanford.edu, mikek@sj.unisys.com, mtully@ups.edu, tinka@leland.stanford.edu, sbrommer@gsb-peso.stanford.edu, harp@athena.mit.edu, billw@cisco.com, syiu@cisco.com, tkolar@cisco.com, eschaffe@cisco.com, halaee@cisco.com, kph@cisco.com, irfan@cisco.com, carrel@cisco.com, lol@cisco.com, satya@cisco.com, achopra@cisco.com, vsta@amri.cisco.com Cc: vandys@cisco.com, jtk@netcom.com Subject: B-day! Date: Fri, 05 Aug 1994 17:10:46 -0700 From: Andrew Valencia <vandys@cisco.com> Andy and Jane Valencia are happy to announce the birth of their daughter, Amri Rose Valencia. She was born Thursday, August 4th at 6:54 PM, at a weight of 5 pounds 15 ounces. Mother and daughter are fine, father is fine except for being a little dazed. Regards, Andy & Jane From vandys@glare.cisco.com Fri Aug 5 16:27:38 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA04684; Fri, 5 Aug 1994 16:27:36 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA08461; Fri, 5 Aug 1994 17:28:26 -0700 Message-Id: <199408060028.RAA08461@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> Cc: vsta@amri.cisco.com Subject: Re: More VSTa info? In-Reply-To: Your message of "Fri, 05 Aug 1994 15:58:29 MDT." <Pine.3.87.9408051529.A17885-0100000@gpu.srv.ualberta.ca> Date: Fri, 05 Aug 1994 17:28:26 -0700 From: Andrew Valencia <vandys@cisco.com> [Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> writes:] >I posted the following to comp.os.misc and thought I would cc directly to >you for your unique insights. This was prompted by your response to a >request by someone for an OS meeting his list of requirements. Greetings. Yes, I saw your posting, and since you hadn't mailed it to me I assumed you wanted other people's opinions. Anyway, now that you've sent it to me.... >1) Who is working on VSTa apart from Mr. Valencia? About 6 really serious developers, and another dozen who send in bits and pieces. >2) How mature is the version available? In reliability or features? In reliability, it is probably superior to an early 386BSD release, but not up to a current FreeBSD release. In features, it lacks many things which a "full" OS would obviously havee. >3) How portable is this system? Pretty portable, ports to 68k and SPARC are in progress. >4) Is there a new windowing system forthcoming as well? > (Reflecting on the systems that influenced the OS, I expect > a fusion/hybrid of 8 1/2 and Photon!) Correct on the windowing system, although I hadn't heard about Photon? >5) How much emphasis will be placed on: > a) Distributed systems? (Spring, Alpha, QNX) Reasonably heavy, although I will note something about this below. > b) Object orientation? (Chorus COOL, Clouds) Much less. >6) How does the message engine compare with Minix? QNX? MPI? Far superior to Minix (1.1/1.2, I haven't looked at it since then). We use the usual VM tricks. Comparable to QNX, although clearly their product is far more finely tuned. >7) Will the system stay publicly available? Future plans? Yes, it'll always be copyleft. We're shooting now for better SCSI, a windowing system, networking, followed by distributed services. >8) Are device drivers and file systems demand loadable/unloadable? Yes. >9) Is the scheduler also a user task? (Workplace kernel) No. >10) Does the system distinguish between realtime and "batch" > tasks? Well, real-time and user-ish. It uses a hierarchical organization of scheduling nodes for user tasks, where nodes at the same level below a given node are scheduled "fair share" based on priority. >As I understand it, part of the raison d'etre for VSTa is to provide >the basis for an exploration of new concepts in OS design that >is accessable to anyone interested. I am also interested in its >potential to provide a basis for a new hardware paradigm emphasizing >high-speed links for near-distributed system. This doesn't sound necessarily incompatible, although there are many, many ways to go on this. Our current plans are to bring up networking, and then set things up so a server (which generally looks like a filesystem) can be mounted over the net. With that running, we can experiment on how we might make services available in a structured and consistent way. Now the "gotcha": most of us are widely separated across the Internet. Most likely, our focus is going to be on designs which map well to large latency connections. If you were to work on the distributed aspects, you might find some of us pushing the design in ways which maintain compatibility with slower connections. On the other hand, almost everything you're likely to be doing would work for both, and right now we don't have anybody actively working in this area anyway. Regards, Andy From vandys@glare.cisco.com Mon Aug 8 09:30:59 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA05039; Mon, 8 Aug 1994 09:30:57 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA19207; Mon, 8 Aug 1994 10:32:02 -0700 Message-Id: <199408081732.KAA19207@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> Cc: vsta@amri.cisco.com Subject: Re: More VSTa info? In-Reply-To: Your message of "Sun, 07 Aug 1994 01:19:15 MDT." <Pine.3.87.9408070115.A26029-0100000@gpu.srv.ualberta.ca> Date: Mon, 08 Aug 1994 10:32:02 -0700 From: Andrew Valencia <vandys@cisco.com> [Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> writes:] >A relatively small group. Are all of these people ones who were >associated with the project from its inception? No, people come and go. Of the core, one is an original bringup site. Two others of the "outer dozen" were original bringup sites as well. >> In features, it lacks many things which a "full" OS would obviously have. >Anything in particular, or are you refering to the broad collection of >utilities and features grafted onto systems as they mature? There you go. For instance, right now I'm porting RCS. It uses %.*s format for printf()'s--which wasn't there. Actually, not a great example. When I wrote VSTa the BSD distribution was under attack by USL, so I chose not to use it, nor any of its derivatives, Now that it's in the clear, we'll probably switch to its use. >Photon is a new product from Quantum Software. Ah, I didn't recollect it by this name, although I saw Dan's posting about a report on it being available. Yes, we're very much in line with QNX's thinking on these things, except that they're proprietary. :-( >> Far superior to Minix (1.1/1.2, I haven't looked at it since then). We use >> the usual VM tricks. Comparable to QNX, although clearly their product is >> far more finely tuned. >What qualities make it superior to Minix? (Layman's terms please) Simply, Minix uses copying because the 8088 did not have support for anything better. I use page remapping, because I targeted 32-bit/virtual memory processors. >I also >received a request from Dan H @ Quantum to cc any information to him. He >is interested in the comparison of message engines particularly. Please feel free to forward anything I write. >MPI is >a library based message system for heterogeneous system (I gather from >reading comp.parallel.mpi). How would this compare to a kernel based >system as implemented in VSTa? The VSTa messaging engine is only intended to do local system moving of messages. There are no hooks for placing networking code into the kernel, and we don't really plan for the kernel to cause messages to flow to a distant node via a networking protocol. Instead, VSTa's messaging engine would simply be used to connect a client with the local networking server, which would simply be another user-mode task. Thus, instead of: Machine1 | Machine2 USER Client1 | Client2 -------------------V------------------------------------^------ KERNEL Messaging->TCP/IP->Ethernet->TCP/IP->Messaging I plan: Machine1 USER Client1 TCP/IP Ether-> (to other machine) -------------------V-------^-V----^--- KERNEL (Messaging only) >Thanks for your reply. While I may not have anything to contribute to >your project, congratulations on what you and your contributors have >accomplished to date! Thanks! I didn't write it with any idea of "beating out" Linux/FreeBSD/ NetBSD/what-have-you. Rather, I wanted a set of software on which the various ideas surrounding "microkernels" could be explored. If you get enjoyment in cruising through the current VSTa source, I'm very satisfied. If you eventually contribute, so much the better! Regards, Andy Valencia From vandys@glare.cisco.com Mon Aug 8 14:50:24 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA05077; Mon, 8 Aug 1994 14:50:23 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA05890; Mon, 8 Aug 1994 15:50:58 -0700 Message-Id: <199408082250.PAA05890@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yhcrana <dd002b@uhura.cc.rochester.edu> Cc: vsta@amri.cisco.com Subject: Re: More VSTa info? In-Reply-To: Your message of "Mon, 08 Aug 1994 16:15:53 EDT." <199408082015.QAA10307@uhura.cc.rochester.edu> Date: Mon, 08 Aug 1994 15:50:57 -0700 From: Andrew Valencia <vandys@cisco.com> [yhcrana <dd002b@uhura.cc.rochester.edu> writes:] >I may be misunderstanding what follows, but would it not be very easy to >integrate Networking so that it was completely transparent? when the name >server returns a port, it would somehow indicate that that port was >somewhere else. Yes, I had pondered something like that. Alternatively, since the name lookup is in the C library, it would be easy enough to have open() and friends understand, for instance, node::path format. >using VM you could then use a copy-on-read scheme. this >would only be efficient for LAN set-ups, which may be why you are not >following that tact. Still, this would allow for vsta to be used on a >message-passing, multi-processor, while at present it could only take >advantage of a shared-memory multi-processor (this is what i have gathered >from perusing the code and your comments...) Yes, because VM granularity is 4K on the i486, and generally at least as large on other 32-bit processors, the granularity for message data is too large. I think I would much rather use message passing hardware in non-shared architectures as a very fast inter-node networking facility rather than a local node kernel messaging facility. >> Machine1 >> USER Client1 TCP/IP Ether-> (to other machine) >> -------------------V-------^-V----^--- >> KERNEL (Messaging only) >what are the advantages of this set-up? All your fancy code is out in user tasks. It can be debugged, unloaded, replaced, and so forth. With a little C library hackery, it can easily be made transparent even if it doesn't happen to reside in the kernel. Andy From vandys@glare.cisco.com Thu Aug 11 05:50:44 1994 Received: from dustbin.cisco.com (dustbin.cisco.com [131.108.1.27]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA05473; Thu, 11 Aug 1994 05:50:42 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by dustbin.cisco.com (8.6.8+c/CISCO.SUB_GATE.1.1) with SMTP id GAA16030 for <vsta@cisco.com>; Thu, 11 Aug 1994 06:51:30 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA28119; Thu, 11 Aug 1994 15:49:03 +0200 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA30518; Thu, 11 Aug 1994 15:43:33 +0200 Date: Thu, 11 Aug 1994 15:43:33 +0200 From: jw@ibch01.inf.tu-dresden.de (Wittenberger) Message-Id: <9408111343.AA30518@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Thoughts for discussion & info request Hello, this is going to become a longer mail, thanks for your patience. I have 5 topics: 0. Intro While working on my thesis I came to the point, that obviosly most if not all reliable, clean, elegant ... system designs all follow a particular structure. This structure is also found in natural language and scientific theories and something more. At least this applies to designs like smaltalk's MVC model, ETHOS's carier/rider seperation, CLOS, Sather's abstract classes and renaming scheme, "clean" client/server systems, modern interrupt handling and interrupt dipatching to tasks. But before I go on to write it finaly down and to realize that I may be wrong I need some more examples. From what I know about VSTa I'm sure it makes a good example. 1. first question Could please anyone explain the mechanism of comunication in VSTa in a somewhat detailed way. I don't look for the details of message passing that is relative easy to see from the well commented code. My question is more like: is the port number something like a unique identifier of a server, is the name a client knows for it something like a alias or more hard coded, is it possible to have different names for the same server in different client views? (The question may make a fool of myself, but at this abstract view it is hard to read it from the code whithout to risk a wrong guess. And at the time I'm not about to become a VSTa wizard.) 2. another question Same as above for the paging mechanism. How is it embedded in the system. I had a view at the swap server source, but I didn't manage to find: - where the decicion is made which page is to swap out or in - where the page is transfered (may be from the kernel?) - how the pager is activated and so on. For the two things above, when I'll have it understood, I'll go on to prepare some pages of paper. It shouldn't be the problem to translate it to english to help extending the poor documantation of VSTa. (Please would someone take the time and correct my english than :-() 3. reflections about the (initial) registered names For theorie *inside* an object (like an server or an object in obj. oriented manner) the name it has in the context it is used in has no meaning at all. (I think it's not worth to found this more; everyone refers to self by I not by it's 1st, 2nd or nick name.) The name of everything has a meaning only in the context this thing is refered / used in. Furthermore everyone how reflects about bindings (for names, classes and so on) comes to the statement: the later a binding is done, the more is known about the conditions, thats why the decicion get better. So far. Now when I have a look at the sources, there exist 2 way the name a server is registered under get determined. For some (good in my mind) examples, the name is provided at start up time by the command line (bfs, dos, tmpfs). But for some other it is hard coded. Sure, at this time, while the system is as "simple" as it is, there is no need not to hard code it. This degree of flexibility is not needed yet. But what when the system extends? So I propose to *generally* provide the name as a parameter and never code it hard. At this time, this is not a great deal, and I think is is worth the effort and pay in the future. Any thoughts? 4. put the server main into the library Going further the way from topic 3. Every main of a server will become almost equal. It will: a) get the name to register under from the command line b) pass any extra command line option to a (proposed) init routine c) register upon success under the given name d) call the (proposed) server_main routine. Why should it remain as a part of code copied for every server? May be it will be worth to code the server_main loop in a library function too. This had the disadvantage, that every server must provide a function of the same name for every possible message, even when some of them read msg_xxx(msg m, file f){}. But it had the advantage of not carrying a long almost constant funtion in every server. Thoughts? 5. go one step further I'm not sure if it is possible in VSTa, but with the above in mind, it should be possible, to build a server which may be called loader. This loader would allocate address space, memory, and an initial process for every server and program. Load the code, initialize it. So a lot of the exec system call could be moved out of the kernel into a server. Not that bad. May be this loader can later be modified to allocate only the address space and memory as shared readable. So we'll have the basis for shared libraries? How about that? So far. Know for a question which should *really* make a fool of myself and the complete university too. Nobody can tell me what a spinlock is. (Maybe I know it by another name? I hope.) From the code it looks like a cpu freese [cli()/sti()], but it's state and it former state is moved around for any reason. Please can someone enlighten me? /joerg ----------------------------------------------------------------------------- Joerg Wittenberger Rietzstr. 32b 01139 Dresden Germany email: jw@ibch50.inf.tu-dresden.de jw6@mail.inf.tu-dresden.de WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a> PGP PUBLIC KEY: available on request or by finger From vandys@glare.cisco.com Thu Aug 11 06:56:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA05483; Thu, 11 Aug 1994 06:55:23 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA18561 for <vsta@cisco.com>; Thu, 11 Aug 1994 07:53:59 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa28071; 11 Aug 94 15:19 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qYawF-0003zuC; Thu, 11 Aug 94 15:16 BST Message-Id: <m0qYawF-0003zuC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Anyone ported uuencode yet? To: VSTa mailing list <vsta@cisco.com> Date: Thu, 11 Aug 1994 15:16:59 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 70 Hi All, Has anyone ported uuencode/uudecode yet? Regards, Dave From vandys@glare.cisco.com Thu Aug 11 09:24:51 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA05511; Thu, 11 Aug 1994 09:24:49 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA28944; Thu, 11 Aug 1994 10:26:14 -0700 Message-Id: <199408111726.KAA28944@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jw@ibch01.inf.tu-dresden.de (Wittenberger) Cc: vsta@cisco.com Subject: Re: Thoughts for discussion & info request In-Reply-To: Your message of "Thu, 11 Aug 1994 15:43:33 +0200." <9408111343.AA30518@ibch01.inf.tu-dresden.de> Date: Thu, 11 Aug 1994 10:26:13 -0700 From: Andrew Valencia <vandys@cisco.com> [jw@ibch01.inf.tu-dresden.de (Wittenberger) writes:] >... is the port number something like a unique identifier of >a server, is the name a client knows for it something like a alias or >more hard coded, is it possible to have different names for the same >server in different client views? A port number (type port_name from <sys/types.h>) is indeed a unique identifier for a server port on a machine running VSTa. In general, a server allows the kernel to allocate an identifier dynamically, and then the server advertises itself by creating a file in /namer whose contents is its port_name. Thus, the "fd" server (floppy disk) might get the value 1027, and then he write "1027" onto /namer/disk/fd. When somebody wants to talk to the "fd" server, they open /namer/disk/fd, read the number 1027, and then msg_connect() to port_name 1027. A very few port_name's are "well known". The /namer server is always 1, This allows you to connect to /namer initially, otherwise there's the "chicken and egg" problem of how to find the service which helps you find services. >Same as above for the paging mechanism. How is it embedded in the >system. First, in the mailing list archives is a fairly detailed discussion of the VM system data structures. >- where the decicion is made which page is to swap out or in >- how the pager is activated We use the old BSD-style two handed clock algorithm. See the discussion of this in the book Kirk McKusick put out on BSD internals. >- where the page is transfered (may be from the kernel?) The kernel queues the I/O to the swap server. The swap server is potentially connected to a number of underlying physical devices, looks up the swap block number, finds out which device and which position that block lives at, and forwards the request. This allows the swap server to provide dynamic swap creation and deletion, interleaved swap, and so forth without any of this complex code living in the kernel. The kernel just lives in a wonderland of a single swap partition starting with block 0 and going up to block n-1 (for current swap size available of n). >So I propose to *generally* provide the name as a parameter and never >code it hard. At this time, this is not a great deal, and I think is >is worth the effort and pay in the future. I could buy this argument. When we get shared source control on-line I'd welcome you to commit patches to have all server behave similarly. >Going further the way from topic 3. Every main of a server will become >almost equal. It will: >... >Why should it remain as a part of code copied for every server? Well, there are a number of subtle variations. Some need I/O port range access, some need a couple ranges of I/O ports, some need to connect to other servers first, some don't. There are also some tricky issues with startup against an interrupt-driven I/O device. See the mach/wd server and the "partundef" variable, for instance. Gavin Nicol has also expressed interest in this area. I think it can be done, and would be an improvement. But don't be surprised if it's harder than you expected to map all the nasty little details into a common, shared routine. >May be it will be worth to code the server_main loop in a library >function too. This has even more subtle variations, since some servers have different needs for M_ABORT handling, and some have limitations in message segmenting. >This had the disadvantage, that every server must >provide a function of the same name for every possible message, even >when some of them read msg_xxx(msg m, file f){}. Well, you can have the servers provide pointers to functions instead, with uninitialized ones being NULL, and your shared server_main code taking default actions on NULL vectors. >But it had the >advantage of not carrying a long almost constant funtion in every >server. It's that "almost" contant that will bite you. Again, I think this is a good idea, but some hard work and thinking would be needed to actually implement it across all servers. I'd be happy to pitch in if you want to pursue it! Regards, Andy From vandys@glare.cisco.com Thu Aug 11 13:16:15 1994 Received: from dustbin.cisco.com (dustbin.cisco.com [131.108.1.27]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA05553; Thu, 11 Aug 1994 13:16:11 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by dustbin.cisco.com (8.6.8+c/CISCO.SUB_GATE.1.1) with SMTP id OAA28520 for <vsta@cisco.com>; Thu, 11 Aug 1994 14:17:27 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa26600; 11 Aug 94 21:52 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qYgfF-0003LqC; Thu, 11 Aug 94 21:23 BST Message-Id: <m0qYgfF-0003LqC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Thoughts for discussion & info request To: Wittenberger <jw@ibch01.inf.tu-dresden.de> Date: Thu, 11 Aug 1994 21:23:49 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <9408111343.AA30518@ibch01.inf.tu-dresden.de> from "Wittenberger" at Aug 11, 94 03:43:33 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6618 Hi, I'll leave some of the details as I expect other people may be able to answer some of your questions from a better "theoretical" perspective. I think I may be able to comment on some of the implementation stuff. Wittenberger wrote: > > 3. reflections about the (initial) registered names > > For theorie *inside* an object (like an server or an object in obj. > oriented manner) the name it has in the context it is used in has no > meaning at all. (I think it's not worth to found this more; everyone > refers to self by I not by it's 1st, 2nd or nick name.) > > The name of everything has a meaning only in the context this thing is > refered / used in. > > Furthermore everyone how reflects about bindings (for names, classes > and so on) comes to the statement: the later a binding is done, the > more is known about the conditions, thats why the decicion get better. > > So far. Now when I have a look at the sources, there exist 2 way the > name a server is registered under get determined. For some (good in my > mind) examples, the name is provided at start up time by the command > line (bfs, dos, tmpfs). But for some other it is hard coded. > > Sure, at this time, while the system is as "simple" as it is, there is > no need not to hard code it. This degree of flexibility is not needed > yet. But what when the system extends? > > So I propose to *generally* provide the name as a parameter and never > code it hard. At this time, this is not a great deal, and I think is > is worth the effort and pay in the future. > > Any thoughts? I've already been going through some of the device servers doing this before the next release. Certainly rs232, wd and fd now allow the namer "name" to be specified as a command-line option. I think what's tended to happen is that as there's been a need to allow multiple instances of a server, the capability for allowing user-specified names has been added. The filesystems came first as there are often multiple instances. Until rs232, fd and wd were modified to allow additional hardware config details to be specified there was only ever one instance, and thus only one name. Things such as nvram, joystick and mouse servers are really only going to have single instance (alright, I know I can have multiple mice, but I've never seen anyone use two :-)). It's a pretty trivial mod to make however. > 4. put the server main into the library > > Going further the way from topic 3. Every main of a server will become > almost equal. It will: > a) get the name to register under from the command line > b) pass any extra command line option to a (proposed) init routine > c) register upon success under the given name > d) call the (proposed) server_main routine. A couple of the servers already do something similar to (b) and (c) already. Unfortunately it seems (to me, but I'm no guru on such things) that initialisation sequences vary depending on what's being initialised. Certain types of server will always have the same sort of initialisation (eg filesystems), but some of the device servers do things in all sorts of orders. This is quite similar to the situation with FS_STAT/FS_WSTAT messages - by allowing each server to do things how it likes (just adopting a convention for a small number of details) we have maximum flexibility, but it makes unifying things more complex. I've found that this freedom is very useful as it allows making use of device specific details very easy, without sacrificing the the clean FS_READ/FS_WRITE type mechanisms used in normal operation. I think though that there may however be a good case for putting some command line option handling into a library. > Why should it remain as a part of code copied for every server? > > May be it will be worth to code the server_main loop in a library > function too. This had the disadvantage, that every server must > provide a function of the same name for every possible message, even > when some of them read msg_xxx(msg m, file f){}. But it had the > advantage of not carrying a long almost constant funtion in every > server. > > Thoughts? I thought about this a while back (although I never has time to try it). The biggest problem I could think of would be that we'd replace a large switch statement with a data structure that had a slot for each function that could be called as the result of a message being received - there are currently around 20 of these. In practice most of the servers don't handle all of them (often far fewer). The other effect I could envisage would be to create lots of little functions, and I suspect then end result will be to expand the overall size of the source files. Another idea I've discussed with a couple of people however, was the possibility of a file-system library. Certainly generalised data/block caching would be pretty simple, and with a bit of work we could use one library base to provide all of the filesystems with multithreading and common features. vstafs has the most different features of all of the filesystems - it's fairly simple to see how caching of blocks is just a subset of caching runs of disk sectors. bfs and dos have almost identical block caching code, so it gets simpler every time one considers the problem. Other library posibilities exist for merging some of the mouse and joystick code, and some of the fixed disk code's already been put into libdiskfs. > 5. go one step further > > I'm not sure if it is possible in VSTa, but with the above in mind, it > should be possible, to build a server which may be called loader. > > This loader would allocate address space, memory, and an initial > process for every server and program. Load the code, initialize it. > > So a lot of the exec system call could be moved out of the kernel into > a server. Not that bad. > > May be this loader can later be modified to allocate only the address > space and memory as shared readable. So we'll have the basis for > shared libraries? > > How about that? I've probably misunderstood something here, but I think that the code in libc/mach/exec.c already does a lot of this. Perhaps with a bit of work this could be made to do something similar to what you mention. As far as having a loader server goes, I've always found the concept a little awkward. The cleanest solution I've come across is the mechanism used in the Oberon system, where the bootstrap code loads a loader at the same time as the kernel. All of Oberon's "libraries" are demand loaded, and this module does the demand loading. I guess you're thinking of something similar? Regards, Dave From vandys@glare.cisco.com Sun Aug 14 04:36:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA12478; Sun, 14 Aug 1994 04:36:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA22955 for <vsta@cisco.com>; Sun, 14 Aug 1994 05:37:34 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA01339; Sun, 14 Aug 1994 14:38:48 +0200 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA17961; Sun, 14 Aug 1994 14:33:25 +0200 Date: Sun, 14 Aug 1994 14:33:25 +0200 From: jw@ibch01.inf.tu-dresden.de (Wittenberger) Message-Id: <9408141233.AA17961@ibch01.inf.tu-dresden.de> To: dave@humbug.demon.co.uk Cc: vsta@cisco.com In-Reply-To: <m0qYgfF-0003LqC@humbug.demon.co.uk> (message from Dave Hudson on Thu, 11 Aug 1994 21:23:49 +0100 (BST)) Subject: Re: Thoughts for discussion & info request Dave wrote: > I've already been going through some of the device servers doing this > before the next release. Certainly rs232, wd and fd now allow the namer > "name" to be specified as a command-line option. I think what's tended to Good :-) > happen is that as there's been a need to allow multiple instances of a > server, the capability for allowing user-specified names has been added. > The filesystems came first as there are often multiple instances. Until > rs232, fd and wd were modified to allow additional hardware config details > to be specified there was only ever one instance, and thus only one name. > > Things such as nvram, joystick and mouse servers are really only going to > have single instance (alright, I know I can have multiple mice, but I've > never seen anyone use two :-)). It's a pretty trivial mod to make however. Yes, the're going to have a single instance, but that doen't matter: 1st: It's a question of unification (or even called polymorphism). If I used different schemes I'll allway have to remember which one is appropriate. My brain is sometimes too small for that. (What would you say, if the c-compiler would require you to not a multiplication for integers like 2*3 while for floats like *(2,3).) 2nd: With the mouse we here got into deep trouble at exactly this point. (We had worked with an similar system written some years ago.) Imagine, you have a mouse server with 2 buttons and a client for it. Now you have a second client which needs a 3 button mouse. Both call their server /dev/mouse. Great dilemma. If you extend the 2 button server to emulate the 3rd button, you may break the 2 button client. The solution would be, to register both servers under a new, different name. Say the old 2 button one as /dev/mouse2b, the new (build on to of the old) als /dev/mouse3emu. Then you may bind the name /dev/mouse to /dev/mouse2b in the namespace for the old client, and to /dev/mouse3emu for the new client. (BTW: how would that be done in VSTa???) But how the hell, should the author of the old 2 button server know that it will ever needed to do such? He can't! That reminds me to an older discussion about a gnu readline server. (I didn't say anything to it because I just felt other than Andy's mind, but know I have an argument.) In the former discussion Andy wrote (cited from memory): The readline can be done in the library, so it shouldn't go to a server. And expressed that code should go as less as possible to the kernel, better to a server, best to the library. A don't disagree in general, because for a heuristic decision it is really the best way. But in the special case he is wrong. Why? All server can be viewed as a meta abstraction of a service. The flexibiltiy this provides is that inside your code you haven't to worry about how the server works. As long as you make allowed requests the server is responsible to do so. (If it fails, don't change the client, fix the server.) Because that fact, you can exchange a server with another one to meet your needs. That is to change the implementation of a meta system in a opaque way. In other words, whenever some detail may be changed without disturbing what is build on to of this detail, a meta abstraction is appropriate. In a c/s system this is called a server. Now for the readline: it is really a server itself, even if it doesn't use help of the system to be a server. It provides some service, i.e. to deliver a command line. In an opaque way (from the client view), it let's you edit the command line. In fact it is really more the only a server, it has a meta interface. At this interface you may change to the vi or emacs behavior or you may change it completly. The very best solution to have things like that done in c/s systems is to complete remove such code from clients (i.e. programs) and have a server avialable. When the system boots there is no need to load a server like the readline. Imagine the all the system (in a special case) does is to run some scripts and it is controled by the mouse, a server which one behaves like the plain unix kernel is full sufficient. But if a user likes all the programms to behave like a readline, a server may be started and shadow the name of the old one. All programm started later will have the readline, even if the where written bevor the readline were invented. The problem, we have is, that at the compile/link time all the abstractions made and stored in the same system get dissolved, while meta abstractions get dissolved when they are used. > > I'm not sure if it is possible in VSTa, but with the above in mind, it > > should be possible, to build a server which may be called loader. ... > > So a lot of the exec system call could be moved out of the kernel into > > a server. Not that bad. > > > > May be this loader can later be modified to allocate only the address > > space and memory as shared readable. So we'll have the basis for > > shared libraries? ... > I've probably misunderstood something here, but I think that the code in > libc/mach/exec.c already does a lot of this. Perhaps with a bit of work > this could be made to do something similar to what you mention. > > As far as having a loader server goes, I've always found the concept a > little awkward. The cleanest solution I've come across is the mechanism > used in the Oberon system, where the bootstrap code loads a loader at the > same time as the kernel. All of Oberon's "libraries" are demand loaded, and > this module does the demand loading. I guess you're thinking of something > similar? Exactly. Beside thinking about relativ "easy" (with respect to the mechanism, not the efford to code) things like an exec-server, I think about a way to move the scheduling algorithms (for cpu and memory) out of the kernel, but I didn't come to a clean solution yet. (That's way I asked, in my mail, where the algorithm is. From Andys mail I read, the decision for the RAM is made in the kernel, while the one for the swap space is made in the swaper. Am I right?) BTW: Andy told me to look for the algorithm in some BSD book. Recently I tried to lend for books from the university library here. All 4 times I was told that it will take 4 to 8 weeks to get it. Yeah, they are really slow on ISBN # started by a 0! Scince the iron wall has fallen it is at least as dark as bevor east of the line. The only way to get recently info's is by the internet. But about 1000 students and the stuff shares a 1200 baud line... For this reason I have a little fear, what solution may I have to invent when the remote-svc is up. From vandys@glare.cisco.com Sun Aug 14 23:31:33 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA12668; Sun, 14 Aug 1994 23:31:32 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA12692 for <vsta@cisco.com>; Mon, 15 Aug 1994 00:33:16 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15605; 15 Aug 94 8:20 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qZwKX-00041zC; Mon, 15 Aug 94 08:19 BST Message-Id: <m0qZwKX-00041zC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Thoughts for discussion & info request To: VSTa mailing list <vsta@cisco.com> Date: Mon, 15 Aug 1994 08:19:36 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2103 Hi, Wittenberger wrote: > > The solution would be, to register both servers under a new, different > name. Say the old 2 button one as /dev/mouse2b, the new (build on to > of the old) als /dev/mouse3emu. Then you may bind the name /dev/mouse > to /dev/mouse2b in the namespace for the old client, and to > /dev/mouse3emu for the new client. > (BTW: how would that be done in VSTa???) > But how the hell, should the author of the old 2 button server know > that it will ever needed to do such? He can't! Well, after I did some work on the serial and ps/2 mouse code a couple of months back I think the server handles both 2 and 3 button mice automatically (it's possible on these 2 types to handle 2 button mice as a subset of 3 button mice). As for the problem with what we call them, I can see two easy ways to implement this: 1) We could simply call the mouse srv/mouse (as we do now) and use the FS_WSTAT mechanism to allow the client to specify the mode of operation. As an example we could define "btnemu" which could take an number of arbitrary states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's an exagerated example, but I think it gives the general idea. 2) We could make the mouse server provide a subdirectory of possible server variants - whichever one is opened by the client would then define the server's behaviour, say: srv/mouse:2btn srv/mouse:3btn srv/mouse:2emu3btn When we mount the server into our namespace we can mount either the whole server namespace and have say: /dev/mouse/2btn /dev/mouse/3btn /dev/mouse/2emu3btn or we could mount the individual server variant we require and just call it /dev/mouse. In this instance I'd have a personal leaning towards solution 1, but there's no good reason that I can point at for this, as with the modified fd server I've used the second approach to allow the user to specify the media type in the drive. It's exactly this sort of flexibility in server coding that makes me prefer VSTa to say Unix (although it did take me a couple of months to appreciate the benefits). Regards, Dave From vandys@glare.cisco.com Mon Aug 15 05:16:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA12786; Mon, 15 Aug 1994 05:16:57 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA24146 for <vsta@cisco.com>; Mon, 15 Aug 1994 06:18:41 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA00459; Mon, 15 Aug 94 09:19:28 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA18271; Mon, 15 Aug 1994 09:19:28 +0500 Date: Mon, 15 Aug 1994 09:19:28 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9408151319.AA18271@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <m0qZwKX-00041zC@humbug.demon.co.uk> (message from Dave Hudson on Mon, 15 Aug 1994 08:19:36 +0100 (BST)) Subject: Re: Thoughts for discussion & info request Content-Length: 1343 >in the drive. It's exactly this sort of flexibility in server coding that >makes me prefer VSTa to say Unix (although it did take me a couple of months >to appreciate the benefits). This, and the fact that servers and the kernel are entirely seperate, were two of the major reasons I dropped Linux/Unix hacking in favor of VSTa. However, I am a little worried that there is no overall structure to the naming policy as yet. As Dave has noted, the naming policy has tended to evolve based on server needs. This is good in that the application is driving the implementation do a degree (so we don't end up with theoretically nice, but realistically unusable systems). I wonder if we have evolved enough to try to start deciding on some guidelines/conventions? Once I get back into mainstream VSTa hacking again, I'd like to explore this issue. I remain unconvinced that the way things are being done now is necessarily the best. I am biased toward an object based approach... BTW. One problem I can still see is something like MADO which cannot assume a fixed file system structure, but for which configuration information should be specifiable by the user (ie. It'd be nice to always assume a ~/.madorc, but I can't). Has anyone thought of beefing up the environment server, or writing something similar, to handle configuration data? From vandys@glare.cisco.com Mon Aug 15 07:32:51 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA12797; Mon, 15 Aug 1994 07:32:50 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA02797; Mon, 15 Aug 1994 08:34:36 -0700 Message-Id: <199408151534.IAA02797@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson <dave@humbug.demon.co.uk> Cc: VSTa mailing list <vsta@cisco.com> Subject: Re: Thoughts for discussion & info request In-Reply-To: Your message of "Mon, 15 Aug 1994 08:19:36 BST." <m0qZwKX-00041zC@humbug.demon.co.uk> Date: Mon, 15 Aug 1994 08:34:36 -0700 From: Andrew Valencia <vandys@cisco.com> [Dave Hudson <dave@humbug.demon.co.uk> writes:] >> The solution would be, to register both servers under a new, different >> name.... >Well, after I did some work on the serial and ps/2 mouse code a couple of >months back I think the server handles both 2 and 3 button mice >automatically... And this is why I prefer that the server just be named /dev/mouse. Rather than have a boundless number of names for the mouse (Logitech/Microsoft/ Mouse Systems/..., one- two- and three-button, bus and serial, ...) it'd be nice if the mouse server just presented a uniform /dev/mouse and then did what was necessary to make it fly. For instance, synthesizing a third button if it's missing. Andy From vandys@glare.cisco.com Mon Aug 15 08:15:50 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA12814; Mon, 15 Aug 1994 08:15:48 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA00831; Mon, 15 Aug 1994 09:17:34 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa16517; 15 Aug 94 17:16 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qa4g4-0000OoC; Mon, 15 Aug 94 17:14 BST Message-Id: <m0qa4g4-0000OoC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Thoughts for discussion & info request To: Andrew Valencia <vandys@cisco.com> Date: Mon, 15 Aug 1994 17:14:24 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199408151534.IAA02797@glare.cisco.com> from "Andrew Valencia" at Aug 15, 94 08:34:36 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1414 Andrew Valencia wrote: > > [Dave Hudson <dave@humbug.demon.co.uk> writes:] > > >> The solution would be, to register both servers under a new, different > >> name.... > >Well, after I did some work on the serial and ps/2 mouse code a couple of > >months back I think the server handles both 2 and 3 button mice > >automatically... > > And this is why I prefer that the server just be named /dev/mouse. Rather > than have a boundless number of names for the mouse (Logitech/Microsoft/ > Mouse Systems/..., one- two- and three-button, bus and serial, ...) it'd be > nice if the mouse server just presented a uniform /dev/mouse and then did > what was necessary to make it fly. For instance, synthesizing a third > button if it's missing. FWIW, I still prefer making the emulation of a 3rd button selectable via the FS_WSTAT mechanism, with the server reporting the number of buttons via FS_STAT. I've come across quite a few programs that assume that either the left or the right button can be pressed at the same time as a middle button (if it's present) - forcing the emulation can break things under these circumstances. BTW, I remembered my objection to using multiple names - it meant adding directory manipulation code to the mouse server where none previously existed. The fd server already had this code, so the additions to handle additional "files" was pretty straightforward. Regards, Dave From vandys@glare.cisco.com Tue Aug 16 04:09:16 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA12959; Tue, 16 Aug 1994 04:09:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA14012 for <vsta@cisco.com>; Tue, 16 Aug 1994 05:09:56 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA07521; Tue, 16 Aug 1994 14:09:26 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA18342; Tue, 16 Aug 1994 14:06:45 +0200 Date: Tue, 16 Aug 1994 14:06:45 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9408161206.AA18342@ibch50.inf.tu-dresden.de> To: vsta@cisco.com In-Reply-To: <9408151319.AA18271@ebt-inc.ebt.com> (gtn@ebt.com) Subject: Re: Thoughts for discussion & info request > This, and the fact that servers and the kernel are entirely seperate, > were two of the major reasons I dropped Linux/Unix hacking in favor of > VSTa. However, I am a little worried that there is no overall > structure to the naming policy as yet. As Dave has noted, the naming I strongly agree. > policy has tended to evolve based on server needs. This is good in > that the application is driving the implementation do a degree (so we > don't end up with theoretically nice, but realistically unusable > systems). I wonder if we have evolved enough to try to start deciding > on some guidelines/conventions? > > Once I get back into mainstream VSTa hacking again, I'd like to > explore this issue. I remain unconvinced that the way things are being > done now is necessarily the best. I am biased toward an object based > approach... Too. > > BTW. One problem I can still see is something like MADO which cannot > assume a fixed file system structure, but for which configuration > information should be specifiable by the user (ie. It'd be nice to > always assume a ~/.madorc, but I can't). Has anyone thought of beefing > up the environment server, or writing something similar, to handle > configuration data? > Damned. a couple of minitues ago it answerd Dave, because his reply arrived earlier by email. Dave, please forward it. I strongly agree. The fact is that a historical accident lead to a server ruled naming. What is needed is to make the name associated with an INSTANCE of anything, not with it CLASS. Moreover, the name must depend on the user (client) of the name, not oon the use object. For the last issue: Why can't you have the name of the config file given at startup time (on the command line) or mount the name of $HOME/.madorc to the file you like. (UHH, know I may have viiolated the terms of VSTa, but that is what I think it should go.) /joerg From vandys@glare.cisco.com Tue Aug 16 04:33:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA12966; Tue, 16 Aug 1994 04:33:08 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA14537; Tue, 16 Aug 1994 05:32:11 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA07841; Tue, 16 Aug 1994 14:32:19 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA18347; Tue, 16 Aug 1994 14:30:19 +0200 Date: Tue, 16 Aug 1994 14:30:19 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9408161230.AA18347@ibch50.inf.tu-dresden.de> To: dave@humbug.demon.co.uk Cc: vandys@cisco.com, vsta@cisco.com In-Reply-To: <m0qa4g4-0000OoC@humbug.demon.co.uk> (message from Dave Hudson on Mon, 15 Aug 1994 17:14:24 +0100 (BST)) Subject: Re: Thoughts for discussion & info request > > And this is why I prefer that the server just be named /dev/mouse. Rather > > than have a boundless number of names for the mouse (Logitech/Microsoft/ > > Mouse Systems/..., one- two- and three-button, bus and serial, ...) it'd be > > nice if the mouse server just presented a uniform /dev/mouse and then did > > what was necessary to make it fly. For instance, synthesizing a third > > button if it's missing. > > FWIW, I still prefer making the emulation of a 3rd button selectable via the > FS_WSTAT mechanism, with the server reporting the number of buttons via > FS_STAT. I've come across quite a few programs that assume that either the > left or the right button can be pressed at the same time as a middle button > (if it's present) - forcing the emulation can break things under these > circumstances. BTW, I remembered my objection to using multiple names - it > meant adding directory manipulation code to the mouse server where none > previously existed. The fd server already had this code, so the additions > to handle additional "files" was pretty straightforward. > > > Regards, > Dave > As I've said. To change the behavior in this way lead to unneccessary complicated client code. (You need to set up the behavior at startup instead of having it ) (working anyway. ) Sure this solution is the one of traditional Unix like systems and so we may be more familliar with it. But VSTa isn't a unix like system. It may be made to behave so, but than it'll lost some benefits. (At the other hand it will be needed to do so for the reason of keeping well know and good applications working.) But in c/s systems, as in other object systems, it is better to have such things solved by simply renaming some stuff. From vandys@glare.cisco.com Tue Aug 16 04:29:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA12962; Tue, 16 Aug 1994 04:29:33 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA14403; Tue, 16 Aug 1994 05:27:51 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA07691; Tue, 16 Aug 1994 14:20:17 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA19368; Tue, 16 Aug 1994 14:18:22 +0200 Date: Tue, 16 Aug 1994 14:18:22 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9408161218.AA19368@ibch50.inf.tu-dresden.de> To: vandys@cisco.com Cc: dave@humbug.demon.co.uk, vsta@cisco.com In-Reply-To: <199408151534.IAA02797@glare.cisco.com> (message from Andrew Valencia on Mon, 15 Aug 1994 08:34:36 -0700) Subject: Re: Thoughts for discussion & info request > >> The solution would be, to register both servers under a new, different > >> name.... > >Well, after I did some work on the serial and ps/2 mouse code a couple of > >months back I think the server handles both 2 and 3 button mice > >automatically... > > And this is why I prefer that the server just be named /dev/mouse. Rather > than have a boundless number of names for the mouse (Logitech/Microsoft/ > Mouse Systems/..., one- two- and three-button, bus and serial, ...) it'd be > nice if the mouse server just presented a uniform /dev/mouse and then did > what was necessary to make it fly. For instance, synthesizing a third > button if it's missing. > > Andy To stick to the example: Yes, I agree. From the client view there *must* be one name like /dev/mouse. A client must never be forced to distinguish between different mouse's. (If you give it the wrong one it's you fault.) But from the server view it is very bad to be forced to make an update all the time anything new is invented. Better new server for the new feature is written and the old one is replaced. But this works only for clients of the new thing, the old one *may* break. (Or it is just hard to keep it working.) So you better have some aliasing and forwarding done and all is fine. But for that you need to change the name a very long time after writing a server. /joerg From vandys@glare.cisco.com Tue Aug 16 05:30:52 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA12973; Tue, 16 Aug 1994 05:30:50 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA16293 for <vsta@cisco.com>; Tue, 16 Aug 1994 06:32:33 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA08235; Tue, 16 Aug 94 09:33:18 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA12036; Tue, 16 Aug 1994 09:33:18 +0500 Date: Tue, 16 Aug 1994 09:33:18 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9408161333.AA12036@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <9408161206.AA18342@ibch50.inf.tu-dresden.de> (jw@ibch50.inf.tu-dresden.de) Subject: Re: Thoughts for discussion & info request Content-Length: 771 >I strongly agree. The fact is that a historical accident lead to a >server ruled naming. What is needed is to make the name associated >with an INSTANCE of anything, not with it CLASS. Moreover, the name >must depend on the user (client) of the name, not oon the use object. I agree. Are you planning to do any work on an object system for VSTa? If so, let's discuss the issues. >For the last issue: Why can't you have the name of the config file >given at startup time (on the command line) or mount the name of >$HOME/.madorc to the file you like. Because I cannot assume a file exists, or even that a filesystem exists. Also, this data is user specific (ie. for each user connecting to the server, I need to access such data). I need to think more about this... From vandys@glare.cisco.com Tue Aug 16 05:55:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA12992; Tue, 16 Aug 1994 05:55:38 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA17133 for <vsta@cisco.com>; Tue, 16 Aug 1994 06:57:30 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa23073; 16 Aug 94 14:42 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qaOjI-0000QwC; Tue, 16 Aug 94 14:39 BST Message-Id: <m0qaOjI-0000QwC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Thoughts for discussion & info request To: VSTa mailing list <vsta@cisco.com> Date: Tue, 16 Aug 1994 14:39:03 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6909 dave wrote: From dave Tue Aug 16 14:29:50 1994 Subject: Re: Thoughts for discussion & info request To: jw@ibch50.inf.tu-dresden.de (Wittenberger) Date: Tue, 16 Aug 1994 14:29:50 +0100 (BST) In-Reply-To: <9408161058.AA18251@ibch50.inf.tu-dresden.de> from "Wittenberger" at Aug 16, 94 12:58:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6460 Wittenberger wrote: > > > > Well, after I did some work on the serial and ps/2 mouse code a couple of > > months back I think the server handles both 2 and 3 button mice > > automatically (it's possible on these 2 types to handle 2 button mice as a > > subset of 3 button mice). > > I think you didn't get what I'm talking about. It is not the problem > that you might have 2 and 3 button at the same time. It's a matter of > evolution. When you had only 2 button you can only write code for 2 > button. Period. It's just because you can't know that anybody will > ever invent the 3rd button. When the 3rd button is added later you run > into the typical problem of needing an update. But with the ability of > renaming and aliasing its just a little extention which never affects > anything else. I agree - a 4 button mouse would present a problem, in which case having two servers would be a reasonable idea, although in practice we could only have one loaded at a time as they'd both be trying to control the same hardware resource (In fact, the second one would fail during loadup and not run). A lot would depend on how important backward compatibility really was to the server however, as there are ways that this can be implemented, but I'll discuss this in a few lines. > (Over all, the problem with the mouse is just a example, and because > of the fact, that the 3rd button of the mouse is older than VSTa it is > no real problem with VSTa. But which example should I chose about > things not invented yet?) The mouse is probably a bad example :-) > > As for the problem with what we call them, I can see two easy ways to > > implement this: > > > > 1) We could simply call the mouse srv/mouse (as we do now) and use the > > FS_WSTAT mechanism to allow the client to specify the mode of operation. As > > an example we could define "btnemu" which could take an number of arbitrary > > states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's > > an exagerated example, but I think it gives the general idea. > > And now the old code would never work, because it dosn't know about > the new extention of FS_WSTAT. > > Or the old behavior is default, then the new code is filled up with > unneccessary code for changing the mode. Code which doen't belong to > the work it really should do. Well it wouldn't have to be the default mode - it could just be a backward compatibility mode. The messaging mechanism means that we can use an arbitrary program to change the mode to whatever we require. When I'm working on servers I frequently use the "stat" command as this allows all of the stat fields to be read/written (assuming the user has sufficient privs - if they haven't then they can't swap server's either so it's a little academic). I agree however about not wanting to put extra code into a new version of a server just to make it work with old code. > > or we could mount the individual server variant we require and just call it > > /dev/mouse. > > > > That is what I'd like. But why mut we be forced to have the services > come from only one server? Well, at the moment there's the fundamental issue of each server being granted interrupts/dma channels at startup with no way of releasing these without the server exiting. I have mentioned this to Andy before (I'd really like to be able to do this anywhere in the server code as I could then do interrupt/dma autoprobing) In fact a lot more of the coding I did on wd, fd and rs232 was to handle specification of IRQ/DMA/IO address settings than specification of namer pathnames. > > In this instance I'd have a personal leaning towards solution 1, but there's > > I think it is because it is the custom, traditional way. I think I mentioned yesterday that I think the real reason was that of the two possibilities I mentioned, the first one involved less code (and thus less liklihood of bugs). In reality this particular case is more the exception rather than the rule as the mouse only handles a single device. In most cases, multiple devices, or cases where the behaviour required is not a simple subset of the default case would use solution 2. Whilst thinking about this I realised that what's actually happened is that any server that wants to be able to serve more than a single client at a time has adopted solution 2, and the others (eg the mouse) have adopted solution 1. I think this also emphasises the comment I made about using the solution that matches the complexity of the service being provided. As an example when I modified the rs232 server I continued to use solution 1 as this meets the requirements well for a single UART - if there are 2 UARTs we use two servers (shared code pages are wonderful!). I considered extending the server to allow multiport boards to work, but rejected this as it added a lot of complexity to have to deal with the different ways the boards would need to handle interrupts, etc. What I decided was that if I wanted to use a multiport board I'd write a server specifically for the task, giving me the simplest solution for both types of hardware - the multiport implementation would use solution 2 however as a different process might want to comunicate with each port. FWIW (and why I think the mouse was perhaps not an ideal example) I actually wanted to split the mouse server up - creating a "libmouse" for all of the common code and separate servers for the ps/2, rs232, microsoft bus and logitech bus mice. Having the rs232 mouse in there particularly bothers me still as it now relies on an rs232 server whereas the others don't need anything else. When I get some time I may still do this in fact, as it would be nice to make the rs232 mouse code system independent (for example I have an old Sun serial mouse that works fine on a PC's serial port). > > no good reason that I can point at for this, as with the modified fd server > > I've used the second approach to allow the user to specify the media type > > in the drive. It's exactly this sort of flexibility in server coding that > > makes me prefer VSTa to say Unix (although it did take me a couple of months > > to appreciate the benefits). > > I agree. But the question again, why should we get the benefit from > the flexibility after the definiton of the server but not before? I probably wasn't too clear in what I was saying - I hope I've explained my original comments a little better :-) Regards, Dave From vandys@glare.cisco.com Tue Aug 16 05:55:36 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA12989; Tue, 16 Aug 1994 05:55:34 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA17129 for <vsta@cisco.com>; Tue, 16 Aug 1994 06:57:25 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa23024; 16 Aug 94 14:42 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qaOgR-0000QvC; Tue, 16 Aug 94 14:36 BST Message-Id: <m0qaOgR-0000QvC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Thoughts for discussion & info request (fwd) To: VSTa mailing list <vsta@cisco.com> Date: Tue, 16 Aug 1994 14:36:06 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3714 Here's the note Joerg asked me to forward: Wittenberger wrote: > From irz301.inf.tu-dresden.de!ibch50.inf.tu-dresden.de!jw Tue Aug 16 13:30:14 1994 > Date: Tue, 16 Aug 1994 12:58:11 +0200 > From: Wittenberger <jw@ibch50.inf.tu-dresden.de> > Message-Id: <9408161058.AA18251@ibch50.inf.tu-dresden.de> > To: dave@humbug.demon.co.uk > In-Reply-To: <m0qZwJB-00041zC@humbug.demon.co.uk> (message from Dave Hudson on Mon, 15 Aug 1994 08:18:13 +0100 (BST)) > Subject: Re: Thoughts for discussion & info request > > > > Well, after I did some work on the serial and ps/2 mouse code a couple of > > months back I think the server handles both 2 and 3 button mice > > automatically (it's possible on these 2 types to handle 2 button mice as a > > subset of 3 button mice). > > I think you didn't get what I'm talking about. It is not the problem > that you might have 2 and 3 button at the same time. It's a matter of > evolution. When you had only 2 button you can only write code for 2 > button. Period. It's just because you can't know that anybody will > ever invent the 3rd button. When the 3rd button is added later you run > into the typical problem of needing an update. But with the ability of > renaming and aliasing its just a little extention which never affects > anything else. > > (Over all, the problem with the mouse is just a example, and because > of the fact, that the 3rd button of the mouse is older than VSTa it is > no real problem with VSTa. But which example should I chose about > things not invented yet?) > > > > > As for the problem with what we call them, I can see two easy ways to > > implement this: > > > > 1) We could simply call the mouse srv/mouse (as we do now) and use the > > FS_WSTAT mechanism to allow the client to specify the mode of operation. As > > an example we could define "btnemu" which could take an number of arbitrary > > states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's > > an exagerated example, but I think it gives the general idea. > > And now the old code would never work, because it dosn't know about > the new extention of FS_WSTAT. > > Or the old behavior is default, then the new code is filled up with > unneccessary code for changing the mode. Code which doen't belong to > the work it really should do. > > > > > 2) We could make the mouse server provide a subdirectory of possible server > > variants - whichever one is opened by the client would then define the > > server's behaviour, say: > > > > srv/mouse:2btn > > srv/mouse:3btn > > srv/mouse:2emu3btn > > > > Yes, but the same problem applies. You have to comlete update the > server. > > > When we mount the server into our namespace we can mount either the whole > > server namespace and have say: > > > > /dev/mouse/2btn > > /dev/mouse/3btn > > /dev/mouse/2emu3btn > > > > or we could mount the individual server variant we require and just call it > > /dev/mouse. > > > > That is what I'd like. But why mut we be forced to have the services > come from only one server? > > > In this instance I'd have a personal leaning towards solution 1, but there's > > I think it is because it is the custom, traditional way. > > > no good reason that I can point at for this, as with the modified fd server > > I've used the second approach to allow the user to specify the media type > > in the drive. It's exactly this sort of flexibility in server coding that > > makes me prefer VSTa to say Unix (although it did take me a couple of months > > to appreciate the benefits). > > I agree. But the question again, why should we get the benefit from > the flexibility after the definiton of the server but not before? > > Regards > Joerg. > > From vandys@glare.cisco.com Tue Aug 16 07:23:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA13012; Tue, 16 Aug 1994 07:23:01 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA20510 for <vsta@cisco.com>; Tue, 16 Aug 1994 08:24:04 -0700 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA10335; Tue, 16 Aug 1994 17:25:04 +0200 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA22894; Tue, 16 Aug 1994 17:23:11 +0200 Date: Tue, 16 Aug 1994 17:23:11 +0200 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9408161523.AA22894@ibch50.inf.tu-dresden.de> To: dave@humbug.demon.co.uk Cc: vsta@cisco.com In-Reply-To: <m0qaOjI-0000QwC@humbug.demon.co.uk> (message from Dave Hudson on Tue, 16 Aug 1994 14:39:03 +0100 (BST)) Subject: Re: Thoughts for discussion & info request Dave wrote: > I agree - a 4 button mouse would present a problem, in which case having two > servers would be a reasonable idea, although in practice we could only have > one loaded at a time as they'd both be trying to control the same hardware > resource (In fact, the second one would fail during loadup and not run). Thats why I think VSTa has issues which have to be improved. > A lot would depend on how important backward compatibility really was to the > server however, as there are ways that this can be implemented, but I'll > discuss this in a few lines. Yes, but thats what everybody needs. Nobody can efford to remake all systems all the time. > Well it wouldn't have to be the default mode - it could just be a backward > compatibility mode. The messaging mechanism means that we can use an call it as you like it. I don't know whether there is a english version of the german idiom: "Namen sind Schall und Rauch" (word by word: Names are noise and dust.) > arbitrary program to change the mode to whatever we require. When I'm > working on servers I frequently use the "stat" command as this allows all of > the stat fields to be read/written (assuming the user has sufficient privs - > if they haven't then they can't swap server's either so it's a little > academic). But it makes lots of things. It makes a system complicate. It forces me to remember a lot of schemes and other things. But the same can be made in a simple renaming scheme. And that is more natural, because it is the way it is done by everyone everyday. It is the way language works! (BTW: that is why I cam across the issue. I tried to figure out, why something is called to be "easy to use", "clean" or so. It is, when is goes the natural way to behave like natural language. Sure there are technical ways to do it other, but that is why lot of gurus for special systems exist.) > Well, at the moment there's the fundamental issue of each server being > granted interrupts/dma channels at startup with no way of releasing these > without the server exiting. I have mentioned this to Andy before (I'd > really like to be able to do this anywhere in the server code as I could > then do interrupt/dma autoprobing) I don't know about the details. But at the first glance it looks like better splitting up the server in servers at first level, which are started from a server at second level... > I think I mentioned yesterday that I think the real reason was that of the > two possibilities I mentioned, the first one involved less code (and thus > less liklihood of bugs). I disagree. The 1st solution needs special code. The second need some arguments at startup, which can be handled in a uniform way. > (eg the mouse) have adopted solution 1. I think this also emphasises the > comment I made about using the solution that matches the complexity of the > service being provided. From the server view you are right. At least at the first moment, when no further development exists. But the server are there to be an abstraction level. When most servers are abstractions (that means here, they don't know about their context, i.e. name) and some not, the level above has to handle with more complexity. > As an example when I modified the rs232 server I continued to use solution 1 > as this meets the requirements well for a single UART - if there are 2 UARTs > we use two servers (shared code pages are wonderful!). I considered > extending the server to allow multiport boards to work, but rejected this as > it added a lot of complexity to have to deal with the different ways the > boards would need to handle interrupts, etc. What I decided was that if I > wanted to use a multiport board I'd write a server specifically for the > task, giving me the simplest solution for both types of hardware - the > multiport implementation would use solution 2 however as a different process > might want to comunicate with each port. In my mind that is really the one and only way. But you would never had to think about the issue, when the let call it primitiv first solution wouldn't have been there. By the way, I still can't figure out, why the dynamic named approach would need more code than the hard wired + FS_STAT. > FWIW (and why I think the mouse was perhaps not an ideal example) I actually > wanted to split the mouse server up - creating a "libmouse" for all of the > common code and separate servers for the ps/2, rs232, microsoft bus and > logitech bus mice. Having the rs232 mouse in there particularly bothers me > still as it now relies on an rs232 server whereas the others don't need > anything else. When I get some time I may still do this in fact, as it > would be nice to make the rs232 mouse code system independent (for example I > have an old Sun serial mouse that works fine on a PC's serial port). Ok, the mouse is not really the best example, It just one I cam accross in practice and on another system. In my mind, there should be x different servers. Each build from a common library on the mouse and some files special to the particular one to handle. At startup I'd like to select the one I wont to use and give it the name I like. This would allow me a flexibility I could never think of in traditional systems. Imagine I load 2 mouse servers, connect to devices and know I have 2. Sure nobody will use this. Really? No! Nobody can have it, traditionally. But imagine someone would have it. He may write a game for 2 people. For your problem with the rs232 mouse: I can't understand your problem. It is just the most natural solution I can think of. Why the hell should the rs232 code be duplicated in a second server? It's wasted work. (For me: I would never use a rs232 mouse server which is concurrent to the rs232 device server. I find this idea confusing. And I can imaging great trouble from this.) There is no good reason to have something independent from something else what is on a level closer to the hardware. /joerg From vandys@glare.cisco.com Wed Aug 17 00:32:53 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA00123; Wed, 17 Aug 1994 00:32:52 -0700 Received: from mail.swip.net (mail.swip.net [192.71.220.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id BAA25885 for <vsta@cisco.com>; Wed, 17 Aug 1994 01:38:37 -0700 Received: by mail.swip.net (8.6.8/2.01) id KAA15707; Wed, 17 Aug 1994 10:38:32 +0200 Received: by distinct.se (4.1/KTH-1.1) id AA00891; Wed, 17 Aug 94 10:18:30 +0100 From: lars@distinct.se (Lars Pensjo) Message-Id: <9408170918.AA00891@distinct.se> Subject: Object interfaces to Vsta To: vsta@cisco.com Date: Wed, 17 Aug 94 10:18:29 BST Reply-To: vsta@cisco.com X-Mailer: ELM [version 2.3 PL0] Wouldn't it be a good idea to create an object oriented interface to system services, libraries etc ? Now should be the right time to do this, before Vsta grows too much. What are the possibilities to also port g++ to the Vsta environment ? For example, most servers use quite a lot of common code. How about making a class for this ? Define a basic class for client process message management. This class would handle the switch-statement, and then call virtual member functions depending on the message type. It is now quite easy to override the function whose behaviour you want to change. This is also a better solution than a C-mechanism where you register call-back functions. There is some overhead as functions will be called indirectly through pointers instead of code being executed inline in the switch statement, but I really think it is minor. An example how it could look: class ServerBase { public: ServerBase(const char *namerName, int numUsers=16); void MainLoop(); protected: virtual void Connect(msg&); // New client virtual void Dup(msg&, file&); // Dup during exec virtual void Abort(msg&, file&); // Aborted operation virtual void Disconnect(msg&, file&); // Client done virtual void Open(msg&, file&); // Look up file from directory virtual void Read(msg&, file&); // Read file virtual void AbsRead(msg&, file&); // Set position, then read virtual void Write(msg&, file&); // Write file virtual void AbsWrite(msg&, file&); // Set position, then write virtual void Seek(msg&, file&); // Set new file position virtual void Stat(msg&, file&); // Tell about file virtual void Wstat(msg&, file&); // Set stuff on file virtual void Remove(msg&, file&); // Get rid of file virtual void Fid(msg&, file&); // File id. virtual void Rename(msg&, file&=; // Rename file/dir private: port_name nm; hash* filehash; // Map of all active users port_t port; // Port we receive contacts through }; This class should probably be split into two, where the base class doesn't handle hashing of clients. ------ Distinct Systems Lars Pensjo From vandys@glare.cisco.com Wed Aug 17 02:23:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA00133; Wed, 17 Aug 1994 02:23:41 -0700 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA03409 for <vsta@cisco.com>; Wed, 17 Aug 1994 03:29:28 -0700 Received: by netmail2.microsoft.com (5.65/25-eef) id AA21401; Wed, 17 Aug 94 03:30:14 -0700 Message-Id: <9408171030.AA21401@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 17 Aug 94 03:30:14 PDT X-Msmail-Message-Id: EBB9B289 X-Msmail-Conversation-Id: EBB9B289 From: Jonathon Tidswell (MS Research Fellow) <t-jont@microsoft.com> To: vsta@cisco.com Date: Wed, 17 Aug 94 20:19:41 TZ Subject: RE: Object interfaces to Vsta ---------- > From: Lars Pensjo <lars@distinct.se> > To: <vsta@cisco.com> > Subject: Object interfaces to Vsta > Date: Wednesday, 17 August 1994 10:18 > > > Wouldn't it be a good idea to create an object oriented interface to > system services, libraries etc ? Now should be the right time to do this, > before Vsta grows too much. It depends on which OO language people wish to use. I don't accept, a priori, that C++ is the "right" OO language, it depends, at least in part, on what you wish to use the OO language for. Do you wish to develop system services in an OO environment or just provide an OO environment for people to experiment/work in. [ Note I am (possibly inappropriately) distinguishing system from non-system services. ] > What are the possibilities to also port g++ to the Vsta environment ? > For example, most servers use quite a lot of common code. How about making a > class for this ? Please don't assume all people "love" objects. Also see the long running discussion on g++ vs gcc in the Linux community. [ Partial summary: Linus used C++ for its better type checking, but the community wanted C because on their poor slow machines g++ compiles took hours or days not minutes --- g++ was too resource hungry --- it ended up with lots of #ifdef's. ] > Define a basic class for client process message management. This class would > handle the switch-statement, and then call virtual member functions > depending on the message type. > > It is now quite easy to override the function whose behaviour > you want to change. This is also a better solution than a C-mechanism > where you register call-back functions. My understanding is that virtual class methods are function pointer struct members. - JonT PS I am a postgraduate student on a scholarship not an employee of Microsoft. From vandys@glare.cisco.com Wed Aug 17 04:24:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00171; Wed, 17 Aug 1994 04:24:38 -0700 Received: from swann.irisa.fr (swann.irisa.fr [131.254.43.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA05770 for <vsta@cisco.com>; Wed, 17 Aug 1994 05:30:24 -0700 Received: (from thorn@localhost) by swann.irisa.fr (8.6.9/8.6.9) id OAA09429 for vsta@cisco.com; Wed, 17 Aug 1994 14:29:50 +0200 Date: Wed, 17 Aug 1994 14:29:50 +0200 From: Tommy Thorn <Tommy.Thorn@irisa.fr> Message-Id: <199408171229.OAA09429@swann.irisa.fr> To: vsta@cisco.com Subject: RE: Object interfaces to Vsta Jonathon Tidswell writes: > It depends on which OO language people wish to use. > I don't accept, a priori, that C++ is the "right" OO language, it > depends, at least in part, on what you wish to use the OO language for. I fully agree. One positive aspect of VSTa is that it's not strongly tied to any language, meaning that it's resonable to interface any favorite language, one might have. Forcing C++ though, would make that much harder, if not impossible. C is the smallest common denominator. > Please don't assume all people "love" objects. I personally get sick every time I hear the typical arguments for object oriented programming. There nothing magical about it. What matters are good concepts and clean interfaces. An operating system shouldn't be language dependent. There's nothing to stop anyone from porting g++ and writing servers in C++, and maybe even make a nice hieracy encapsulating the interface. I hope one day to write a server in Scheme. It would be a mistake, though, to force a language bias. All IMHO of course. As a non-contributer, my view shouldn't count much. Regards, Tommy From vandys@glare.cisco.com Wed Aug 17 05:07:18 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00177; Wed, 17 Aug 1994 05:07:16 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA06992 for <vsta@cisco.com>; Wed, 17 Aug 1994 06:13:01 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15213; 17 Aug 94 13:50 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qakPn-0000TgC; Wed, 17 Aug 94 13:48 BST Message-Id: <m0qakPn-0000TgC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Object interfaces to Vsta To: VSTa mailing list <vsta@cisco.com> Date: Wed, 17 Aug 1994 13:48:23 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4047 Jonathon Tidswell wrote: > > > ---------- > > From: Lars Pensjo <lars@distinct.se> > > To: <vsta@cisco.com> > > Subject: Object interfaces to Vsta > > Date: Wednesday, 17 August 1994 10:18 > > > > > > Wouldn't it be a good idea to create an object oriented interface to > > system services, libraries etc ? Now should be the right time to do this, > > before Vsta grows too much. > It depends on which OO language people wish to use. > I don't accept, a priori, that C++ is the "right" OO language, it > depends, at least in > part, on what you wish to use the OO language for. > Do you wish to develop system services in an OO environment or just provide an > OO environment for people to experiment/work in. > [ Note I am (possibly inappropriately) distinguishing system from non-system > services. ] I'd really like to get an Oberon-2 compiler running on VSTa (already discussing it with the guys who did Linux Oberon), but that would be to see how well it worked - not to convert the existing code over. One of the things I really like about VSTa's message passing system is that I don't have to implement every server in exactly the same way and with the same tools - I've always wanted to be able to experiment. FWIW I think that the distinction between system and non-system services is a little grey - the only thing I'd really be worried about tampering with would be the kernel. > > What are the possibilities to also port g++ to the Vsta environment ? Shouldn't be too difficult - it already ports to DOS. When I did my run on GNU tools a couple of months back, if it ported to DOS it was easiest to start with that as a base and remove any of the code that stopped things like pipes from being used. When 1.4's available the extra library code should make this fairly simple for anyone who'd care to try. I'm not sure how close we'll be to running configure scripts (pretty close I think), but at the worst we'd just need to run them on a Linux or xxxBSD box and then do a little bit of hand editing the makefiles. > > For example, most servers use quite a lot of common code. How about making a > > class for this ? > Please don't assume all people "love" objects. > Also see the long running discussion on g++ vs gcc in the Linux community. > [ Partial summary: Linus used C++ for its better type checking, but the > community > wanted C because on their poor slow machines g++ compiles took hours or days > not minutes --- g++ was too resource hungry --- it ended up with lots > of #ifdef's. ] I think the other part of this debate (I don't know if you read the Linux kernel channel) was that g++ kept generating the wrong code and introducing obscure bugs/races. I don't know about 2.6.0 though - anyone tried it yet? > > Define a basic class for client process message management. This class would > > handle the switch-statement, and then call virtual member functions > > depending on the message type. > > > > It is now quite easy to override the function whose behaviour > > you want to change. This is also a better solution than a C-mechanism > > where you register call-back functions. > My understanding is that virtual class methods are function pointer > struct members. Perhaps the best way to determine the effects would be to cross compile a server with this sort of class library. I'd think a good idea would be to code a dummy server that provides access to a single data file (as a primitive file server) - it should only take a couple of hours to code one in C. If we then have an identical C++ based server we can measure preformance on accesses to both servers (and we can also look at how large both are). (Just for completeness I think both the C and C++ servers should be compiled on the same version of gcc/g++ and with the same optimisations set). I'm not trying to make any philosophical points here - it just seems like a good way to get some sort of practical answer to something that seems to be causing more religious wars in the newsgroups by the day :-( Regards, Dave From vandys@glare.cisco.com Wed Aug 17 06:14:47 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00188; Wed, 17 Aug 1994 06:14:46 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA09212 for <vsta@cisco.com>; Wed, 17 Aug 1994 07:20:31 -0700 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id HAA12002; Wed, 17 Aug 1994 07:20:25 -0700 Message-Id: <199408171420.HAA12002@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Wed, 17 Aug 1994 07:20:25 PDT In-Reply-To: Dave Hudson <dave@humbug.demon.co.uk>' <m0qakPn-0000TgC@humbug.demon.co.uk> Re: Object interfaces to Vsta Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Dave Hudson <dave@humbug.demon.co.uk>, VSTa mailing list <vsta@cisco.com> Subject: Re: Object interfaces to Vsta From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: Object interfaces to Vsta > Shouldn't be too difficult - it already ports to DOS. When I did my run on > GNU tools a couple of months back, if it ported to DOS it was easiest to start I had gcc 2.4.5 G++ cross compiling for VSTa when I was hacking on it a while ago. The Vsta support is still in our G++ sources, I need to submit the patch to the FSF, all the other GNU tools getting VSTa support out on the net was easy. > I think the other part of this debate (I don't know if you read the Linux > kernel channel) was that g++ kept generating the wrong code and introducing > obscure bugs/races. I don't know about 2.6.0 though - anyone tried it yet? 2.6.0 definetely has bugs, but that's cause the FSF doesn't believe in regression testing, they'd rather let net folks find the bugs. Anyway, I'll try to make sure my VSTa patch still works, if so I can get it added to the Net sources. :-) > Perhaps the best way to determine the effects would be to cross compile a > server with this sort of class library. I'd think a good idea would be to > both are). (Just for completeness I think both the C and C++ servers should > be compiled on the same version of gcc/g++ and with the same optimisations > set). I tried this, and got held up in the C libraries. Maybe 1.4 will solve my problems. I'm working on a GCC/GDB port now to an HPPA embedded target, I'll see if I can find alittle time to cleanup GCC/G++ and do a quicky source release (if anyone would want one). I'd *love* to get a GDB port working... - rob - From vandys@glare.cisco.com Wed Aug 17 08:50:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00211; Wed, 17 Aug 1994 08:50:08 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA16091 for <vsta@cisco.com>; Wed, 17 Aug 1994 09:55:51 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA01261; Wed, 17 Aug 94 12:56:34 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA09451; Wed, 17 Aug 1994 12:56:33 +0500 Date: Wed, 17 Aug 1994 12:56:33 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9408171656.AA09451@ebt-inc.ebt.com> To: vsta@cisco.com In-Reply-To: <9408170918.AA00891@distinct.se> (lars@distinct.se) Subject: Re: Object interfaces to Vsta Content-Length: 1802 >Wouldn't it be a good idea to create an object oriented interface to >system services, libraries etc ? Now should be the right time to do this, >before Vsta grows too much. Like most, I don't think we should force C++ on people. A long time ago (6 months or more), I was thinking very deeply about an object system for VSTa. My idea was to use the CORBA ideas, and to create an IDL to C compiler. My reasoning for using IDL is that it is language independent, but is a good language for defining *interfaces*, while not forcing any given implementation. As such, we can use IDL to specify what services will be available from a given server (object if you like), but we can feel free to code it any way we want, giving us a nice "meta-level". I still think this is a viable, and indeed desirable thing to do, though it might be good to do this outside the mainstream VSTa development. Some parts (like defining a messaging protocol, and interface repository) would be good in general though. BTW. One objection I have to the "natural" approach that joerg talks about is that "naturalness" is necessarily tied to societal and cultural background/values, so what might be natural for people from the USA, will be almost incomprehensible to someone from China. In an artificial system, the best we can hope for is to develop a universally understood *artificial* system, like calculus, to act as a bridge. OOP is a good example of this (ie. many people do not think of "objects" but everyone understands bytes). While I am very hesitant to recommend it, there is an IDL to C++ complier in X11R6 (in Fresco). I prefer the IDL CFE from the OMG, but getting a C compiler from that might be more work. Just in case someone wants to *try* IDL :-) Once MADO is done, I *will* be looking into this again. From vandys@glare.cisco.com Wed Aug 17 09:03:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00216; Wed, 17 Aug 1994 09:03:03 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA16607 for <vsta@cisco.com>; Wed, 17 Aug 1994 10:08:48 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA01277; Wed, 17 Aug 94 13:09:05 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA09622; Wed, 17 Aug 1994 13:08:52 +0500 Date: Wed, 17 Aug 1994 13:08:52 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9408171708.AA09622@ebt-inc.ebt.com> To: all@ebt.com, vsta@cisco.com, cwh@basistech.com, bob@gnu.ai.mit.edu Subject: It's a boy! Content-Length: 332 My wife Chikako and I are happy to announce the birth of our third son. He was born at 10:15pm today, weighs in at 3440g, and 52cm. The name is yet to be announced. The birth was exceptionally easy on both the mother and the baby. Both are in excellent condition. My cup floweth over indeed! An experience heartily recommended! From vandys@glare.cisco.com Wed Aug 17 19:31:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00281; Wed, 17 Aug 1994 19:31:05 -0700 Received: from uucp0.iij.ad.jp (uucp0.iij.ad.jp [192.244.176.51]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id UAA12194 for <vsta@cisco.com>; Wed, 17 Aug 1994 20:36:54 -0700 Received: from uslp.UUCP (uucp@localhost) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-UUCP) with UUCP id MAA20714 for cisco.com!vsta; Thu, 18 Aug 1994 12:35:30 +0900 Message-Id: <199408180335.MAA20714@uucp0.iij.ad.jp> Subject: Re: Object interfaces to Vsta To: vsta@cisco.com Date: Thu, 18 Aug 94 12:31:14 JST From: Christopher Fraser <uslp!vinyard!chrisf@uucp0.iij.ad.jp> In-Reply-To: <9408170918.AA00891@distinct.se>; from "Lars Pensjo" at Aug 17, 94 10:18 am Reply-To: Christopher Fraser <chrisf@uslp.co.jp> X-Deleted-Return-Receipt-To: Christopher Fraser <chrisf@uslp.co.jp> X-Mailer: ELM [version 2.3 PL11] Content-Type: text Content-Length: 3184 Spoke Lars Pensjo thus: > > Wouldn't it be a good idea to create an object oriented interface to > system services, libraries etc ? Now should be the right time to do this, > before Vsta grows too much. The *architecture* is already quite "object oriented"; you have servers (objects) which communicate with each other via messages (methods) via some protocol (interface). The only real benefits in *implementing* in a language like c++ are some notational conveniences and better support for compile time interface checking. The costs are: a larger, heavier, buggier, slower tool set; c++ linking semantics (like multiple pass linking, name mangling); and having to live with a language which is a moving target for the ANSI standardisation committee (some of the more pessimistic people I work with doubt C++ will ever become standardised; there are just too many undefined constructs, and more keep appearing as existing ones are defined). Also, as far as the kenel programming is concerned, there are some C++ features that are just too risky to use, like static constructors. > What are the possibilities to also port g++ to the Vsta environment ? I guess that g++ itself wouldn't be much harder than gcc. Making libg++ thread-safe could require some work. There are some iostream functions, for example format() which are just not thread-safe. They may fallen out of favor these days, I haven't been keeping up with developments in C++ for a year or so. > For example, most servers use quite a lot of common code. How about making a > class for this ? > > Define a basic class for client process message management. This class would > handle the switch-statement, and then call virtual member functions > depending on the message type. > > It is now quite easy to override the function whose behaviour > you want to change. This is also a better solution than a C-mechanism > where you register call-back functions. For trivial servers, yes, but it's not a great benefit. All you're doing is pushing a smallish switch statement into the library. Also note that C++ only supports static classing, i.e. you can't change methods on the fly. As soon as your server has states like ``uninitialised'' and ``waiting-for-response'' you revert to standard procedural code. > There is some overhead as functions will be called indirectly through pointers > instead of code being executed inline in the switch statement, but I really > think it is minor. Yep. > An example how it could look: > > [ ... ] > > This class should probably be split into two, where the base class doesn't > handle hashing of clients. These ideas are well and good, but I don't think it's useful enough to mandate requiring C++ to build vsta. Incidentally, don't get me wrong ... I quite like programming in C++, but I think it's one of those right tools for he right problem things. Where I think C++ class could be more useful is in the encapsulation of connections to servers, where the interface to the class represents the interface to the server .... but at the moment I'm just waving my hands and don't really have any concrete ideas :-) Cheers, Christopher Fraser chrisf@sw.oz.au From vandys@glare.cisco.com Thu Aug 18 00:10:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA00296; Thu, 18 Aug 1994 00:10:09 -0700 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA18777 for <vsta@cisco.com>; Thu, 18 Aug 1994 01:16:01 -0700 Received: by netmail2.microsoft.com (5.65/25-eef) id AA28131; Thu, 18 Aug 94 01:16:48 -0700 Message-Id: <9408180816.AA28131@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 18 Aug 94 01:16:48 PDT X-Msmail-Message-Id: 21A31165 X-Msmail-Conversation-Id: 21A31165 From: Jonathon Tidswell (MS Research Fellow) <t-jont@microsoft.com> To: vsta@cisco.com Date: Thu, 18 Aug 94 18:04:39 TZ Subject: IDL (was Re: Object interfaces to Vsta) ---------- > From: Gavin Nicol <gtn@ebt.com> > Subject: Re: Object interfaces to Vsta [ ... ] > While I am very hesitant to recommend it, there is an IDL to C++ > complier in X11R6 (in Fresco). I prefer the IDL CFE from the OMG, but > getting a C compiler from that might be more work. Just in case > someone wants to *try* IDL :-) An alternative may be Xerox's ILU ( Inter language unification). The reference manual for version 1.6.4 includes pieces on use with: Common Lisp, C++, ANSI-C, Modula-3 and OMG-IDL - JonT From vandys@glare.cisco.com Thu Aug 18 05:52:00 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00433; Thu, 18 Aug 1994 05:51:59 -0700 Received: from ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA01975 for <vsta@cisco.com>; Thu, 18 Aug 1994 06:57:47 -0700 Received: from ebt-inc.ebt.com by ebt.com (4.1/SMI-4.1) id AA00604; Thu, 18 Aug 94 09:58:35 EDT Received: by ebt-inc.ebt.com (5.0/SMI-SVR4) id AA12633; Thu, 18 Aug 1994 09:58:35 +0500 Date: Thu, 18 Aug 1994 09:58:35 +0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <9408181358.AA12633@ebt-inc.ebt.com> To: t-jont@microsoft.com Cc: vsta@cisco.com In-Reply-To: <9408180816.AA28131@netmail2.microsoft.com> (t-jont@microsoft.com) Subject: Re: IDL (was Re: Object interfaces to Vsta) Content-Length: 129 >An alternative may be Xerox's ILU ( Inter language unification). is there a freely avilable (via net) source/doc set for this? From vandys@glare.cisco.com Thu Aug 18 23:53:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA00502; Thu, 18 Aug 1994 23:53:09 -0700 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA10704 for <vsta@cisco.com>; Fri, 19 Aug 1994 00:59:07 -0700 Received: by netmail2.microsoft.com (5.65/25-eef) id AA02472; Thu, 18 Aug 94 22:15:47 -0700 Message-Id: <9408190515.AA02472@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 18 Aug 94 22:15:47 PDT X-Msmail-Message-Id: 24059A41 X-Msmail-Conversation-Id: 24059A41 From: Jonathon Tidswell (MS Research Fellow) <t-jont@microsoft.com> To: gtn@ebt.com Date: Fri, 19 Aug 94 13:46:24 TZ Subject: ILU (IDL ...) Cc: vsta@cisco.com From The Modula-3 FAQ: [ Sorry for the attrocious indenting and wraparound. ] > 7.2. ILU, an object-oriented multi-lingual RPC-capable module system > > > The following was recently announced by Xerox PARC: > > Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU) > system is now available for general use. > WHAT'S ILU? > > ILU (pronounced eye'-loo) is a system that promotes software > interoperability via interfaces. Interfaces between what? Whatever > units of program structure are desired; we call them by the generic > term "modules". They could be parts of one process, all written in > the same language; they could be parts written in different languages, > sharing runtime support in one memory image; they could be parts > running in different memory images on different machines (on different > sides of the planet). A module could even be a distributed system > implemented by many programs on many machines. Calls across ILU > interfaces involve only as much mechanism as necessary for the calling > and called modules to interact. In particular, when the two modules > are in the same memory image and use the same data representations, > the calls are direct local procedure calls -- no stubs or other RPC > mechanisms are involved. > > ILU modules are known by their interfaces. A module interface is > specified once in ILU's object-oriented Interface Specification > Language (called, simply, ISL). For each of the particular > programming languages supported by ILU (currently Common Lisp, ANSI C, > C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works), > a version of the interface in that particular programming language can > be generated. The ILU kernel library provides services which may be > used by the language-specific interface to overcome intermodule > language or address space differences. > > Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF > DCE RPC, have strong notions of interfaces. ILU allows binding to > such services provided by such systems if their interfaces can be > described in ISL. ISL has been designed to facilitate such > description (currently, only for ONC RPC; Courier and DCE RPC are in > progress). The binding to such RPC services is done in such a way as > to be indistinguishable from binding to other ILU modules. In fact, > properly constructed ILU modules can appear as native RPC services, > and can be manipulated by non-ILU tools designed to work with those > RPC services. > > Similarly, the Object Management Group's (OMG) Common Object Request > Broker Architecture (CORBA) defines modules with explicit interfaces. > ILU allows modules that can be described with a safe subset of OMG > CORBA IDL to be used as ILU modules, as well, though the ILU object > model is not quite the same as the OMG CORBA object model. In fact, > people wishing to experiment with CORBA may find ILU a useful > experimental platform, as it does allow module specification with OMG > IDL, and does generate ANSI C support as specified in Draft 1.2 of the > OMG CORBA specification. As the OMG specification for a C++ mapping > is agreed upon, we intend to provide that mapping for our C++ support, > as well. > > Release 1.6.4 is intended as a beta release. Major efficiency > improvements and some usability improvements are planned for the next > release. It has been tested lightly on SunOS 4.1.3, Sun's Solaris > 2.3, and SGI's IRIX 5.2. It is designed to be highly portable, and a > port to the Macintosh has been done (but is not included in this > release). > > > GETTING THE RELEASE > > The release is only available via FTP from the PARC ftp server. > Perhaps the simplest way is to go through our World Wide Web home > page, > > > > <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html>ILU </A> > > > > It has links to everything else, and may help answer any questions you > might have. > > The release notes are available as an HTML document. > > > <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/announce.html> Announce </A> > > > > The full source code, including documentation, is available as a 3 MB > compressed tar file as > > > <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-1.6.4.tar.Z> Source </A> > > > > The 1.6.4 ILU manual is also available separately, either in > Postscript (231 KB) as > > > <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-manual-1.6.4.ps.Z> Documentation </A> > > > > or via World Wide Web at > > > <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_toc. html> Documentation </A> > > > > > CONTRIBUTORS > > Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson, Mike > Spreitzer, Mark Stefik, Farrell Wymore > > > From vandys@glare.cisco.com Fri Aug 19 07:55:30 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00556; Fri, 19 Aug 1994 07:55:29 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA15402; Fri, 19 Aug 1994 09:01:28 -0700 Message-Id: <199408191601.JAA15402@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yhcrana <dd002b@uhura.cc.rochester.edu> Cc: vsta@cisco.com Subject: Re: help with file name space In-Reply-To: Your message of "Fri, 19 Aug 1994 11:51:18 EDT." <199408191551.LAA02667@uhura.cc.rochester.edu> Date: Fri, 19 Aug 1994 09:01:27 -0700 From: Andrew Valencia <vandys@cisco.com> [yhcrana <dd002b@uhura.cc.rochester.edu> writes:] >although i ahve been watching this list for a few months, i only just got my >hands on a 486 to play with. one of my first acts was to download vsta. it >is running, sorta... Congratulations! On bad days, I feel like all VSTa *does* is "run, sorta...." :-) >if i log in as guest, i can see the file system. but if i log in as myself, >I see no file structure at all. the shell can't even find any executables. >what did i do wrong? Could you forward me your password file? If you've put "real" passwords into it, please XXX them out. >on a different note, I an confused by the "enviroment" field of the passwd >file. what is that? (is an answer to that an answer to my previous >question?) It specifies your path down into the /env server for getting environment variables. If your path was users/yhcrana, then when you did a: getenv("PRINTER"); the file /env/users/yhcrana/PRINTER would be accessed. If it didn't exist, next would be /env/users/PRINTER, and finally /env/PRINTER. Thus, creating a file /env/PRINTER sets a value global to the system. Creating /env/users/PRINTER creates a value shared by all "users". And so forth. So... the environment field says where a given account is "rooted" in the environment hierarchy, which defines which values you might inherit from various levels of the /env filesystem hierarchy. >if this helps, every time i boot, init fails to find root and slepps for 5. >i assume it does eventually find it (from looking at code and the fact that >the guest account works). This is probably OK. Some IDE drives take an unbelievable amount of time to reset, long enough that init takes its first shot at mounting a root filesystem before the drive is ready. If it gets it on the retry then you're fine. Andy From vandys@glare.cisco.com Fri Aug 19 07:45:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00552; Fri, 19 Aug 1994 07:45:26 -0700 Received: from uhura.cc.rochester.edu (dd002b@uhura.cc.rochester.edu [128.151.224.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA27837 for <vsta@cisco.com>; Fri, 19 Aug 1994 08:51:25 -0700 Received: (dd002b@localhost) by uhura.cc.rochester.edu (8.6.9/8.6.4) id LAA02667 for vsta@cisco.com; Fri, 19 Aug 1994 11:51:18 -0400 From: yhcrana <dd002b@uhura.cc.rochester.edu> Message-Id: <199408191551.LAA02667@uhura.cc.rochester.edu> Subject: help with file name space To: vsta@cisco.com Date: Fri, 19 Aug 1994 11:51:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 981 although i ahve been watching this list for a few months, i only just got my hands on a 486 to play with. one of my first acts was to download vsta. it is running, sorta... if i log in as guest, i can see the file system. but if i log in as myself, I see no file structure at all. the shell can't even find any executables. what did i do wrong? on a different note, I an confused by the "enviroment" field of the passwd file. what is that? (is an answer to that an answer to my previous question?) if this helps, every time i boot, init fails to find root and slepps for 5. i assume it does eventually find it (from looking at code and the fact that the guest account works). hhmmm derek ------------------------------------------------------------------------------ You should fear any bureaucratic entity that claims to work for you. derek denny-brown (yhcrana) dd002b@uhura.cc.rochester.edu chief engineer, WRUR derdb@cs.rochester.edu From vandys@glare.cisco.com Mon Aug 22 08:21:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01008; Mon, 22 Aug 1994 08:21:34 -0700 Received: from uhura.cc.rochester.edu (dd002b@uhura.cc.rochester.edu [128.151.224.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA16395 for <vsta@cisco.com>; Mon, 22 Aug 1994 09:27:49 -0700 Received: (dd002b@localhost) by uhura.cc.rochester.edu (8.6.9/8.6.4) id MAA06073 for vsta@cisco.com; Mon, 22 Aug 1994 12:27:42 -0400 From: yhcrana <dd002b@uhura.cc.rochester.edu> Message-Id: <199408221627.MAA06073@uhura.cc.rochester.edu> Subject: some problems i have.... To: vsta@cisco.com Date: Mon, 22 Aug 1994 12:27:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2436 hello! i have been watching here for soo long, and finnaly have a machine to play with. here are some things i have found to be problems.. 1) no example 'etc/groups' file was included (mine was empty) and i think that is the culprit of my next problem 2) if i log in with gid = 0 all is fine, but if gid = 1, i can not execute the profile (or is it rc?) and my PATH,TERM, atc are all empty. ANNOYING! 3) file redirection appears to not work propperly? is is supposed to? anyway, i tried 2 things which failed differently 'cat > ttyinput.txt' never lets me leave, ie. ignores ^d 'ls | less' just hangs, with (i think) less just waiting for the input.. 4) nothing recognizes teh arrow keys...yes i can use ^n,^p etc, but arrows are nice...(ie i'm lazy) i looked at the cons driver (i am assumin we now use cons2, as cons has no keyboard hooks...) and it appears to map 1-1, is there a way to catch esc codes. or (i jsut thought of this) does it map scan codes? that could me easier to map..(for a reson i plan to get into next) 5) the machine i am using now has a faulty esc key, making emacs frustrating as all hell. (try scrolling back when every other esc-v => v...) is it possible to map (alt) to (meta)? i am not sure how this info is dealt with in unix, but it would make a great deal of sense...IMHO 6) the HD has 2 partitions, how do i mount a 2nd partition? i can get dos to work, but how do i make it appear in my file space? 7) is it possible to make /vsta be root, rather than / ? (thus i don's have such a mess in my root...the boot partition is 200meg and has plenty of dos stuff also..) 8) what is the status of VstaFS and MADO? is VstaFS reliable? 9) is there a way for a process to tell a directory from a file...(at presetn you can 'ls file.txt' and get a text dump of the file. not bad unless you want to allow 'ls -l file.txt' to give info on only file.txt...) i think that is enough questions for now, though i have more at home, but i forgot them...so what i need is a portable computer to carry al this vital info at all times, so i can never escape. thanx and great work to all you who have helped out so far. derek ------------------------------------------------------------------------------ You should fear any bureaucratic entity that claims to work for you. derek denny-brown (yhcrana) dd002b@uhura.cc.rochester.edu chief engineer, WRUR derdb@cs.rochester.edu From vandys@glare.cisco.com Mon Aug 22 08:41:01 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01011; Mon, 22 Aug 1994 08:40:59 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA18384; Mon, 22 Aug 1994 09:47:15 -0700 Message-Id: <199408221647.JAA18384@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: yhcrana <dd002b@uhura.cc.rochester.edu> Cc: vsta@cisco.com Subject: Re: some problems i have.... In-Reply-To: Your message of "Mon, 22 Aug 1994 12:27:42 EDT." <199408221627.MAA06073@uhura.cc.rochester.edu> Date: Mon, 22 Aug 1994 09:47:14 -0700 From: Andrew Valencia <vandys@cisco.com> [yhcrana <dd002b@uhura.cc.rochester.edu> writes:] >1) no example 'etc/groups' file was included (mine was empty) and i think >that is the culprit of my next problem You mean /vsta/etc/group? From the tar file: rw-rw-rw- 0/0 34 Apr 13 14:00 1993 etc/group So it isn't zero-length in the distribution. >2) if i log in with gid = 0 all is fine, but if gid = 1, i can not execute >the profile (or is it rc?) and my PATH,TERM, atc are all empty. ANNOYING! Which account, which shell? Also, some things require sys.sys access to write, so not being in the group might cause you headaches. >3) file redirection appears to not work propperly? is is supposed to? >anyway, i tried 2 things which failed differently >'cat > ttyinput.txt' >never lets me leave, ie. ignores ^d Hmmm, is c_cc[VEOF] handling missing from the TTY code? Yup, looks that way to me. :-( See /vsta/libc/tty.c, feel free to add it, otherwise I'll do it sometime soon. >'ls | less' >just hangs, with (i think) less just waiting for the input.. I think this is because currently there's nothing mounted as /dev/tty, which is where less would like to open() and read from when stdin is a file. I was hoping MADO would have covered this, but for now it's a pain. As a workaround, you can mount your current TTY there as an alias, which might satisfy less. >4) nothing recognizes teh arrow keys...yes i can use ^n,^p etc, but arrows >are nice...(ie i'm lazy) i looked at the cons driver (i am assumin we now >use cons2, as cons has no keyboard hooks...) and it appears to map 1-1, is >there a way to catch esc codes. or (i jsut thought of this) does it map scan >codes? that could me easier to map..(for a reson i plan to get into next) Which version do you have? It's all a blur to me. srv/mach/cons2 certainly has escape key mapping, at least in my version. See isr.c. If you don't have it, it might be one of those new things for v1.4. >5) the machine i am using now has a faulty esc key, making emacs frustrating >as all hell. (try scrolling back when every other esc-v => v...) is it >possible to map (alt) to (meta)? i am not sure how this info is dealt with >in unix, but it would make a great deal of sense...IMHO I think we don't want to do this in the keyboard driver, but rather in the windowing system. Of course, for now, you can hack it in isr.c! >6) the HD has 2 partitions, how do i mount a 2nd partition? i can get dos >to work, but how do i make it appear in my file space? Mount disk/wd in, say, /dev/wd. Now chdir to /dev/wd and ls. You should see all the partitions the driver found. See the mailing list archives for how to fire up a filesystem server. >7) is it possible to make /vsta be root, rather than / ? (thus i don's have >such a mess in my root...the boot partition is 200meg and has plenty of dos >stuff also..) Well, the root path is coded in a couple places. It used to be /vsta, but it just made it a pain to access your VSTa stuff, because it all lives in the vsta subdir, so everything was /vsta/vsta/bin/.... >8) what is the status of VstaFS and MADO? is VstaFS reliable? Of course it is! :-) Seriously, it works well enough for basic stuff, but it needs some serious tuning. Also, the fsck needs to know more about repairing damage, especially lost blocks. >9) is there a way for a process to tell a directory from a file...(at >presetn you can 'ls file.txt' and get a text dump of the file. not bad >unless you want to allow 'ls -l file.txt' to give info on only file.txt...) Yes, that needs fixing. "ls" just needs to check the "type=" field from the FS_STAT. It also needs to sort its output. Additionally, Dave ported GNU ls. But, of course, it doesn't understand the extended protection information. On another note, I have all of KA9Q compiling, and am hacking my way through the undefined symbols. My plan for distributed source access is to export a filesystem under VSTa, and let folks use RCS. So... the distributed aspects of VSTa are imminent. Regards, Andy From vandys@glare.cisco.com Tue Aug 23 00:05:28 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA01110; Tue, 23 Aug 1994 00:05:27 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA23255; Tue, 23 Aug 1994 01:11:44 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa19313; 23 Aug 94 8:59 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0qcqid-00039pC; Tue, 23 Aug 94 08:56 BST Message-Id: <m0qcqid-00039pC@humbug.demon.co.uk> From: Dave Hudson <dave@humbug.demon.co.uk> Subject: Re: some problems i have.... To: Andrew Valencia <vandys@cisco.com> Date: Tue, 23 Aug 1994 08:56:30 +0100 (BST) Cc: VSTa mailing list <vsta@cisco.com> In-Reply-To: <199408221647.JAA18384@glare.cisco.com> from "Andrew Valencia" at Aug 22, 94 09:47:14 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3730 Hi All, > >'ls | less' > >just hangs, with (i think) less just waiting for the input.. > > I think this is because currently there's nothing mounted as /dev/tty, which > is where less would like to open() and read from when stdin is a file. I > was hoping MADO would have covered this, but for now it's a pain. As a > workaround, you can mount your current TTY there as an alias, which might > satisfy less. There's also bugs in the 1.3.1 code for less and the pipe server - Andy's had the fixes for 1.4. If you're interested I can mail them to you (the problems were in keyboard handling for less and messaging code for pipe). > >5) the machine i am using now has a faulty esc key, making emacs frustrating > >as all hell. (try scrolling back when every other esc-v => v...) is it > >possible to map (alt) to (meta)? i am not sure how this info is dealt with > >in unix, but it would make a great deal of sense...IMHO > > I think we don't want to do this in the keyboard driver, but rather in the > windowing system. Of course, for now, you can hack it in isr.c! I must admit that having a generic keyboard remapping facility would be nice - it's on my list of "good ideas" but I don't have the time at the moment, and I managed to get my hands on a US 101 key keyboard so that helped! If it's done as a library then adding it to cons and any windowing system will be easy. > >7) is it possible to make /vsta be root, rather than / ? (thus i don's have > >such a mess in my root...the boot partition is 200meg and has plenty of dos > >stuff also..) > > Well, the root path is coded in a couple places. It used to be /vsta, but > it just made it a pain to access your VSTa stuff, because it all lives in > the vsta subdir, so everything was /vsta/vsta/bin/.... Andy, would a variation on what you mentioned a while back work? Create a subdir called /vsta/vsta on the DOS drive and unpack everything into that instead of /vsta, and then instead of mounting fs/root as /, mount fs/root:vsta as / instead. I just tried: mount fs/root:windows /w and I now magically have my windows directory mounted at /w This wouldn't remove the need for a "vsta" path, but it would clear the remaining dos code out of the root directory. It'd be pretty simple to then mount the whole partition as say /dos. > >8) what is the status of VstaFS and MADO? is VstaFS reliable? > I'm not quite sure how far Gavin's got with MADO, but I brought up some generic VGA display code yesterday. The code's based on the XFree86 video drivers to make bringing up SVGA support easier. Hopefully by the end of the week we'll have a video library, with BitBlt in the next few weeks. > >9) is there a way for a process to tell a directory from a file...(at > >presetn you can 'ls file.txt' and get a text dump of the file. not bad > >unless you want to allow 'ls -l file.txt' to give info on only file.txt...) > > Yes, that needs fixing. "ls" just needs to check the "type=" field from the > FS_STAT. It also needs to sort its output. > > Additionally, Dave ported GNU ls. But, of course, it doesn't understand the > extended protection information. Ah, there are two versions of GNU ls in the code I ported - one's a pretty faithful Unix hack-alike (gls), but the other one (vls) handles all of the VSTa subtleties as well - even does pretty formatting too :-) > On another note, I have all of KA9Q compiling, and am hacking my way through > the undefined symbols. My plan for distributed source access is to export a > filesystem under VSTa, and let folks use RCS. So... the distributed aspects > of VSTa are imminent. Now there's a piece of code to make me want to get some PCMCIA modem code written :-) Regards, Dave From vandys@glare.cisco.com Tue Aug 23 08:35:00 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01172; Tue, 23 Aug 1994 08:34:58 -0700 Received: from uhura.cc.rochester.edu (dd002b@uhura.cc.rochester.edu [128.151.224.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA14549 for <vsta@cisco.com>; Tue, 23 Aug 1994 09:41:19 -0700 Received: (dd002b@localhost) by uhura.cc.rochester.edu (8.6.9/8.6.4) id MAA07557; Tue, 23 Aug 1994 12:40:59 -0400 From: yhcrana <dd002b@uhura.cc.rochester.edu> Message-Id: <199408231640.MAA07557@uhura.cc.rochester.edu> Subject: 1.4, mounting, and more To: dave@humbug.demon.co.uk (Dave Hudson) Date: Tue, 23 Aug 1994 12:40:59 -0400 (EDT) Cc: vsta@cisco.com In-Reply-To: <m0qcqid-00039pC@humbug.demon.co.uk> from "Dave Hudson" at Aug 23, 94 08:56:30 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3499 > > There's also bugs in the 1.3.1 code for less and the pipe server - Andy's > had the fixes for 1.4. If you're interested I can mail them to you (the > problems were in keyboard handling for less and messaging code for pipe). > when should 1.4 be released? > > I must admit that having a generic keyboard remapping facility would be nice > - it's on my list of "good ideas" but I don't have the time at the moment, > and I managed to get my hands on a US 101 key keyboard so that helped! > > If it's done as a library then adding it to cons and any windowing system > will be easy. > i will look at it, but do not expect to get to much for a while, i am about to move... > > >7) is it possible to make /vsta be root, rather than / ? (thus i don's have > > >such a mess in my root...the boot partition is 200meg and has plenty of dos > > >stuff also..) > > > > Create a subdir called /vsta/vsta on the DOS drive and unpack everything > into that instead of /vsta, and then instead of mounting fs/root as /, mount > fs/root:vsta as / instead. > > I just tried: > > mount fs/root:windows /w > > and I now magically have my windows directory mounted at /w > > This wouldn't remove the need for a "vsta" path, but it would clear the > remaining dos code out of the root directory. It'd be pretty simple to then > mount the whole partition as say /dos. > this is what i was looking for... but i dont seem to have a "mount" command, and when i tried to create one last night, it killed 'root' (the process) and i was dumped into the debugger > > >8) what is the status of VstaFS and MADO? is VstaFS reliable? > > > > I'm not quite sure how far Gavin's got with MADO, but I brought up some > generic VGA display code yesterday. The code's based on the XFree86 video > drivers to make bringing up SVGA support easier. Hopefully by the end of > the week we'll have a video library, with BitBlt in the next few weeks. > i am looking at buying a system (the one i use now is on loan), and would like to get a video accelerator (i wasnt to play with some 3-d GUI stuff) anyone have experience with taking advatage of various accelerators...what does xfree (or x for linux..etc...but i don't think they are different?) know about? (so i can steal their code) > > Additionally, Dave ported GNU ls. But, of course, it doesn't understand the > > extended protection information. > > Ah, there are two versions of GNU ls in the code I ported - one's a pretty > faithful Unix hack-alike (gls), but the other one (vls) handles all of the > VSTa subtleties as well - even does pretty formatting too :-) > pretty please tell me where i can get these... > > On another note, I have all of KA9Q compiling, and am hacking my way through > > the undefined symbols. My plan for distributed source access is to export a > > filesystem under VSTa, and let folks use RCS. So... the distributed aspects > > of VSTa are imminent. > > Now there's a piece of code to make me want to get some PCMCIA modem code > written :-) > what is KA9Q? how many people have gotten vsta to work on a portable.... (i am trying to decide on buying a portable, so the machine can follow me, or a fast desktop... thanx derek ------------------------------------------------------------------------------ You should fear any bureaucratic entity that claims to work for you. derek denny-brown (yhcrana) dd002b@uhura.cc.rochester.edu chief engineer, WRUR derdb@cs.rochester.edu From vandys@glare.cisco.com Thu Aug 25 06:34:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA01595; Thu, 25 Aug 1994 06:34:02 -0700 Received: from uahcs2.cs.uah.edu (uahcs2.cs.uah.edu [146.229.2.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA01267 for <vsta@cisco.com>; Thu, 25 Aug 1994 07:40:36 -0700 Received: (from mmceniry@localhost) by uahcs2.cs.uah.edu (8.6.9/8.6.9) id JAA06264 for vsta@cisco.com; Thu, 25 Aug 1994 09:40:45 -0500 From: Michael McEniry <mmceniry@uahcs2.cs.uah.edu> Message-Id: <199408251440.JAA06264@uahcs2.cs.uah.edu> Subject: SPARC port To: vsta@cisco.com Date: Thu, 25 Aug 94 9:40:44 CDT X-Mailer: ELM [version 2.4dev PL73] Content-Type: text Content-Length: 355 What's the status on the port to SPARC platforms? I might be getting a (cheap/used/old *sigh*) IPC in the very near future and would like to play--er, do useful and productive things with VSTa on it. (Besides, it'd make a helluva Senior Project, eh?) Michael McEniry Research Assistant Computer Science, Univ. Ala. in Huntsville mmceniry@cs.uah.edu