From vandys@cisco.com Mon Aug 16 15:08:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13716; Mon, 16 Aug 93 15:08:31 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07704; Mon, 16 Aug 93 15:11:22 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA28977(netkeeper.sj.nec.com ); Mon, 16 Aug 93 15:11:21 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24398(archimedes.inoc.sj.nec.com ); Mon, 16 Aug 93 15:11:19 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA14599 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 15:04:07 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00491); Mon, 16 Aug 93 15:02:38 -0700 Received: from localhost by glare.cisco.com with SMTP id AA19021 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 15:01:12 -0700 Message-Id: <199308162201.AA19021@glare.cisco.com> To: vsta@cisco.com Subject: VSTa mailing list Date: Mon, 16 Aug 1993 15:01:12 -0700 From: Andrew Valencia Status: OR Welcome, The VSTa mailing list is hopefully open. To request address changes, make administrative inquiries, etc. please mail to vsta-request@cisco.com. To send to the members of the list, use vsta@cisco.com. I will let this dribble out. When it appears that it works "for real", I will send along the first patch you'll need to build VSTa from the latest distribution. Regards, Andy Valencia vandys@cisco.com From vandys@cisco.com Mon Aug 16 16:45:40 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13931; Mon, 16 Aug 93 16:45:38 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07869; Mon, 16 Aug 93 16:48:30 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29970(netkeeper.sj.nec.com ); Mon, 16 Aug 93 16:48:28 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24678(archimedes.inoc.sj.nec.com ); Mon, 16 Aug 93 16:48:26 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA21679 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 16:41:56 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00551); Mon, 16 Aug 93 16:40:45 -0700 Received: from localhost by glare.cisco.com with SMTP id AA23661 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 16:38:45 -0700 Message-Id: <199308162338.AA23661@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: VSTa mailing list In-Reply-To: Your message of "Tue, 17 Aug 1993 08:29:06 +0200." <9308162329.AA03826@silk1.nsis.cl.nec.co.jp> Date: Mon, 16 Aug 1993 16:38:45 -0700 From: Andrew Valencia Status: OR >1) Did you see/find the mount bug I mentioned? Nope... sorry. :-( I'm playing with some RCS version management stuff so I can use symbolic names. I also have some of the buffering code for my contiguous filesystem. I'll have a look-see tonight, perhaps. >2) From looking at the sources, it looks like VSTa supports "mount > overs" like plan9. Is that correct? Yes, although I didn't provide the full set of before, after, overlay. You can get overlay by just umount()'ing first. I think my mount() provides only before semantics. >3) What kind of "look" would you prefer the window manager to have? If > you mention an X window manager, I'll know the look. uwm. :-) >4) Are you still working on real-time? On a slow machine (like mine!), > bitblt stalls noticeably during a switch. Real-time won't soften the blow of having the CPU stolen from you; it merely provides some guarantees concerning when it will be stolen. If bitblt takes a LOT of cpu, you probably don't want it to be real-time. Or do I mis- understand the question? Andy From vandys@cisco.com Mon Aug 16 16:54:15 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13951; Mon, 16 Aug 93 16:54:14 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07880; Mon, 16 Aug 93 16:57:05 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00188(netkeeper.sj.nec.com ); Mon, 16 Aug 93 16:57:04 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24707(archimedes.inoc.sj.nec.com ); Mon, 16 Aug 93 16:57:01 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA22044 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 16:50:30 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00559); Mon, 16 Aug 93 16:49:06 -0700 Received: from localhost by glare.cisco.com with SMTP id AA24022 (5.67a/IDA-1.5 for ); Mon, 16 Aug 1993 16:47:41 -0700 Message-Id: <199308162347.AA24022@glare.cisco.com> To: vsta@cisco.com Subject: Patch for dbsym Date: Mon, 16 Aug 1993 16:47:41 -0700 From: Andrew Valencia Status: OR For those of you who have hit a compile problem with dbsym, here's the patch which allows dbsym to build from the djgpp (because dbsym runs under DOS/djgpp) while still using the needed header from dbg/. patch appears to come with djgpp, so I'm assuming you folks will have no trouble applying this: *** c:/tmp/T0AA.AAA Fri Aug 13 09:23:00 1993 --- make/make.tai Fri Aug 13 09:13:46 1993 *************** *** 1,12 **** vsta: $(OBJS) dbsym $(LD) -e _start -o vsta @objs $(LIBS) go32 dbsym vsta dbsym: ../dbg/dbsym.c ! $(CC) $(CFLAGS) -o dbsym ../dbg/dbsym.c clean: rm -f genassym assym.h locore.s *.o clobber: clean rm -f vsta --- 1,12 ---- vsta: $(OBJS) dbsym $(LD) -e _start -o vsta @objs $(LIBS) go32 dbsym vsta dbsym: ../dbg/dbsym.c ! $(CC) $(DEFS) -o dbsym ../dbg/dbsym.c clean: rm -f genassym assym.h locore.s *.o clobber: clean rm -f vsta *** c:/tmp/T0AA.AAA Fri Aug 13 09:23:00 1993 --- dbg/dbsym.c Fri Aug 13 09:11:38 1993 *************** *** 3,15 **** * Hacked for VSTa by Andy Valencia (jtk@netcom.com). This file is * still in the public domain. */ #ifdef KDB #include #include ! #include extern void *malloc(); #define FILE_OFFSET(vadr) \ (vadr - N_DATADDR(hdr) + N_DATOFF(hdr)) --- 3,15 ---- * Hacked for VSTa by Andy Valencia (jtk@netcom.com). This file is * still in the public domain. */ #ifdef KDB #include #include ! #include "../dbg/dbg.h" extern void *malloc(); #define FILE_OFFSET(vadr) \ (vadr - N_DATADDR(hdr) + N_DATOFF(hdr)) *** c:/tmp/T0AA.AAA Fri Aug 13 09:23:00 1993 --- dbg/dbg.h Fri Aug 13 09:11:20 1993 *************** *** 1,14 **** #ifndef _NAMES_H #define _NAMES_H /* * names.h * Values shared between kernel and utiliies */ - #include - #define DBG_NAMESZ (20*1024) /* Buffer for namelist data */ /* * Type of each entry in dbg_names[] */ #define DBG_END (1) --- 1,12 ---- *************** *** 16,29 **** #define DBG_DATA (3) /* * Structure superimposed onto the stream of bytes in dbg_names[] */ struct sym { ! uchar s_type; /* Must be first--see dbg_names[] */ ! ulong s_val; char s_name[1]; }; /* * How to advance to end of current struct sym */ --- 14,27 ---- #define DBG_DATA (3) /* * Structure superimposed onto the stream of bytes in dbg_names[] */ struct sym { ! unsigned char s_type; /* Must be first--see dbg_names[] */ ! unsigned long s_val; char s_name[1]; }; /* * How to advance to end of current struct sym */ From vandys@cisco.com Tue Aug 17 15:23:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07800; Tue, 17 Aug 93 15:23:03 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08278; Tue, 17 Aug 93 15:26:00 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05461(netkeeper.sj.nec.com ); Tue, 17 Aug 93 15:25:59 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26944(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 15:25:57 -0700 Received: from localhost by glare.cisco.com with SMTP id AA09631 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 15:22:12 -0700 Message-Id: <199308172222.AA09631@glare.cisco.com> To: abbie@dcsd.sj.nec.com (Abbie Matthews x2959) Subject: Re: VSTa sources In-Reply-To: Your message of "Tue, 17 Aug 1993 15:11:05 PDT." <9308172211.AA01965@chicago.dcsd.sj.nec.com.dcsd.sj.nec.com> Date: Tue, 17 Aug 1993 15:22:12 -0700 From: Andrew Valencia Status: OR >I am now on your mailing list ... but do not know where to get the >sources for VSTa. I would also appreciate info on which compiler to use >etc. *********** FTP SITE ************ You can get it from ftp.cisco.com:vandys/vsta, start with the readme. I recommend the latest djgpp you can find (mine's 2.4.4 based, I believe). You can get it from any of a number of MSDOS archive sites; I use barnacle.erc.clarkson.edu:/pub/msdos/djgpp. Andy From vandys@cisco.com Tue Aug 17 17:18:58 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08514; Tue, 17 Aug 93 17:18:56 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08349; Tue, 17 Aug 93 17:21:53 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07599(netkeeper.sj.nec.com ); Tue, 17 Aug 93 17:21:52 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27216(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 17:21:50 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA17715 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 17:15:42 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00263); Tue, 17 Aug 93 17:14:46 -0700 Received: from localhost by glare.cisco.com with SMTP id AA11777 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 17:13:26 -0700 Message-Id: <199308180013.AA11777@glare.cisco.com> To: eric@sunbeam.ca.tekelec.com (Eric Peterson) Cc: vsta@cisco.com Subject: Re: Bootstrapping vsta In-Reply-To: Your message of "Tue, 17 Aug 1993 17:02:36 PDT." <9308180002.AA24675@tweety.ca.tekelec.com> Date: Tue, 17 Aug 1993 17:13:26 -0700 From: Andrew Valencia Status: OR > I've finally gotten my disk cleaned up enough to get vsta loaded on the > system - now for bootstrapping. From the "roadmap.txt" I assumed that > a bootable kernel existed on the root.t file, but I can't find it. Now > looking things over, I have figured out that things (like some drivers) > need to be configured per system, so I guess I need to build a kernel. Nope. No drivers in the kernel. You *do* have to configure parameters for the arguments to the programs which will be running when the system first starts. But to save space, I don't distribute a kernel binary, so you have to build it anyway. :-) The part about configuring the parameters should lead you to the file boot/boot.lst, which (sort of) documents itself. > Ok, no problem... I seem to have a gcc compiler but it's a vsta, not > a DOS version, uh oh - back to my problem with bootstrapping. Is the > "DJ Delorie" compiler the DOS gcc that I need to get things built? I > couldn't find binaries on the gcc.tz tar file, is this where it should > be built from, or is there another source for this compiler...? Yes, the gcc supplied is for native VSTa compiling. To build from DOS you need to get the djgpp compiler package ("DJ Delorie"). My favorite place to pull it is barnacle.erc.clarkson.edu from /pub/msdos/djgpp. VSTa has run with older versions, I'm hearing some rumblings about middle versions though I haven't seen it myself, and the latest version works just fine. Clarkson tends to have the latest, so you should be OK. Install djgpp, then go back to bootstrapping. I will ponder clarifying the native vs. host issue when I go back and edit the roadmap for the next release. Regards... Andy From vandys@cisco.com Tue Aug 17 21:12:14 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10750; Tue, 17 Aug 93 21:12:12 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08616; Tue, 17 Aug 93 21:15:10 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09735(netkeeper.sj.nec.com ); Tue, 17 Aug 93 21:15:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27538(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 21:15:08 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA03805 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 21:07:29 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00520); Tue, 17 Aug 93 21:06:26 -0700 Received: from localhost by glare.cisco.com with SMTP id AA03839 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 21:05:13 -0700 Message-Id: <199308180405.AA03839@glare.cisco.com> To: Simmule Turner Cc: vsta@cisco.com Subject: Re: Mailing List In-Reply-To: Your message of "Tue, 17 Aug 1993 23:56:33 EDT." Date: Tue, 17 Aug 1993 21:05:12 -0700 From: Andrew Valencia Status: OR Ah. Got it. I bet they're overstepping C and that's why the latest gcc backs away from this. Anyway, my C library calls it "volatile void", which was what it took to make gcc happy. I see now that I should make the kernel function have a different name (because he *isn't* the exit system call, although he implements it). I'll fiddle this for the next release. Thanks for the report. Andy > > >On Mon, 16 Aug 1993, Andrew Valencia wrote: > >> >The fatal errors were in files mach/syscall.c and kern/proc.c. They >> >contain usages and redefinitions of exit. >> >> Exactly which kinds of errors? I hit this with my 2.4.4 GCC, but fixed >> it and thus am curious what variation of the problem exists on an earlier >> GCC. > >The errors are because exit() in VSTa is an integer valued function, not >a voided function. Here is the error text: > >../mach/syscall.c:22: conflicting types for `exit' >:0: previous declaration of `exit' > >../kern/proc.c:535: conflicting types for `exit' >:0: previous declaration of `exit' > >I'm going to switch in a day or so to 2.4.4 release. > >simmy From vandys@cisco.com Tue Aug 17 21:26:41 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12164; Tue, 17 Aug 93 21:26:39 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08620; Tue, 17 Aug 93 21:29:38 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09805(netkeeper.sj.nec.com ); Tue, 17 Aug 93 21:29:37 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27550(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 21:29:35 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04445 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 21:22:36 -0700 Received: from barley.cisco.com by amri.cisco.com (AA00529); Tue, 17 Aug 93 21:20:53 -0700 Received: by barley.cisco.com id AA07732 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Tue, 17 Aug 1993 21:19:41 -0700 Date: Tue, 17 Aug 1993 21:19:41 -0700 From: Andrew Valencia Message-Id: <199308180419.AA07732@barley.cisco.com> To: vsta@cisco.com Subject: Patch pat.3 Status: OR This patch fixes a conformance problem with the type of strlen(). It should be size_t. GCC has built-ins and built-in knowledge of such things, so it complains. This should fix that. *** c:/tmp/T0AA.AAA Tue Aug 17 21:14:36 1993 --- include/string.h Mon Aug 16 08:29:14 1993 *************** *** 10,18 **** * Prototypes */ extern char *strcpy(char *, const char *), *strncpy(char *, const char *, int); extern char *strcat(char *, const char *), *strncat(char *, const char *, int); ! extern int strlen(const char *), strcmp(const char *, const char *), strncmp(const char *, const char *, int); extern void *memcpy(void *, const void *, size_t); extern char *strchr(const char *, int), *strrchr(const char *, int); extern char *index(const char *, int), *rindex(const char *, int); --- 10,19 ---- * Prototypes */ extern char *strcpy(char *, const char *), *strncpy(char *, const char *, int); extern char *strcat(char *, const char *), *strncat(char *, const char *, int); ! extern size_t strlen(const char *); ! extern int strcmp(const char *, const char *), strncmp(const char *, const char *, int); extern void *memcpy(void *, const void *, size_t); extern char *strchr(const char *, int), *strrchr(const char *, int); extern char *index(const char *, int), *rindex(const char *, int); *** c:/tmp/T0AA.AAA Tue Aug 17 21:14:36 1993 --- libc/string.c Mon Aug 16 08:29:38 1993 *************** *** 40,50 **** /* * strlen() * Length of string */ strlen(const char *p) { ! int x = 0; while (*p++) ++x; return(x); --- 40,51 ---- /* * strlen() * Length of string */ + size_t strlen(const char *p) { ! size_t x = 0; while (*p++) ++x; return(x); From vandys@cisco.com Tue Aug 17 21:26:40 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12163; Tue, 17 Aug 93 21:26:39 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08619; Tue, 17 Aug 93 21:29:37 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09801(netkeeper.sj.nec.com ); Tue, 17 Aug 93 21:29:36 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27548(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 21:29:33 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04441 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 21:22:32 -0700 Received: from barley.cisco.com by amri.cisco.com (AA00527); Tue, 17 Aug 93 21:20:52 -0700 Received: by barley.cisco.com id AA07730 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Tue, 17 Aug 1993 21:19:41 -0700 Date: Tue, 17 Aug 1993 21:19:41 -0700 From: Andrew Valencia Message-Id: <199308180419.AA07730@barley.cisco.com> To: vsta@cisco.com Subject: Patch pat.2 Status: OR This patch fixes a problem with readdir() not correctly creating pseudo-directories for mount paths which include our path. For instance, if you have a mount path of the console driver to /dev/cons, when you chdir to /dev and list files, you should get "cons". This worked for chdir'ing to / and seeing "dev", but not for the former. This patch fixes that. *** c:/tmp/T0AA.AAA Mon Aug 16 18:20:04 1993 --- libc/dir.c Mon Aug 16 18:14:02 1993 *************** *** 21,52 **** --- 21,76 ---- DIR * opendir(char *path) { DIR *d; char *p; extern char *__cwd; /* + * Bogus. + */ + if (!path || !path[0]) { + return(0); + } + + /* * Get private, writable copy of path. Flatten to absolute. */ if (path[0] == '/') { p = strdup(path); } else { p = malloc(strlen(path) + strlen(__cwd) + 1); if (p ) { sprintf(p, "%s/%s", __cwd, path); } } + if (p == 0) { return(0); } if (__dotdot(p)) { free(p); return(0); + } + + /* + * All directory paths should end in "/". Add one if + * it isn't present. + */ + if (p && (p[strlen(p)-1] != '/')) { + char *q; + + q = realloc(p, strlen(p)+2); + if (!q) { + free(p); + return(0); + } + p = q; + strcat(p, "/"); } /* * Get a DIR */ d = malloc(sizeof(DIR)); if (d == 0) { free(p); From vandys@cisco.com Wed Aug 18 08:24:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17934; Wed, 18 Aug 93 08:24:14 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08834; Wed, 18 Aug 93 08:27:14 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15662(netkeeper.sj.nec.com ); Wed, 18 Aug 93 08:27:13 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28269(archimedes.inoc.sj.nec.com ); Wed, 18 Aug 93 08:27:11 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA21440 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 08:21:16 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00876); Wed, 18 Aug 93 08:11:49 -0700 Received: from localhost by glare.cisco.com with SMTP id AA13095 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 08:10:43 -0700 Message-Id: <199308181510.AA13095@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Shared libraries? In-Reply-To: Your message of "Wed, 18 Aug 1993 16:53:38 +0200." <9308180753.AA20221@silk1.nsis.cl.nec.co.jp> Date: Wed, 18 Aug 1993 08:10:42 -0700 From: Andrew Valencia Status: OR >Note that shared libraries really need to be done properly, if they're >to be done at all. Some of the Linuxers here could tell long tales >of woe with the early versions on Linux shared libraries... and can >probably tell how to avoid the mistakes. There are two levels of answer to this question. The first has to do with the "kernel" functionality which happens to be present in the C library due to the design of a microkernel. The second has to do with user code which would be nice to share. For the former ("kernel") code, I would rather use a simpler mechanism that Sun-style shared libraries. Sun-style (from my research; somebody correct me if I'm out of date) generates slower code and burns one of those valuable 386 registers. For "kernel" user-mode code, I would rather use a technique more like the original Linux shared libraries. Perhaps not even call it a shared library; we could refer to the ring 0 "kernel" as k-code, and ring 3 "kernel" as u-code. u-code would be attached at a fixed address at bootup with your usual leading jump table to get to the various functions. When you boot a kernel you run your programs with the loaded version of both k-code and u-code. This then leaves all the rest of the libraries and their functions. If somebody wants to hack up the libraries, write an ld.so, and all that good stuff, then I think that's fine. Just make sure the -static still works so we can generate non-shared versions as needed! Most studies suggest that the savings in memory is not very great. The big savings is in disk space and in convenience in having your app dynamically run against the latest (and presumably best) version of the various library routines. Andy From mackinla@cs.curtin.edu.au Wed Aug 18 09:30:00 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18275; Wed, 18 Aug 93 09:29:58 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08858; Wed, 18 Aug 93 09:32:54 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17655(netkeeper.sj.nec.com ); Wed, 18 Aug 93 09:32:50 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28447(archimedes.inoc.sj.nec.com ); Wed, 18 Aug 93 09:32:48 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA25502 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 09:25:56 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00117); Wed, 18 Aug 93 09:25:10 -0700 Received: from marsh.cs.curtin.edu.au by dirt.cisco.com with SMTP id AA25251 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 09:24:00 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA13135 (5.67a/IDA-1.5); Thu, 19 Aug 1993 00:24:33 +0800 Received: by lillee.cs.curtin.edu.au id AA21843 (5.67a/IDA-1.4.4); Thu, 19 Aug 1993 00:24:32 +0800 From: Pat Mackinlay Message-Id: <199308181624.AA21843@lillee.cs.curtin.edu.au> Subject: Re: Shared libraries? To: vandys@cisco.com (Andrew Valencia) Date: Thu, 19 Aug 1993 00:24:32 +0800 (WST) Cc: vsta@cisco.com In-Reply-To: <199308181510.AA13095@glare.cisco.com> from "Andrew Valencia" at Aug 18, 93 08:10:42 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1536 Status: OR > "kernel" as k-code, and ring 3 "kernel" as u-code. u-code would be > attached at a fixed address at bootup with your usual leading jump table > to get to the various functions. When you boot a kernel you run your > programs with the loaded version of both k-code and u-code. I'm not sure I have this right. Basically, what everyone wants to share (I think) is libc. If I understand correctly, this would be an example of your u-code? Doing this with the "old Linux" method would leave us with a jump table for libc functions in memory, with appropriate library loading code in crt0.o. Do I have this right? Is this so hard to do? > Most studies suggest that the savings in memory is not very great. > The big savings is in disk space and in convenience in having your Yes, you're right here. You do save a lot of disk space, although the memory savings are pretty good under Linux also (eg: I can run X and lots of small clients and all the usual Unix/networking daemons without excessive swapping in 5M of memory. I _really_ don't think it'd be possible if each binary included their own copies of the various X and libc functions.) Anyhow, in the short term, my goal is to get out of MS-DOS. Andy, you mentioned "dmake" before. Where can I get source for that? Anyone else know of a decent free make with source (and don't say GNU make )? Pat -- "There's only one thing left to do Mama, I got to ding a ding dang my dang a long ling long" (Jesus Built My Hotrod -- Ministry) GCS d* -p+ c++ l++ m--- s+/- !g w- t- r From vandys@cisco.com Wed Aug 18 10:24:09 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19166; Wed, 18 Aug 93 10:24:06 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08884; Wed, 18 Aug 93 10:27:06 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08337(netkeeper.sj.nec.com ); Wed, 18 Aug 93 10:27:04 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28639(archimedes.inoc.sj.nec.com ); Wed, 18 Aug 93 10:27:02 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA29264 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 10:20:39 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00065); Wed, 18 Aug 93 10:20:43 -0700 Received: from localhost by glare.cisco.com with SMTP id AA18638 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 10:09:07 -0700 Message-Id: <199308181709.AA18638@glare.cisco.com> To: Pat Mackinlay Cc: vsta@cisco.com Subject: Re: Shared libraries? In-Reply-To: Your message of "Thu, 19 Aug 1993 00:24:32 +0800." <199308181624.AA21843@lillee.cs.curtin.edu.au> Date: Wed, 18 Aug 1993 10:09:07 -0700 From: Andrew Valencia Status: OR >I'm not sure I have this right. Basically, what everyone wants to share >(I think) is libc. If I understand correctly, this would be an example of >your u-code? Doing this with the "old Linux" method would leave us with >a jump table for libc functions in memory, with appropriate library loading >code in crt0.o. libc contains two distinct classes of routines, with a grey area. There are functions which are definitely not system code (strcpy, printf), there are functions which are definitely system code (opendir, readdir, open) and there are fuzzy areas (read/write, stat, malloc). I guess my first pass would be to plunk the whole current C library into a fixed area, put a jump table at front, and generate a stub C library for apps to link against which used the jump table. This has the advantage of working even when there isn't a filesystem. Even standalone mode can dynamically get access to the appropriate u-code as well as k-code. It has the disadvantages which the Linux folks have found. How do you override a function? If you override it, will the other library code honor your override, or will it use the old definition? Can you set yourself up to run against an older version of library? Thus my desire to draw a distinction between "true" k-code and the rest of the stuff in the C library. In an ideal world, you partition the two and put only k-code into this fixed library. Then most of the shared library questions make no more sense than asking if you can run against an older version of the kernel. In practice, there is fuzziness, but I think we should try this approach. Of course, if someone's ready to work on this, then they get to think this through more thoroughly, and most likely come up with a different, better answer. >Anyhow, in the short term, my goal is to get out of MS-DOS. Andy, you >mentioned "dmake" before. Where can I get source for that? Anyone else >know of a decent free make with source (and don't say GNU make )? Archie shows it (actually, it shows other stuff, but I hunted it down): plg.uwaterloo.ca:pub/dmake Andy From vandys@cisco.com Wed Aug 18 13:05:07 1993 Return-Path: Received: from texas.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20087; Wed, 18 Aug 93 13:04:54 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by texas.dcsd.sj.nec.com (4.0/SMI-4.1) id AA11170; Wed, 18 Aug 93 13:07:31 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10045(netkeeper.sj.nec.com ); Wed, 18 Aug 93 13:06:07 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28998(archimedes.inoc.sj.nec.com ); Wed, 18 Aug 93 13:06:05 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA09062 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 13:00:48 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00156); Wed, 18 Aug 93 13:01:21 -0700 Received: from localhost by glare.cisco.com with SMTP id AA28890 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 12:59:25 -0700 Message-Id: <199308181959.AA28890@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Help!! Unable to extract VSTa sources In-Reply-To: Your message of "Wed, 18 Aug 1993 21:36:48 +0700." <9308181936.AA18838@quasi.vmars.tuwien.ac.at> Date: Wed, 18 Aug 1993 12:59:25 -0700 From: Andrew Valencia Status: OR >gzip should probably be included in the package, or at least a hint on >where to find it. Alternatively it could be repackaged with a more >common archiver such as zoo or zip. This would also have the advantage >that you don't need several megabytes of free space just to hold >uncompressed tar files. Well, you'll need that space after you extract to build anyway. I chose the current scheme because gzip is better at compressing than pkzip (I use -9), and tar's default to extracting in a directory tree, whereas pkunzip needs extra switches. I have also not had great experiences with extracting directory hierarchies out of zip archives on UNIX systems. People sometimes want to do that. I've added a note to the readme, and put a copy of gzip.exe out on the FTP directory too. Andy From hp@quasi.vmars.tuwien.ac.at Wed Aug 18 12:44:21 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20061; Wed, 18 Aug 93 12:44:20 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00163; Wed, 18 Aug 93 12:47:21 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09860(netkeeper.sj.nec.com ); Wed, 18 Aug 93 12:46:38 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28967(archimedes.inoc.sj.nec.com ); Wed, 18 Aug 93 12:46:36 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA08040 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 12:40:23 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00145); Wed, 18 Aug 93 12:40:55 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA07989 (5.67a/IDA-1.5 for ); Wed, 18 Aug 1993 12:38:58 -0700 Received: by quasi.vmars.tuwien.ac.at id AA18838 (5.64+/IDA-1.3.4 for vsta@cisco.com); Wed, 18 Aug 93 21:36:49 +0200 From: Peter Holzer Message-Id: <9308181936.AA18838@quasi.vmars.tuwien.ac.at> Subject: Re: Help!! Unable to extract VSTa sources To: vsta@cisco.com Date: Wed, 18 Aug 93 21:36:48 MET DST In-Reply-To: <9308181914.AA00234@chicago.dcsd.sj.nec.com.dcsd.sj.nec.com>; from "Abbie Matthews x2959" at Aug 18, 93 12:14 pm Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Abbie Matthews x2959) wrote: > > HI, > > I downloaded the vsta sources from ftp.cisco.com:vandys/vsta > > I tried to use djtarx.exe on my DOS 5.00 PC and was unable to get it to > work or any meaningful info from it. (I set FTP to binary etc.). It > tries to extract files with graphic character names and prompts me to > provide a name (which I am unable to do!!). The tar files are compressed with gzip. You have to uncompress them first. Gzip is available from your nearest GNU archive (I think there are even DOS executables). gzip should probably be included in the package, or at least a hint on where to find it. Alternatively it could be repackaged with a more common archiver such as zoo or zip. This would also have the advantage that you don't need several megabytes of free space just to hold uncompressed tar files. hp -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From vandys@cisco.com Tue Aug 17 21:26:51 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12172; Tue, 17 Aug 93 21:26:50 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08625; Tue, 17 Aug 93 21:29:48 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09809(netkeeper.sj.nec.com ); Tue, 17 Aug 93 21:29:47 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27556(archimedes.inoc.sj.nec.com ); Tue, 17 Aug 93 21:29:43 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04447 (5.67a/IDA-1.5 for ); Tue, 17 Aug 1993 21:22:38 -0700 Received: from barley.cisco.com by amri.cisco.com (AA00531); Tue, 17 Aug 93 21:20:53 -0700 Received: by barley.cisco.com id AA07734 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Tue, 17 Aug 1993 21:19:42 -0700 Date: Tue, 17 Aug 1993 21:19:42 -0700 From: Andrew Valencia Message-Id: <199308180419.AA07734@barley.cisco.com> To: vsta@cisco.com Subject: Patch pat.4 Status: OR This patch avoids GCC's built-in knowledge of the type of exit(). The function previously named exit() in the kernel wasn't really the exit() system call (although it implemented said call), so it has been renamed. *** c:/tmp/T0AA.AAA Tue Aug 17 21:15:26 1993 --- kern/proc.c Tue Aug 17 21:11:10 1993 *************** *** 522,538 **** free(p); } /* ! * exit() ! * The exit() system call * * Tricky once we tear down our kernel stack, because we can no longer * use stack variables once this happens. The trivial way to deal with * this is to declare them "register" and hope the declaration is honored. * I'm trying to avoid this by using just the percpu "curthread" value. */ ! exit(int code) { struct thread *t = curthread, *t2, **tp; struct proc *p = t->t_proc; int last; --- 522,541 ---- free(p); } /* ! * do_exit() ! * The exit() system call, really * * Tricky once we tear down our kernel stack, because we can no longer * use stack variables once this happens. The trivial way to deal with * this is to declare them "register" and hope the declaration is honored. * I'm trying to avoid this by using just the percpu "curthread" value. + * + * GCC tends to *know* what exit() means, so we name it do_exit() and + * avoid the issue. */ ! do_exit(int code) { struct thread *t = curthread, *t2, **tp; struct proc *p = t->t_proc; int last; *************** *** 548,556 **** break; } tp = &t2->t_next; } ! ASSERT(t2, "exit: lost thread"); last = (p->p_threads == 0); /* * Accumulate CPU in proc --- 551,559 ---- break; } tp = &t2->t_next; } ! ASSERT(t2, "do_exit: lost thread"); last = (p->p_threads == 0); /* * Accumulate CPU in proc *************** *** 605,613 **** p_lock(&runq_lock, SPLHI); ATOMIC_DEC(&cpu.pc_locks); /* swtch() will handle dispatch */ for (;;) { swtch(); ! ASSERT(0, "exit: swtch returned"); } } /* --- 608,616 ---- p_lock(&runq_lock, SPLHI); ATOMIC_DEC(&cpu.pc_locks); /* swtch() will handle dispatch */ for (;;) { swtch(); ! ASSERT(0, "do_exit: swtch returned"); } } /* *** c:/tmp/T0AA.AAA Tue Aug 17 21:15:28 1993 --- mach/syscall.c Tue Aug 17 21:09:46 1993 *************** *** 18,26 **** /* #define SYSCALLTRACE /* */ extern int msg_port(), msg_connect(), msg_accept(), msg_send(), msg_receive(), msg_reply(), msg_disconnect(), msg_err(); ! extern int exit(), fork(), fork_thread(), enable_io(), enable_isr(), mmap(), munmap(), strerror(), notify(), clone(); extern int page_wire(), page_release(), enable_dma(), time_get(), time_sleep(), exec(), waits(), perm_ctl(), set_swapdev(), run_qio(), set_cmd(), pageout(), getid(), unhash(); --- 18,26 ---- /* #define SYSCALLTRACE /* */ extern int msg_port(), msg_connect(), msg_accept(), msg_send(), msg_receive(), msg_reply(), msg_disconnect(), msg_err(); ! extern int do_exit(), fork(), fork_thread(), enable_io(), enable_isr(), mmap(), munmap(), strerror(), notify(), clone(); extern int page_wire(), page_release(), enable_dma(), time_get(), time_sleep(), exec(), waits(), perm_ctl(), set_swapdev(), run_qio(), set_cmd(), pageout(), getid(), unhash(); *************** *** 37,45 **** {msg_receive, 2}, /* 4 */ {msg_reply, 2}, /* 5 */ {msg_disconnect, 1}, /* 6 */ {msg_err, 3}, /* 7 */ ! {exit, 1}, /* 8 */ {fork, 0}, /* 9 */ {fork_thread, 1}, /* 10 */ {enable_io, 2}, /* 11 */ {enable_isr, 2}, /* 12 */ --- 37,45 ---- {msg_receive, 2}, /* 4 */ {msg_reply, 2}, /* 5 */ {msg_disconnect, 1}, /* 6 */ {msg_err, 3}, /* 7 */ ! {do_exit, 1}, /* 8 */ {fork, 0}, /* 9 */ {fork_thread, 1}, /* 10 */ {enable_io, 2}, /* 11 */ {enable_isr, 2}, /* 12 */ *** c:/tmp/T0AA.AAA Tue Aug 17 21:15:28 1993 --- mach/trap.c Tue Aug 17 21:12:34 1993 *************** *** 489,497 **** { struct evframe e; struct trapframe *f; struct proc *p; ! extern void exit(); ASSERT(t->t_uregs, "sendev: no user frame"); f = t->t_uregs; --- 489,497 ---- { struct evframe e; struct trapframe *f; struct proc *p; ! extern int do_exit(); ASSERT(t->t_uregs, "sendev: no user frame"); f = t->t_uregs; *************** *** 505,513 **** t->t_pid, ev); dbg_enter(); #endif strcpy(p->p_event, ev); ! exit(_W_EV); } /* * Build event frame --- 505,513 ---- t->t_pid, ev); dbg_enter(); #endif strcpy(p->p_event, ev); ! do_exit(_W_EV); } /* * Build event frame *************** *** 524,532 **** printf("Stack overflow pid %ld/%ld sp 0x%x\n", p->p_pid, t->t_pid, f->esp); dbg_enter(); #endif ! exit(1); } /* * Update user's registers to reflect this nesting --- 524,532 ---- printf("Stack overflow pid %ld/%ld sp 0x%x\n", p->p_pid, t->t_pid, f->esp); dbg_enter(); #endif ! do_exit(1); } /* * Update user's registers to reflect this nesting From vandys@cisco.com Thu Aug 19 08:53:11 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26861; Thu, 19 Aug 93 08:53:10 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00682; Thu, 19 Aug 93 08:56:16 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23243(netkeeper.sj.nec.com ); Thu, 19 Aug 93 08:56:14 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01058(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 08:56:12 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28887 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 08:50:54 -0700 Received: from barley.cisco.com by amri.cisco.com (AA00929); Thu, 19 Aug 93 08:51:15 -0700 Received: by barley.cisco.com id AA02895 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Thu, 19 Aug 1993 08:49:28 -0700 Date: Thu, 19 Aug 1993 08:49:28 -0700 From: Andrew Valencia Message-Id: <199308191549.AA02895@barley.cisco.com> To: vsta@cisco.com Subject: Patch pat.5 Status: OR This patch keeps the kbd server from abort()'ing when an arrow key or other extended key is hit on the IBM PC keyboard. *** c:/tmp/T0AA.AAA Thu Aug 19 08:49:22 1993 --- kbd/isr.c Thu Aug 19 08:43:10 1993 *************** *** 55,65 **** ch = shift ? shifted[c] : normal[c]; } /* ! * Oops. */ ! ASSERT_DEBUG(ch != 0x80, "key_event: shift in data"); /* * Convert to control characters if CTL key down */ --- 55,67 ---- ch = shift ? shifted[c] : normal[c]; } /* ! * Arrow keys and stuff like that--ignore for now. */ ! if (ch == 0x80) { ! return; ! } /* * Convert to control characters if CTL key down */ From jrp@accint.dmc.com Thu Aug 19 13:12:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28007; Thu, 19 Aug 93 13:12:35 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01307; Thu, 19 Aug 93 13:15:41 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17761(netkeeper.sj.nec.com ); Thu, 19 Aug 93 13:15:40 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01901(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 13:15:37 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA18747 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 13:08:44 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00219); Thu, 19 Aug 93 13:08:56 -0700 Received: from dmc.com (HULK.DMC.COM) by dirt.cisco.com with SMTP id AA18660 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 13:07:07 -0700 Received: from accint by DMC.COM (MX V3.3 VAX) with UUCP; Thu, 19 Aug 1993 16:02:33 EST Received: by accint.dmc.com (4.1/SMI-4.1) id AA02329; Thu, 19 Aug 93 01:28:02 EDT Message-Id: <9308190528.AA02329@accint.dmc.com> To: vsta@cisco.com Subject: Shared Libraries.... Date: Thu, 19 Aug 93 01:27:59 EDT From: jrp@accint.dmc.com Status: OR Okay, what Andrew basically wants is what PRIMOS called Static Libraries. Drawbacks: 1) You have to reserve memory locations for the call vectors into the library, on a per-library basis. 2) Testing is a problem, because you can't have multiple instances of a library in the correct place in virtual memory, on a per-user basis. This is more of a problem than it sounds, because some buggy code (yes, it *does* get written sometimes) can work very well in static mode, but can really screw when shared. 3) Dynamic Links go away, which means that you can't override a library's functions. (Very useful in some situations.) Now, PRIMOS about 12 years ago said "This sucks", and spent some time playing around with different schemes, which finally culminated in EPF (Executable Program Format is their term for it) Libraries, Registered EPFs, and Ring 0 EPFs. EPFs have relocatable code areas, data, static data, and DYNT,as well as a few other bits, and they used simple relocation which means that you had a Code area (usually in a different segment, because you could protect an entire segment as, for example, eXecute only), Data area, etc, and only allocated the pages out of these segments you needed. User Code was VMFA'd (Virtual Memory File Accessed) directly from the executable file on a per-invocation basis. (PRIMOS had an invocation stack, instead of shells), so you could run a program, change a library, and rerun a program with the new library without hurting someone who was running the program concurrently, something which static shared libraries can't do. Data, and DYNTS (which were snapped at execute-time) went into their own areas. Registered EPF's did two things, they put the code in the same place for all users (saving MMAP and PMAP space), although it was still dynamic, so you didn't have to recompile if you wanted to insert a library somewhere at random in what was really kernel space. They also took any DYNT's which could be snapped into other known places, and pre-snapped them. (It gets complicated when you have forward dependencies, however). This, it turns out, gave a HUGE improvement at system startup time, and saved a fair bit of memory. Oracle, I believe when we tested it, get about 20% smaller, and started up about 400% faster. This also (through serious magic) did the same thing as 'normal' EPF's, where you could replace a registered library, and not effect other users using the current library. Also, there was something called shared static data, which, of course, had the same virtual address for all processes, and was writable through all processes. (We didn't, but you *can* do data protection with this scheme, so that static data can only be accessed while within this library. Very very magic, but very useful.) Ring 0 EPF's were along the same line as registered EPF's, in fact used most of the same initialization code, but were to be used in the kernel. Since PRIME started to decline when I got there, nobody really cared, and this project was never really completed, but much of the code remained, just not turned on. The person who did much of the EPF phase 1 and 2 design was really off the wall, and made it much more complicated than it had to be, and, under the Guidence of a Senior Technical and *really* smart (and sane) guy, it came out to be a simple, and fairly elegant architecture. But, like anything over a few years of hacking, it, when I got on the scene, started looking a little ragged around the corners. This is pretty much how Prime did these things, I had a part in the Registered EPF part of the project. I don't think I'm telling secrets out of school, however, please don't sue me. This might give you some more ideas, I do agree with the gentleperson who started this topic, do it right, or don't do it at all. (Although I don't claim this is the only right way, it certainly is pleasant.) I'll try to field any questions you may have... Oh, something about Dynts which you might find interesting: DYNT's were actually pointers to character strings with the high bit (The hardware FAULT bit) turned on. PRIMOS trapped the fault (instead of the common practice of making some mmap entry 'invalid' and geting the trap this way) read the string, called the functions which searched the hash table, then searched the libraries in an LD_LIBRARY_PATH type manner, and replaced the pointer to the string with a pointer to either the data, or the Function which was referenced, and reexecuted the instruction. So, you can see how presnapping dynts reduced significantly the overhead of startup. Have fun! Jason R. Pascucci jrp%accint.uucp@dmc.com From mackinla@cs.curtin.edu.au Fri Aug 20 09:27:23 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05181; Fri, 20 Aug 93 09:27:22 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01881; Fri, 20 Aug 93 09:30:34 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01831(netkeeper.sj.nec.com ); Fri, 20 Aug 93 09:30:33 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03750(archimedes.inoc.sj.nec.com ); Fri, 20 Aug 93 09:30:31 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA11641 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 09:23:55 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00385); Fri, 20 Aug 93 09:23:58 -0700 Received: from marsh.cs.curtin.edu.au by dirt.cisco.com with SMTP id AA11566 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 09:22:19 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA21965 (5.67a/IDA-1.5); Sat, 21 Aug 1993 00:22:49 +0800 Received: by lillee.cs.curtin.edu.au id AA22905 (5.67a/IDA-1.4.4); Sat, 21 Aug 1993 00:22:49 +0800 From: Pat Mackinlay Message-Id: <199308201622.AA22905@lillee.cs.curtin.edu.au> Subject: Re: Problem with booting VSTa To: vandys@cisco.com (Andrew Valencia) Date: Sat, 21 Aug 1993 00:22:48 +0800 (WST) Cc: vsta@cisco.com In-Reply-To: <199308201533.AA25686@glare.cisco.com> from "Andrew Valencia" at Aug 20, 93 08:33:43 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 896 Status: OR > boot/boot.lst, and switch your disk parameters from readp to cmos (or > vice versa, if you're already using cmos). At worst, find out what > parameters DOS is using and use the :: > format for your disk server. This hack is still bothering me. Can I ask how many people are actually using the "cmos" configuration successfully? I have a nasty feeling that it won't work on a reasonably large number of machines... An slightly cleaner method would be to hack BOOT.EXE so that it makes a "special case" of the WD server. This would probably be a better solution in the long run, as the fake geometry is important when you deal with SCSI disks too. Anyone else have any bright ideas? Pat -- "There's only one thing left to do Mama, I got to ding a ding dang my dang a long ling long" (Jesus Built My Hotrod -- Ministry) GCS d* -p+ c++ l++ m--- s+/- !g w- t- r From vandys@cisco.com Fri Aug 20 08:37:38 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05119; Fri, 20 Aug 93 08:37:37 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01863; Fri, 20 Aug 93 08:40:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00787(netkeeper.sj.nec.com ); Fri, 20 Aug 93 08:40:48 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03569(archimedes.inoc.sj.nec.com ); Fri, 20 Aug 93 08:40:41 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA08796 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 08:35:06 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00345); Fri, 20 Aug 93 08:35:19 -0700 Received: from localhost by glare.cisco.com with SMTP id AA25686 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 08:33:43 -0700 Message-Id: <199308201533.AA25686@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: Problem with booting VSTa In-Reply-To: Your message of "Fri, 20 Aug 1993 13:47:00 +0200." <199308201147.AA21051@faui01.informatik.uni-erlangen.de> Date: Fri, 20 Aug 1993 08:33:43 -0700 From: Andrew Valencia Status: OR >init: can't find root, sleeping >Assertion failed in file fat.c, line 122 >Fatal error: fat_init: bad sector size Your DOS filesystem server bailed out on you. It read in the boot block, applied a sanity check to said block, and didn't like what it saw. Usually this means you didn't get your geometry right; have a look in boot/boot.lst, and switch your disk parameters from readp to cmos (or vice versa, if you're already using cmos). At worst, find out what parameters DOS is using and use the :: format for your disk server. If you still have no luck, let us know what type of disk you're using and its geometry. I'll guide you through the basics of talking to the disk in standalone mode using testsh. Hopefully you can just use the CMOS parameters and be up and running without further bother. Andy From hp@quasi.vmars.tuwien.ac.at Fri Aug 20 02:55:31 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29299; Fri, 20 Aug 93 02:55:29 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01799; Fri, 20 Aug 93 02:58:40 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26887(netkeeper.sj.nec.com ); Fri, 20 Aug 93 02:58:39 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03162(archimedes.inoc.sj.nec.com ); Fri, 20 Aug 93 02:58:35 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA08077 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 02:48:14 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00249); Fri, 20 Aug 93 02:37:34 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA04916 (5.67a/IDA-1.5 for ); Fri, 20 Aug 1993 02:35:53 -0700 Received: by quasi.vmars.tuwien.ac.at id AA04564 (5.64+/IDA-1.3.4 for vsta@cisco.com); Fri, 20 Aug 93 11:33:42 +0200 From: Peter Holzer Message-Id: <9308200933.AA04564@quasi.vmars.tuwien.ac.at> Subject: Re: VSTa lockups and Shared Libraries.... To: vsta@cisco.com Date: Fri, 20 Aug 93 11:33:39 MET DST In-Reply-To: <9308200306.AA09646@silk1.nsis.cl.nec.co.jp>; from "Gavin Thomas Nicol" at Aug 20, 93 12:06 pm Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Gavin Thomas Nicol) wrote: > > >>I don't really see the need for 2 different systems. I undertand > >>Andys points about what he wants to see, but I don't know if it's > >>worth the bother to have 2 different systems, when dll can do just > >>fine for both. Anyway, as Andy said, "let them who do the work, decide". Agreed. > I think PIC is out, even though it would be > nice. We have to think of a better idea.... How about the following: Reserve some portion of the virtual address space of each process for shared libraries. Whenever a process needs a shared library, it is mapped into this space and immediately relocated. If a second process needs the same library it just gets mapped into its address space at the same address. The data segment needs to be duplicated, of course. User programs could be relocated when loaded or they could use jump tables. When the last process using a shared library exits, the space could be freed again (in this case it is probably better to allocate space in large chunks (say 4MB) to reduce fragmentation). We don't need PIC for that, but we have to relocate each library when it is loaded and the size of all shared libraries in use at once is limited by the virtual address space. What do you think? -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From nick@nsis.cl.nec.co.jp Thu Aug 19 21:01:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29074; Thu, 19 Aug 93 21:01:54 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01647; Thu, 19 Aug 93 21:05:04 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23479(netkeeper.sj.nec.com ); Thu, 19 Aug 93 21:05:03 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02902(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 21:05:01 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA19725 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:58:39 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00357); Thu, 19 Aug 93 20:58:58 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA19717 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:57:13 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA18001; Fri, 20 Aug 1993 12:57:10 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA23634; Fri, 20 Aug 1993 12:57:09 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA02636; Fri, 20 Aug 1993 12:57:07 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA10069; Fri, 20 Aug 93 12:57:05 JST Date: Fri, 20 Aug 93 12:57:05 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308200357.AA10069@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Thu, 19 Aug 1993 20:43:45 -0700 <199308200343.AA11837@glare.cisco.com> Subject: VSTa lockups and Shared Libraries.... Status: OR >>Yep, a *very* crude one, and a polling keyboard driver (*that* was >>fun...) > >Is it enough like an IBM PC for me to drag it over? I don't mind >swelling the kernel a little bit so long as it's behind #ifdef KDB. I'll have a look over the weekend (if I get time), and try to make it a bit tidier, and less machine dependent. Hopefully, I'll have something you can try on Monday. As for CR/LF, I meant after we get a better filesystem. Finally (I never stop talking once I start...), how could we do ps command for VSTa? I'm going to need to monitor process size, and entering the debugger is rather inconvenient.... Does someone want to do a /proc server? From vandys@cisco.com Thu Aug 19 20:48:22 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29069; Thu, 19 Aug 93 20:48:19 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01643; Thu, 19 Aug 93 20:51:24 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23380(netkeeper.sj.nec.com ); Thu, 19 Aug 93 20:51:21 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02892(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 20:51:19 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA18691 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:46:09 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00353); Thu, 19 Aug 93 20:45:27 -0700 Received: from localhost by glare.cisco.com with SMTP id AA11837 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:43:45 -0700 Message-Id: <199308200343.AA11837@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: VSTa lockups and Shared Libraries.... In-Reply-To: Your message of "Fri, 20 Aug 1993 12:06:20 +0200." <9308200306.AA09646@silk1.nsis.cl.nec.co.jp> Date: Thu, 19 Aug 1993 20:43:45 -0700 From: Andrew Valencia Status: OR >Yep, a *very* crude one, and a polling keyboard driver (*that* was >fun...) Is it enough like an IBM PC for me to drag it over? I don't mind swelling the kernel a little bit so long as it's behind #ifdef KDB. >On the 386 I guess PIC will suck 5-20% depending on the code. I once >messed with gcc's register allocation an crippled it a bit just to see >how much register usage affected speed. That was the results or >crippling one register. I think PIC is out, even though it would be >nice. We have to think of a better idea.... I guess we're left with fixed address assignment (which we all know, for the general case, is not good enough) or doing relocation & address assignment on-the-fly. Hmmm... what about doing a shlib server, and then doing mmap()'s off of files in the shlib server. During bootup you'd write a library to it, and then when you close()'ed it the server would relocate the library and start advertising it under the given name. I don't know, just a wild thought. >I'm *really* looking forward to getting a decent filesystem. BTW. I >wonder if we shouldn't remove *all* the CR/LF conversion stuff in the >libraries, and just go straight Unix style. The more I think about it, >the more I think a single character EOL is important. I believe all of VSTa's C library uses single '\n'. gets()/fgets() will understand \r\n also, although puts()/fputs() also follow the single \n rule. I don't think the gets() conversion is causing your problems. It's just that we're living in a DOS cross-compilation environment, and still running into DOS conventions sometimes. We're living with it--at least for now--because it was convenient, and we can't strip the \r's until we have a native port of all our utilities including RCS, or until somebody finds the DOS RCS port and does a special version which uses UNIX-style line termination. Andy From nick@nsis.cl.nec.co.jp Thu Aug 19 16:30:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28620; Thu, 19 Aug 93 16:30:27 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01543; Thu, 19 Aug 93 16:33:35 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA20198(netkeeper.sj.nec.com ); Thu, 19 Aug 93 16:33:34 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02433(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 16:33:32 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA01579 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 16:28:11 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00269); Thu, 19 Aug 93 16:28:30 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA01542 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 16:26:32 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA26454; Fri, 20 Aug 1993 08:26:29 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA10845; Fri, 20 Aug 1993 08:26:28 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA16912; Fri, 20 Aug 1993 08:26:26 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA06297; Fri, 20 Aug 93 08:26:25 JST Date: Fri, 20 Aug 93 08:26:25 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308192326.AA06297@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: VSTa lockups and Shared Libraries.... Status: O Lockups: >The bug is that the keyboard server doesn't expect to get any of the >extended keys yet. I've changed the server to just ignore the keys >instead of abort()'ing. Now the arrow keys are simply ignored. I >suppose nick@nsis.cl.nec.co.jp will have to tell us eventually how he >wants to hear about these keys for his windowing system. I have no problems with the keyboard driver because I'm not using the one which came with VSTa (I run VSTa on a completely non-IBM compatible system). I wrote my own :-) Same with the console. Mine supports kanji, and yes, I can even see it in memacs! The one you all see is a variation of that. Anyway, my keyboard driver has an array of 256 function pointers, and calls a function for each keystroke. This sounds slow, but in practice, it's pretty fast, and very flexible: my arrow keys, and function keys emulate the vt100. Eventually, I'm going to rewrite this driver again such that we can download "keyboard maps" to it, or to change the mapping to "raw", vt100, etc. That way, I'll be able to have whatever mapping I need for the window system. I want to get bitblt done before I start messing with this though. I should note that the NEC rs232c port is really flaky, so *my* kernel debugger plops me onto the *console*. Can't miss it that way! Shared libraries: I didn't start this thread, but I mentioned it to Andy a month or two ago. I read the PRIMOS idea with interest, it sounds good. I don't really see the need for 2 different systems. I undertand Andys points about what he wants to see, but I don't know if it's worth the bother to have 2 different systems, when dll can do just fine for both. Anyway, as Andy said, "let them who do the work, decide". Bitblt: Well I have bitblt fairly well skeletonised, and a few sub-systems done. I still have a lot to do. Does anyone on the list know a fast algorithm for ellipses/arcs? I have a killer algorithm for circles... The algorithm should take the following parameters: x,y,width,height,start_degree, end_degree. TTFN From vandys@cisco.com Thu Aug 19 19:53:44 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29058; Thu, 19 Aug 93 19:53:42 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01629; Thu, 19 Aug 93 19:56:51 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22812(netkeeper.sj.nec.com ); Thu, 19 Aug 93 19:56:50 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02850(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 19:56:48 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA11087 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 19:50:10 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00324); Thu, 19 Aug 93 19:50:09 -0700 Received: from localhost by glare.cisco.com with SMTP id AA10714 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 19:48:27 -0700 Message-Id: <199308200248.AA10714@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: VSTa lockups and Shared Libraries.... In-Reply-To: Your message of "Fri, 20 Aug 1993 08:26:25 +0200." <9308192326.AA06297@silk1.nsis.cl.nec.co.jp> Date: Thu, 19 Aug 1993 19:48:26 -0700 From: Andrew Valencia Status: O >Anyway, my keyboard driver has an array of 256 function pointers, and >calls a function for each keystroke. This sounds slow, but in >practice, it's pretty fast, and very flexible: my arrow keys, and >function keys emulate the vt100. Well, after all, how fast can you type? A couple keys a second at most. A function call these days is < 1 uSec, so efficiency is not really a big concern. Mind you, this is the keyboard side--the screen needs to be kept just as fast as it can! will happily replace my bare-bones keybd server for one with decent features. >I should note that the NEC rs232c port is really flaky, so *my* kernel >debugger plops me onto the *console*. Can't miss it that way! So did you embed a console driver in the microkernel? How do you drive the screen? Talk to the keyboard? >I don't really see the need for 2 different systems. I undertand >Andys points about what he wants to see, but I don't know if it's >worth the bother to have 2 different systems, when dll can do just >fine for both. Anyway, as Andy said, "let them who do the work, decide". Amen. Although if you do an evil job of it don't be surprised if I want to help you rework it into shape! I'm pretty concerned about PIC code generation for i386--having to use PC relative modes and burn a register seems like a pretty dear price for the "other half" of your kernel. If somebody could show me that the cost was X%, then we could look at the price and decide whether it was worth it. Personally I'd pay 5% to go with a single shlib scheme. 10%... hits my pain threshold. If I end up doing it, don't be surprised if I break out a portion of the C library (all internal--every ANSI and POSIX interface would remain in the C library) and make it callable in a way which doesn't even look like a library. In fact, you could consider them "system calls" which are invoked at the cost of a procedure call and remain in ring 3. But that's just if I do it. Maybe. :-) >Bitblt: >Well I have bitblt fairly well skeletonised, and a few sub-systems >done. I still have a lot to do. Does anyone on the list know a fast >algorithm for ellipses/arcs? I have a killer algorithm for circles... I have buffering and contiguous file allocation written for my filesystem. I need to finish read/write and then I can start on directory access. Since it does file version, I think I'm going to implement them as a comma separated number. So you'd create a file like: % cat > file and then write over it with % cat > file But you could then see the old "file" as: % cat file,1 Tenex used semicolon, but this has meaning to the shell. Comma doesn't look as nice. It'll definitely be a #define, in any case. Regards... Andy From nick@nsis.cl.nec.co.jp Thu Aug 19 20:11:37 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29063; Thu, 19 Aug 93 20:11:36 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01638; Thu, 19 Aug 93 20:14:45 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22993(netkeeper.sj.nec.com ); Thu, 19 Aug 93 20:14:44 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02872(archimedes.inoc.sj.nec.com ); Thu, 19 Aug 93 20:14:42 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA11652 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:07:58 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00331); Thu, 19 Aug 93 20:08:17 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA11635 (5.67a/IDA-1.5 for ); Thu, 19 Aug 1993 20:06:30 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA14201; Fri, 20 Aug 1993 12:06:23 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA21411; Fri, 20 Aug 1993 12:06:22 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA29423; Fri, 20 Aug 1993 12:06:21 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA09646; Fri, 20 Aug 93 12:06:20 JST Date: Fri, 20 Aug 93 12:06:20 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308200306.AA09646@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: VSTa lockups and Shared Libraries.... Status: OR >be kept just as fast as it can! will happily replace my bare-bones >keybd server for one with decent features. When I have it done *to my satisfaction*, of course I will share it. Actually, if someone else wants to do it while I'm doing bitblt, go for it, otherwise you'll have to wait a bit. >>I should note that the NEC rs232c port is really flaky, so *my* kernel >>debugger plops me onto the *console*. Can't miss it that way! > >So did you embed a console driver in the microkernel? How do you drive >the screen? Talk to the keyboard? Yep, a *very* crude one, and a polling keyboard driver (*that* was fun...) >>I don't really see the need for 2 different systems. I undertand >>Andys points about what he wants to see, but I don't know if it's >>worth the bother to have 2 different systems, when dll can do just >>fine for both. Anyway, as Andy said, "let them who do the work, decide". > >Amen. Although if you do an evil job of it don't be surprised if I want >to help you rework it into shape! I'm pretty concerned about PIC code >generation for i386--having to use PC relative modes and burn a register >seems like a pretty dear price for the "other half" of your kernel. >If somebody could show me that the cost was X%, then we could look at >the price and decide whether it was worth it. Personally I'd pay 5% >to go with a single shlib scheme. 10%... hits my pain threshold. On the 386 I guess PIC will suck 5-20% depending on the code. I once messed with gcc's register allocation an crippled it a bit just to see how much register usage affected speed. That was the results or crippling one register. I think PIC is out, even though it would be nice. We have to think of a better idea.... I'm *really* looking forward to getting a decent filesystem. BTW. I wonder if we shouldn't remove *all* the CR/LF conversion stuff in the libraries, and just go straight Unix style. The more I think about it, the more I think a single character EOL is important. From nick@nsis.cl.nec.co.jp Sun Aug 22 16:21:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18622; Sun, 22 Aug 93 16:21:48 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02834; Sun, 22 Aug 93 16:25:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27036(netkeeper.sj.nec.com ); Sun, 22 Aug 93 16:25:12 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06363(archimedes.inoc.sj.nec.com ); Sun, 22 Aug 93 16:25:10 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28745 (5.67a/IDA-1.5 for ); Sun, 22 Aug 1993 16:18:40 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00309); Sun, 22 Aug 93 16:18:10 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by dirt.cisco.com with SMTP id AA28725 (5.67a/IDA-1.5 for ); Sun, 22 Aug 1993 16:16:58 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA05351; Mon, 23 Aug 1993 08:16:54 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA07132; Mon, 23 Aug 1993 08:16:53 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA27124; Mon, 23 Aug 1993 08:16:52 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA00312; Mon, 23 Aug 93 08:16:51 JST Date: Mon, 23 Aug 93 08:16:51 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308222316.AA00312@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: DOS dying and Shared Libraries.... Status: R Peter Holzer writes >User programs could be relocated when loaded or they could use jump >tables. We should not use jump tables, because they cause all sorts of problems when upgrading, and we cannot use PIC because of performance problems. I kind of liked the idea Andy has with the shlib server; maybe because it's so different. I'm not really qualified to say what is best though because 1) I'll not be implementing shared libraries unless they aren't done before the windowing system is. 2) I have no *real* experience in designing such systems, even though I know the pitfalls of current systems. Somebody else metioned that DOS bailed out on them. If the disk geometry looks OK. check the block size for DOS. If the block size is 1024 bytes, I'll tell you how to patch it to fix it. (I think USA and non-USA DOS differ a bit. I know the NEC version certainly is different.) I'll be sending Andy a new string.c, string.h, stdio.h, console kernel debugger, and a few other things later today. From vandys@cisco.com Sun Aug 22 18:37:11 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18686; Sun, 22 Aug 93 18:37:10 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02857; Sun, 22 Aug 93 18:40:35 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA28057(netkeeper.sj.nec.com ); Sun, 22 Aug 93 18:40:34 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06576(archimedes.inoc.sj.nec.com ); Sun, 22 Aug 93 18:40:32 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA02697 (5.67a/IDA-1.5 for ); Sun, 22 Aug 1993 18:33:28 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00359); Sun, 22 Aug 93 18:32:03 -0700 Received: from localhost by glare.cisco.com with SMTP id AA17325 (5.67a/IDA-1.5 for ); Sun, 22 Aug 1993 18:30:53 -0700 Message-Id: <199308230130.AA17325@glare.cisco.com> To: This could be my last regress Cc: vsta@cisco.com Subject: Re: VSTa Date: Sun, 22 Aug 1993 18:30:53 -0700 From: Andrew Valencia Status: R Cool! You're welcome to scope out the effort. You'll need access to a 386 PC with IDE or ST-506 disks (well, one disk is fine!) We have a mailing list (vsta@cisco.com, vsta-request@cisco.com for admin stuff) and an FTP site for you to pull sources (ftp.cisco.com:vandys/vsta). Start with the readme, pull what else you desire, and see about getting it booted up. Note (the doc says this, but I guess it's easy to miss) that you'll need the DJ Delorie C compiler package for DOS to get yourself up and running. I've compile and run with both 1.X and 2.X GCC flavors, but I've received some complaints concerning earlier 2.X flavors. The patches in the patches subdir should help. I've been starting to ponder writing a "guided tour" kind of document, but for now I guess you'll have to get by with reading the source, recognizing stuff from other OS'es, and of course, the mailing list. We currently have a bunch of people who are just getting it running and are searching about for what they might want to do. We have a from- scratch windowing system being written, and I'm busily hacking on a fancier filesystem (currently we boot & run with a DOS filesystem.) Other folks are making initial efforts on SCSI drivers, networking code, and there's a bunch of discussion (though no code yet) for shared libraries. Regards... Andy Valencia >Not sure what to say here, but I find VSTa very intriguing .. I've been >hacking on Linux for about a year and have about 6 years of C programming >behind me (including some silly real mode ASM from way back in my DOS >days ;)), and I'd love to get involved in the project ;) .. I heard about >it thru some email from some friends of mine that are already on the >mailing list, and some Linux Activists digests also .. Anyway, I'd love >to help anyway I can :) - don't know what else to say besides that I'm >a student and I have plenty of extra time :) > >Thanks, >-Tim From vandys@cisco.com Mon Aug 23 08:25:03 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26049; Mon, 23 Aug 93 08:25:02 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03013; Mon, 23 Aug 93 08:28:31 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05302(netkeeper.sj.nec.com ); Mon, 23 Aug 93 08:28:30 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07368(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 08:28:28 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA01645 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 08:22:43 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00089); Mon, 23 Aug 93 08:22:05 -0700 Received: from localhost by glare.cisco.com with SMTP id AA28781 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 08:21:05 -0700 Message-Id: <199308231521.AA28781@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: Problem with booting VSTa (No luck) In-Reply-To: Your message of "Mon, 23 Aug 1993 15:11:26 +0200." <199308231311.AA02438@faui01.informatik.uni-erlangen.de> Date: Mon, 23 Aug 1993 08:21:04 -0700 From: Andrew Valencia Status: R >I tried all the above, but it didn't make a difference. The error stays >the same. Okay, here goes the down-n-dirty way to look around on VSTa. Go to your boot/boot.lst file and comment out the lines for dos and init. At the bottom, add a line: ../bin/testsh/testsh Now go over to bin/testsh and edit the makefile. Add -DSTAND, remove the .o's, and rebuild. Go back to boot/ and run the "go" bat file. You should now be sitting in a standalone shell. Send us mail when you have this much working, and I'll walk you through the next phase. Andy From nick@nsis.cl.nec.co.jp Mon Aug 23 16:21:46 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03839; Mon, 23 Aug 93 16:21:45 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03247; Mon, 23 Aug 93 16:25:14 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02717(netkeeper.sj.nec.com ); Mon, 23 Aug 93 16:25:13 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08960(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 16:25:09 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA05564 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:18:34 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00184); Mon, 23 Aug 93 16:17:41 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by dirt.cisco.com with SMTP id AA05499 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:16:42 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA00944; Tue, 24 Aug 1993 08:16:39 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA18519; Tue, 24 Aug 1993 08:16:38 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA18985; Tue, 24 Aug 1993 08:16:37 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA15140; Tue, 24 Aug 93 08:16:36 JST Date: Tue, 24 Aug 93 08:16:36 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308232316.AA15140@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: "Marc Papen (CIP 90)"'s message of Mon, 23 Aug 1993 15:11:26 +0200 (MET DST) <199308231311.AA02438@faui01.informatik.uni-erlangen.de> Subject: Problem with booting VSTa (No luck) Status: R Well, if your DOS sector size is greater than 512 bytes, you'll be out of luck. On my machine it is 1024 bytes, and I changed dos/dos.h. The change was to the definition of SECSZ. I put: #define SECSZ (bootb.secsize0 + (bootb.secsize1 << 8)) You'll also have to change main.c (towards the bottom of main()), where it allocates the sector buffer, and reads the bootblock. ie. secbuf = malloc(1024); .... if(read(blkdev,secbuf,512) != 512) { ... Worked for me..... I hardcoded the sector buffer malloc to 1024 bytes, and the read() to 512 bytes. From vandys@cisco.com Mon Aug 23 16:26:33 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03885; Mon, 23 Aug 93 16:26:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03250; Mon, 23 Aug 93 16:30:03 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02767(netkeeper.sj.nec.com ); Mon, 23 Aug 93 16:30:02 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08985(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 16:30:00 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA05939 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:23:53 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00189); Mon, 23 Aug 93 16:23:07 -0700 Received: from localhost by glare.cisco.com with SMTP id AA19311 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:22:09 -0700 Message-Id: <199308232322.AA19311@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Problem with booting VSTa (No luck) In-Reply-To: Your message of "Tue, 24 Aug 1993 08:16:36 +0200." <9308232316.AA15140@silk1.nsis.cl.nec.co.jp> Date: Mon, 23 Aug 1993 16:22:08 -0700 From: Andrew Valencia Status: R Gavin (is that what you prefer to be called, BTW?), Is there an easy way to check what sector size the underlying disk is using? Maybe we could add a check (or better, auto-adapt) at the appropriate place? Andy p.s. I have the console kdb working. I've folded it in so that the NEC, IBM, and serial drivers can co-exist cleanly. >Well, if your DOS sector size is greater than 512 bytes, you'll be out >of luck. On my machine it is 1024 bytes, and I changed dos/dos.h. The >change was to the definition of SECSZ. I put: >... From mcpapen@cip.informatik.uni-erlangen.de Mon Aug 23 08:18:47 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26040; Mon, 23 Aug 93 08:18:46 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03008; Mon, 23 Aug 93 08:22:14 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05250(netkeeper.sj.nec.com ); Mon, 23 Aug 93 08:22:13 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07349(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 08:22:11 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA29599 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 08:15:23 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00067); Mon, 23 Aug 93 08:14:33 -0700 Received: from faui45.informatik.uni-erlangen.de by dirt.cisco.com with SMTP id AA20967 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 06:11:36 -0700 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA23117 (5.65c-5/7.3v-FAU); Mon, 23 Aug 1993 15:11:29 +0200 Received: from faui04e.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA02438 (5.65c-5/7.3m-FAU); Mon, 23 Aug 1993 15:11:27 +0200 From: "Marc Papen (CIP 90)" Message-Id: <199308231311.AA02438@faui01.informatik.uni-erlangen.de> Subject: Re: Problem with booting VSTa (No luck) To: vsta@cisco.com Date: Mon, 23 Aug 1993 15:11:26 +0200 (MET DST) In-Reply-To: <199308201533.AA25686@glare.cisco.com> from "Andrew Valencia" at Aug 20, 93 08:33:43 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1189 Status: OR I already sent this once, but it didn't seem to come through right. Sorry if you have already seen this. > Usually this means you didn't get your geometry right; have a look in > boot/boot.lst, and switch your disk parameters from readp to cmos (or > vice versa, if you're already using cmos). At worst, find out what > parameters DOS is using and use the :: > format for your disk server. I tried all the above, but it didn't make a difference. The error stays the same. > > If you still have no luck, let us know what type of disk you're using > and its geometry. I'll guide you through the basics of talking to the > disk in standalone mode using testsh. Hopefully you can just use the > CMOS parameters and be up and running without further bother. > I'm using a 43 MB Seagate ST157A (560, 5, 26) as C: drive and a 85 MB ST1102 (1024, 10, 17) as D: drive. Both are IDE drives. ( I only use the C: drive for DOS/VSTa) Both are recognized with the correct size. I hope this helps to get me going on. Bye Marc -- Marc Papen Henkestr. 41 91054 Erlangen Germany email: mcpapen@cip.informatik.uni-erlangen.de or marc@lft.uni-erlangen.de From nick@nsis.cl.nec.co.jp Mon Aug 23 16:50:11 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04050; Mon, 23 Aug 93 16:50:10 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03282; Mon, 23 Aug 93 16:53:37 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03121(netkeeper.sj.nec.com ); Mon, 23 Aug 93 16:53:33 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09046(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 16:53:31 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA07286 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:48:03 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00202); Mon, 23 Aug 93 16:47:35 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA07118 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:46:29 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA02841; Tue, 24 Aug 1993 08:46:18 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA19259; Tue, 24 Aug 1993 08:46:14 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA20100; Tue, 24 Aug 1993 08:46:12 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA15341; Tue, 24 Aug 93 08:46:10 JST Date: Tue, 24 Aug 93 08:46:10 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308232346.AA15341@silk1.nsis.cl.nec.co.jp> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Mon, 23 Aug 1993 16:22:08 -0700 <199308232322.AA19311@glare.cisco.com> Subject: Problem with booting VSTa (No luck) Status: OR >Gavin (is that what you prefer to be called, BTW?), Most people call me "nick" because Gavin in Japanese pronunciation comes out as "giyabin" or "kyabin". I really don't care though. >Is there an easy way to check what sector size the underlying disk >is using? Maybe we could add a check (or better, auto-adapt) at the >appropriate place? Sooner or later we should do this, but I don't know an easy way, without reading the BIOS. For DOS, the boot block seems to always be <= 512 bytes, though sector sizes differ, so it's not a problem, but for the new file system, we'll need something... BTW. The changes I suggested to dos should work even if the sector size is 512, 1024, or more bytes. Could you check it, and if it works, include it in the main distribution? Thanks. >p.s. I have the console kdb working. I've folded it in so that the > NEC, IBM, and serial drivers can co-exist cleanly. Did the keyboard driver work without too much hacking? That was all pure guess work! BTW. If I sent all the NEC specific stuff, would you add it to the main distribution? I will understand if you say "no" because it'll mean a lot of extra code to maintain, and you have no way to test it. Perhaps I should just keep it here for now... especially as large changes may be coming up (shared libs etc). From vandys@cisco.com Mon Aug 23 17:00:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04259; Mon, 23 Aug 93 17:00:27 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03300; Mon, 23 Aug 93 17:03:58 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03187(netkeeper.sj.nec.com ); Mon, 23 Aug 93 17:03:57 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09080(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 17:03:55 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA07919 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:57:19 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00207); Mon, 23 Aug 93 16:56:42 -0700 Received: from localhost by glare.cisco.com with SMTP id AA20276 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 16:55:43 -0700 Message-Id: <199308232355.AA20276@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Problem with booting VSTa (No luck) In-Reply-To: Your message of "Tue, 24 Aug 1993 08:46:10 +0200." <9308232346.AA15341@silk1.nsis.cl.nec.co.jp> Date: Mon, 23 Aug 1993 16:55:42 -0700 From: Andrew Valencia Status: OR >BTW. The changes I suggested to dos should work even if the sector >size is 512, 1024, or more bytes. Could you check it, and if it works, >include it in the main distribution? Thanks. Will check and see if it'll fly. >Did the keyboard driver work without too much hacking? That was all >pure guess work! Well, you had a couple little mistakes, but everything was pretty much right on the money. It didn't take too much work at all, and the result was well worth it. >BTW. If I sent all the NEC specific stuff, would you add it to the >main distribution? I will understand if you say "no" because it'll >mean a lot of extra code to maintain, and you have no way to test it. >Perhaps I should just keep it here for now... especially as large >changes may be coming up (shared libs etc). I seriously pondered leaving out the debug driver for NEC, but that just seemed too inconsiderate considering you gave me the code in the first place! :-) But let's leave the rest at least until I reorganize the source directories. As I understand it, much of your NEC-specific code resides in distinct server directories, which should help keep it clean. I placed your code under #ifdef NEC. I placed the choice of serial vs. console in the mach/param.h file. I also tidied all the debugger stuff so that the getc() kind of function will be left out unless KDB is defined. We're still a 40K microkernel when you leave out the kernel debugger! Andy From nick@nsis.cl.nec.co.jp Mon Aug 23 17:11:01 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04468; Mon, 23 Aug 93 17:11:00 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03313; Mon, 23 Aug 93 17:14:30 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03350(netkeeper.sj.nec.com ); Mon, 23 Aug 93 17:14:29 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09101(archimedes.inoc.sj.nec.com ); Mon, 23 Aug 93 17:14:27 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA08495 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 17:07:59 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00219); Mon, 23 Aug 93 17:07:39 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA08360 (5.67a/IDA-1.5 for ); Mon, 23 Aug 1993 17:06:40 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA03921; Tue, 24 Aug 1993 09:06:37 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA19898; Tue, 24 Aug 1993 09:06:36 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA21559; Tue, 24 Aug 1993 09:06:35 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA15598; Tue, 24 Aug 93 09:06:34 JST Date: Tue, 24 Aug 93 09:06:34 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9308240006.AA15598@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: NEC stuff Status: OR If you like, you can leave out the NEC stuff entirely. There are a lot of small changes in kernel for the NEC VSTa version too. It's probably easier for me to maintain the NEC version here (I know what changes are needed, so I can produce a new version quickly. Last time it took < 24 hours to port the source drop). Glad you like the kdb console code. From mcpapen@cip.informatik.uni-erlangen.de Thu Aug 26 08:25:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09884; Thu, 26 Aug 93 08:25:47 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05769; Thu, 26 Aug 93 08:29:42 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25229(netkeeper.sj.nec.com ); Thu, 26 Aug 93 08:29:41 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16022(archimedes.inoc.sj.nec.com ); Thu, 26 Aug 93 08:29:33 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28133 (5.67a/IDA-1.5 for ); Thu, 26 Aug 1993 08:21:48 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00085); Thu, 26 Aug 93 08:21:19 -0700 Received: from faui45.informatik.uni-erlangen.de by dirt.cisco.com with SMTP id AA28054 (5.67a/IDA-1.5 for ); Thu, 26 Aug 1993 08:20:51 -0700 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA03975 (5.65c-5/7.3v-FAU); Thu, 26 Aug 1993 17:20:48 +0200 Received: from faui04f.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA04195 (5.65c-5/7.3m-FAU); Thu, 26 Aug 1993 17:20:46 +0200 From: "Marc Papen (CIP 90)" Message-Id: <199308261520.AA04195@faui01.informatik.uni-erlangen.de> Subject: No luck booting To: vsta@cisco.com Date: Thu, 26 Aug 1993 17:20:44 +0200 (MET DST) In-Reply-To: <199308231521.AA28781@glare.cisco.com> from "Andrew Valencia" at Aug 23, 93 08:21:04 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 828 Status: OR > Now go over to bin/testsh and edit the makefile. Add -DSTAND, remove the > .o's, and rebuild. Go back to boot/ and run the "go" bat file. You should > now be sitting in a standalone shell. Send us mail when you have this much > working, and I'll walk you through the next phase. > I can't get the above to work. I had to edit the makefile in bin/testsh because it wouldn't run when linking with crt0.o. I replaced it with crt0srv.o. Now all went well, but after the message Launching at ... it just did nothing at all. I will be getting a new disk in a couple of days and am trying to get a terminal. Maybe I can get more info about what is goimg wromg then. Thanks for your help Marc -- Marc Papen Henkestr. 41 91054 Erlangen Germany email: mcpapen@cip.informatik.uni-erlangen.de or marc@lft.uni-erlangen.de From vandys@cisco.com Thu Aug 26 08:40:18 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09905; Thu, 26 Aug 93 08:40:17 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05809; Thu, 26 Aug 93 08:44:11 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25409(netkeeper.sj.nec.com ); Thu, 26 Aug 93 08:44:10 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16077(archimedes.inoc.sj.nec.com ); Thu, 26 Aug 93 08:44:08 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28855 (5.67a/IDA-1.5 for ); Thu, 26 Aug 1993 08:36:46 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00092); Thu, 26 Aug 93 08:35:36 -0700 Received: from localhost by glare.cisco.com with SMTP id AA13489 (5.67a/IDA-1.5 for ); Thu, 26 Aug 1993 08:35:03 -0700 Message-Id: <199308261535.AA13489@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: No luck booting In-Reply-To: Your message of "Thu, 26 Aug 1993 17:20:44 +0200." <199308261520.AA04195@faui01.informatik.uni-erlangen.de> Date: Thu, 26 Aug 1993 08:35:02 -0700 From: Andrew Valencia Status: OR >I can't get the above to work. I had to edit the makefile in bin/testsh >because it wouldn't run when linking with crt0.o. I replaced it with crt0srv.o. >Now all went well, but after the message > Launching at ... >it just did nothing at all. Ah, right. Boot programs need the crt0srv version of crt0.o. Sorry; boot arguments are relatively new and I did most of my own standalone hackery before they existed. I'm glad you fixed this and went on. Starting with my standard boot.lst, you commented out just the dos and init boot programs, and added ../bin/testsh/testsh? And you don't see *anything*? I'm surprised; the wd server should have printed out the name and size of each disk it found. You should also get the "% " prompt from testsh. Do you have a terminal hooked to COM1? You might have dropped into the kernel debugger. You might try commenting out the wd server from boot.lst, and come up with no disk storage at all. I want to see you with the standalone testsh on your screen before we continue on in search of your ailing disk. After you added -DSTAND to your testsh's makefile, you *did* remove all your .o's and recompile, didn't you? Note to all: I have pulled in Nick's (Gavin Nicol, but he says "Nick" works for him... :->) kdb-on-the-screen stuff. It's not available as a patch because it involves moving files and such, but the next source drop will include it. I'd like to hold off on this until I can offer the Alpha version of my new filesystem, but we'll see how that goes. Andy From vandys@cisco.com Fri Aug 27 10:29:24 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18855; Fri, 27 Aug 93 10:29:23 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08963; Fri, 27 Aug 93 10:33:27 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25015(netkeeper.sj.nec.com ); Fri, 27 Aug 93 10:33:25 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01627(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 10:33:23 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA21668 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 10:25:30 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00597); Fri, 27 Aug 93 10:23:03 -0700 Received: from localhost by glare.cisco.com with SMTP id AA17610 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 10:22:45 -0700 Message-Id: <199308271722.AA17610@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Shared libraries revisited In-Reply-To: Your message of "Fri, 27 Aug 1993 18:55:42 +0700." <9308271655.AA14402@quasi.vmars.tuwien.ac.at> Date: Fri, 27 Aug 1993 10:22:44 -0700 From: Andrew Valencia Status: OR >I found out a little bit about the Linux shared libraries in the mean >time, and I think it is not the way to go. They have several drawbacks: >...[lots of drawbacks, all observations I agree with] Oh, good! A straight man for me to expound my evolving shared library ideas with! :-) >As Andy suggested, there should be a server to manage them. I am not >yet sure, how they should be registered to the server: > * Some program to tell the server which libraries exist. For standard > libraries this would have to be called from /etc/rc (or even > boot.lst). Heavens, not from boot.lst. You don't have *filesystems* in boot.lst. And it's not needed. Your boot programs will be statically linked. It's once you're up and running that you'll need shared libraries. All servers look like filesystems. I envision the shlib server to be a directory with subdirectories and files. All it takes to "register" a shared library is to chdir to some place you're allowed to write, and creating a file there. When you close() the file, the shlib server then scans the library, assigns it a unique virtual address, relocates the library, and makes it available as a mappable file. > * The server searches some path for library files. There must be a > method to tell the server to change or rescan the path). The server has files written to it; it never scans paths. Remember, each process has its own private mount structure, so there is no such thing as a global pathname. >When the server knows that a library will be needed (either when the >first program asks for it or when it is registered) it chooses some >unique address and relocates the library to this address. It then >announces the address, and all processes which need the lib can mmap it >into their process space at this address. Care has to be taken to >get protection right. Since the shlib server is a filesystem, its files are protected using the same techniques as any other filesystem. Files have owners, protection, and so forth. >Since the position of the libraries is generally not known at compile >time, the executables must be stored in relocatable format also (or >alternatively, they must only use pointers to access library objects -- >I don't like that). This may make demand paging infeasible. Also, since >I don't think it is a good idea letting the process patch up itself, >the mmapping of the shared libraries should not be done by by the >process itself. Why? SunOS allows the process to "patch itself up" using ld.so as mapped into the process address space. Remember, the kernel does not understand a.out, or filesystems, or mount paths, or pathname lookups. This is a *micro*kernel. Once the process has mapped in the relocated shared library, it must either fix its own relocatable references, or use a table which has already been relocated (which assumes fixed library locations, which we don't want, I'm told). It is important that the per-process relcation not require writing the relocated library. This would force each copy of the process to have its own copy of the library. This defeats one of the key benefits of shared libraries. > * Startup times may be slow, although I don't really think so. If it > really proves to be slow, we can always put the standard libs at > fixed addresses and prerelocate the executables (I think this is > what is called `presnapping' in Primos). This is always the bane of shared libraries. > * It is not possible to override parts of a library. If you include > a different version of e.g. fprintf in your program, the library will > still use its own version. Actually I am not even sure if this is a > disadvantage :-) If you relocate the a.out at run-time, this would work. You would find the local fprintf() and not pull the one from the library. I would modify the loader so it wouldn't complain about a second fprintf() pulled in from the library. This can happen when more than one routine is in a .o, and you pull the .o for another routine, but then hit a collision. >How are processes created currently? The VSTa kernel does mmap()-type mapping of an open file. An execv() is implemented as the process opening the target a.out, verifying that it is sane, then building a table of offsets and protections for the open file. It then calls the VSTa exec() syscall, which simply replaces your address space with the mappings described by the table. The process is re-entered at the PC value it specifies in the exec() call, and you're now running with the new executable. Page faults are converted into FS_READ requests to the server of the open file. Full copy-on-write is not supported, but VSTa can break your association with a mapped page as you write it. This is enough to do exec(). >What happens if a process sends more data than the receiver expects? >The comments in msg.h and seg.c imply that one or more segments >containing the surplus data is created. The code however looks like it >is discarded (all segments of the message are mapped to the receiver's >address space, as much data as fits is copied to the segments specified >by the receiver, all segments of sent message are discarded). There are two directions. Data is mapped into the server's address space. The server can just ignore it, and the data goes away as the server takes a new request. If a server sends back too much data to a client, the extra data is simply not copied out, and thus is immediately ignored. >What is port 0x84? It is used in the assembler code a lot (in the SYNC >macro). My hardware docu (for a not 100% compatible XT :-) just says >`DO NOT USE!'. It is a harmless port, used to synch the pipeline of the 486 so that the setting of interrupt masks will not lag execution of code. If you don't do this, you can run into fatal cases where you run code with interrupt still enabled. It's described in the Compaq technical manual, but I've seen it happen at Sequent on i486 machines which are not even PC compatible. Andy From vandys@cisco.com Fri Aug 27 10:39:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18874; Fri, 27 Aug 93 10:39:03 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09002; Fri, 27 Aug 93 10:43:07 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25181(netkeeper.sj.nec.com ); Fri, 27 Aug 93 10:43:06 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01722(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 10:43:05 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA22460 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 10:34:45 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00604); Fri, 27 Aug 93 10:32:20 -0700 Received: from localhost by glare.cisco.com with SMTP id AA18046 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 10:31:56 -0700 Message-Id: <199308271731.AA18046@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: Booting into testsh does work In-Reply-To: Your message of "Fri, 27 Aug 1993 12:24:07 +0200." <199308271024.AA08179@faui01.informatik.uni-erlangen.de> Date: Fri, 27 Aug 1993 10:31:56 -0700 From: Andrew Valencia Status: OR >I tried to boot into testsh again this morning and surprise: >It worked!! >I haven't done anything to the system after my first tries so I don't know >what went wrong in the first place. >But now I get the prompt and can use the commands. >So please guide me further into getting my harddrive to work. Well, congratulations on running VSTa on your PC. Without any filesystem, I'm sure your enthusiasm is tempered by the fact that you can't DO anything! :-) Next steps (don't type the remarks on the right!): % mount 1 /namer (1 is the well-known-port for namer) % cd /namer (now in the namer "filesystem") % ls disk % cd disk % ls (now in the place where disks register) wd % cat wd (a "file" maps a name to a port) 1026% mount 1026 /wd (mount the indicated port) % cd /wd % ls (now in the wd "filesystem") wd0 wd0_dos0 wd0_p1 % sec wd0 0 ...[hex dump of sector 0 of wd0] % sec wd0 1 ...[sector 1]. You should see a disk label here % sec wd0_dos0 0 ...[sector 0 of the DOS partition. You should see MSDOSX.X here] Let me know if: - There's no disk/wd entry in the namer - There's no wd0_dos0 subdir in the wd driver - Your I/O's fail - Your sectors don't look right Regards... Andy Valencia From hp@quasi.vmars.tuwien.ac.at Fri Aug 27 10:04:18 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18822; Fri, 27 Aug 93 10:04:17 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08890; Fri, 27 Aug 93 10:08:21 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24700(netkeeper.sj.nec.com ); Fri, 27 Aug 93 10:08:20 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01489(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 10:08:17 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA20057 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 09:59:43 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00585); Fri, 27 Aug 93 09:58:18 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA20006 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 09:57:56 -0700 Received: by quasi.vmars.tuwien.ac.at id AA14402 (5.64+/IDA-1.3.4 for vsta@cisco.com); Fri, 27 Aug 93 18:55:43 +0200 From: Peter Holzer Message-Id: <9308271655.AA14402@quasi.vmars.tuwien.ac.at> Subject: Shared libraries revisited To: vsta@cisco.com Date: Fri, 27 Aug 93 18:55:42 MET DST Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR I found out a little bit about the Linux shared libraries in the mean time, and I think it is not the way to go. They have several drawbacks: * Shared libraries have fixed addresses. * Inside shared libs global variables have fixed addresses. The manual encourages you to leave space after structures and arrays for future growth. * Making libraries is complicated and requires significant magic (such as rewriting gcc output to be more position independent). I also agree, that PIC is probably too costly in terms of performance (besides, gcc is rumoured to be very buggy when producing PIC code for the 386/486). So I still believe my proposal is best. To flesh it out a little bit: Shared libraries are stored in relocatable format (output of ld -r). As Andy suggested, there should be a server to manage them. I am not yet sure, how they should be registered to the server: * Some program to tell the server which libraries exist. For standard libraries this would have to be called from /etc/rc (or even boot.lst). * The server searches some path for library files. There must be a method to tell the server to change or rescan the path). personally, I like the first method somewhat better. When the server knows that a library will be needed (either when the first program asks for it or when it is registered) it chooses some unique address and relocates the library to this address. It then announces the address, and all processes which need the lib can mmap it into their process space at this address. Care has to be taken to get protection right. Since the position of the libraries is generally not known at compile time, the executables must be stored in relocatable format also (or alternatively, they must only use pointers to access library objects -- I don't like that). This may make demand paging infeasible. Also, since I don't think it is a good idea letting the process patch up itself, the mmapping of the shared libraries should not be done by by the process itself. I see two problems with this approach: * Startup times may be slow, although I don't really think so. If it really proves to be slow, we can always put the standard libs at fixed addresses and prerelocate the executables (I think this is what is called `presnapping' in Primos). * It is not possible to override parts of a library. If you include a different version of e.g. fprintf in your program, the library will still use its own version. Actually I am not even sure if this is a disadvantage :-) Apart from the obvious question (Have I overlooked something?), I have a few others: How are processes created currently? What happens if a process sends more data than the receiver expects? The comments in msg.h and seg.c imply that one or more segments containing the surplus data is created. The code however looks like it is discarded (all segments of the message are mapped to the receiver's address space, as much data as fits is copied to the segments specified by the receiver, all segments of sent message are discarded). What is port 0x84? It is used in the assembler code a lot (in the SYNC macro). My hardware docu (for a not 100% compatible XT :-) just says `DO NOT USE!'. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From vandys@cisco.com Fri Aug 27 12:30:55 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18951; Fri, 27 Aug 93 12:30:39 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09283; Fri, 27 Aug 93 12:34:44 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26520(netkeeper.sj.nec.com ); Fri, 27 Aug 93 12:34:43 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02124(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 12:34:40 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28775 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 12:26:48 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00643); Fri, 27 Aug 93 12:24:26 -0700 Received: from localhost by glare.cisco.com with SMTP id AA22968 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 12:24:02 -0700 Message-Id: <199308271924.AA22968@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Shared libraries revisited In-Reply-To: Your message of "Fri, 27 Aug 1993 20:30:25 +0700." <9308271830.AA14949@quasi.vmars.tuwien.ac.at> Date: Fri, 27 Aug 1993 12:24:02 -0700 From: Andrew Valencia Status: OR >Well, you could share code between boot programs this way. Of course >some of them (at least the shlib server!) need to be statically linked. Well, if you do shared libraries for VSTa you can add this. But I'd strongly suggest doing this after "regular" programs are working well.... >This might be a good idea on a diskless system. It also doesn't seem to >make much difference from registering them from /etc/rc. The process >registering the shared lib may not be able to access other servers at >that time, but it could write it from its own data segment. So now you'd need some way to embed library images into an a.out. Something like "dbsym" would suffice, but... is it worth the time? There shouldn't be *that* many boot servers. In fact, my own boot.lst could stand some trimming. >Yes, but you may want different memory-protection schemes on different >portions of the shared library: Code should probably be read-only, data >copy-on-write (although shared variables might be a good idea, too). >Maybe each library should really be a directory, where each segment is >a file? You are confusing mechanism with policy. The shared library server only provides a mechanism--the provision of data, and base guarantees about its consistency. The policy of what should be read vs. read/write is up to the client. The critical one is that the file not be mapped read/write. VSTa itself forbids this, so no problem. Aside from this, why should the server care if you want to map text copy-on-write or place your data at the wrong address? >I generally think a process should not write into its own text segment. >While it may be save to do so at startup, most attemps to do so later >are probably programming errors (In these days of long pipelines and >seperate I&D caches it is increasingly difficult to write selfmodifying >code). It also prevents sharing of text pages >between processes running the same program. Yes. Sun uses mprotect() to switch access off after setup. We don't have an mprotect() (yet) so whoever does shared libraries might need to write one. Or ask me (nicely :->). >Execv writes the a.out file to the shlib-server, which will relocate it >against already registered libraries. If the relocation succeeds, the >relocated file and the shlib can be mmap'ed and exec be called. >If not, shlib will return a list of libraries. Execv will try to find >them and register them in turn (which may make it necessary to register >more libraries). After that it will again register the a.out. and exec >it. The server can discard unused excutables and shared libraries if it >runs out of space. This is starting to sound like VMS--too complex! How about: execv() uses an environment variable (remember--we have a shared namespace for environment variables, so there can be a default, a per-user, and a per-process, as needed) to find libraries. If it can't find a library, it fails. You need to look at the a.out caching VSTa currently provides. We don't want to lose this if we can help it. See kern/exec.c, especially the parts about FS_FID. It would be VERY desirable to reattach to an existing pset for the shared library segment as well as the a.out file itself. This might require FS_FID hooks in mmap() also; whoever does shared libraries will have to ponder this. The initial bringup doesn't need it (the pages are presumably still in the cache of the shlib server) but I found a definite speedup when I added a.out caching and allowed re-execv()'s to just attach to the existing pset. Andy From mod@westford.ccur.com Fri Aug 27 12:46:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18966; Fri, 27 Aug 93 12:46:41 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09326; Fri, 27 Aug 93 12:50:46 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26691(netkeeper.sj.nec.com ); Fri, 27 Aug 93 12:50:45 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02185(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 12:50:42 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA29312 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 12:42:48 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00650); Fri, 27 Aug 93 12:40:48 -0700 Received: from westford.ccur.com (masscomp.westford.ccur.com) by dirt.cisco.com with SMTP id AA29279 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 12:40:30 -0700 Received: from moe by masscomp.westford.ccur.com via TCP/IP with SMTP id aa20759; 27 Aug 93 15:37 EDT Received: from osprey by moe.westford.ccur.com via TCP/IP with SMTP (local) id aa17969; 27 Aug 93 15:40 EDT To: vsta@cisco.com Subject: AHA1542B SCSI support Date: Fri, 27 Aug 93 15:40:47 EDT From: Michael O'Donnell Message-Id: <9308271540.aa17969@moe.westford.ccur.com> Status: OR Poor me - I have been obliged to lurk on this mailing list in ReadOnly mode, taking solace from my hope that (sniff!) at least the *rest* of you are having fun. I have only an AHA1542B SCSI adaptor on my 486 box (no IDE) and I am thus prevented from running VSTa and joining the rest of you on that higher plane of consciousness. If anybody manages to get the necessary code written to allow VSTa to boot and run from an AHA1542B SCSI adaptor, please be sure to make a suitable noise on this channel. I will be spastic with gratitude for your efforts and I hope to immediately grab the sources and start making my share of trouble. Thanks. Regards, ----------------------------------------------------------------- Michael O'Donnell mod@westford.ccur.com uunet!masscomp!mod Concurrent Computer Corporation Westford, MA (508)392-2915 ----------------------------------------------------------------- P.S. Even though this posting indicates that I am sleep- deprived, I really am. From bowen!stuart@cs.ubc.ca Fri Aug 27 13:47:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19022; Fri, 27 Aug 93 13:47:12 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09480; Fri, 27 Aug 93 13:51:18 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27387(netkeeper.sj.nec.com ); Fri, 27 Aug 93 13:51:17 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02334(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 13:51:14 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA02361 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 13:40:25 -0700 Received: from dustbin.cisco.com by amri.cisco.com (AA00159); Fri, 27 Aug 93 13:36:42 -0700 Received: from grolsch.cs.ubc.ca by dustbin.cisco.com with SMTP id AA19891 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 13:36:29 -0700 Received: from cs.ubc.ca by grolsch.cs.ubc.ca with SMTP id AA20734 (5.65c/IDA-1.3.5 for dustbin.cisco.com!cisco.com!vsta); Fri, 27 Aug 1993 13:36:27 -0700 Received: from bowen.UUCP by cs.ubc.ca with UUCP id AA02248 (5.65c/IDA-1.3.5 for dustbin.cisco.com!cisco.com!vsta); Fri, 27 Aug 1993 13:36:25 -0700 Received: by bowen (NX5.67d/NX3.0M) id AA00280; Fri, 27 Aug 93 13:28:33 -0700 Date: Fri, 27 Aug 93 13:28:33 -0700 From: Stuart Ritchie Message-Id: <9308272028.AA00280@bowen> Received: by NeXT.Mailer (1.95) Received: by NeXT Mailer (1.95) To: vsta@cisco.com Subject: Re: Shared libraries revisited Status: OR Have you guys looked at the Sun's experimental microkernel, Spring? There is a set of tech reports on it, one of them describing their shared library implementation: "High Performance Dynamic Linking Though Caching." (SMLI TR-93-15). I am a little busy to go into the details now, but I will quote the abstract: "The Spring Operating System provides high performance dynamic linking of program images. Spring uses caching of both fixed-up program images and partially fixed-up shared libraries to make dynamic linking of program images efficient, to reduce the need for PIC (position indendent code), and to improve page sharing between different program images running the same libraries. The result is that with program image caching, dynamically-linked programs have a start-up cost similar to statically linked programs regardless of the number of unresolved symbols in dynamically linked program images and shared libraries. In addition, with library and program image caching, we have reduced the need for PIC and have increased page sharing." Note that these techniques are to be used in a full blown Unix microkernel environment, where 32MB DRAM is the norm. In a smaller environment like VSTa, a smaller scale implementation would probably be better. But at least this paper may provide some ideas. later, _stuart: From jrp@accint.dmc.com Fri Aug 27 16:50:48 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22633; Fri, 27 Aug 93 16:50:29 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09997; Fri, 27 Aug 93 16:54:32 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29291(netkeeper.sj.nec.com ); Fri, 27 Aug 93 16:54:27 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02878(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 16:54:23 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA10992 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 16:46:36 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00367); Fri, 27 Aug 93 16:44:22 -0700 Received: from dmc.com (HULK.DMC.COM) by dirt.cisco.com with SMTP id AA10925 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 16:43:57 -0700 Received: from accint by DMC.COM (MX V3.3 VAX) with UUCP; Fri, 27 Aug 1993 19:38:52 EST Received: by accint.dmc.com (4.1/SMI-4.1) id AA13012; Fri, 27 Aug 93 19:02:28 EDT Message-Id: <9308272302.AA13012@accint.dmc.com> To: vsta@cisco.com Subject: Re: Shared libraries revisited In-Reply-To: Your message of Fri, 27 Aug 93 18:55:42 +0700. <9308271655.AA14402@quasi.vmars.tuwien.ac.at> Date: Fri, 27 Aug 93 19:02:20 EDT From: jrp@accint.dmc.com Status: OR > * Startup times may be slow, although I don't really think so. If it > really proves to be slow, we can always put the standard libs at > fixed addresses and prerelocate the executables (I think this is > what is called `presnapping' in Primos). Not quite, you prerelocated at share time, there are no fixed addresses. So, you share libc, which gets no relocatables prelocated. Then you share libspam, which gets it's printf pointed to the one in libc. If you want to be spiffy (which you probably do), you then go back to libc's 'relocatable' table, and try to snap them to shared images. I.E. what you do is snap the links at 'share' time, to links you already know about. For example, libc relocatable (dynamic) address (stored in a pleasant structure for easy access) get replaced with fixed addresses at share time, not at link time (static links) nor at run time (normal dynamic links). This means that you take most of the startup hit when you share the library (once, at boot time, who cares about a few seconds?), instead of whenever you run a program (when everybody cares about a few seconds). > * It is not possible to override parts of a library. If you include > a different version of e.g. fprintf in your program, the library will > still use its own version. Actually I am not even sure if this is a > disadvantage :-) This sucks. This implies poor dynamicity. I've found that replacing system services with your own meta-service, which may, for instance, count occurences, or something, is *extrememly* helpful in debugging, especially so-called 'ring 3' services. So, you really want a LD_LIBRARY_PATH=/magic/path:/usr/lib. (If you want to have protection, you have a 'SYSTEM_LD_LIBRARY_PATH' (not an environment variable) which gets prepended to the LD_LIBRARY_PATH in the search list in the kernel.) Where, when you run a program, it looks at /home/jrp/mylib, then for the shared version in /magic/path, then in /usr/lib for non-shared versions. If you want to run in debug mode, you set LD_LIBRARY_PATH=/home/jrp/mylib:/usr/lib, which should then link to mylib's fprintf, overriding the one in /usr/lib. -- Jason R. Pascucci jasonp%accint.uucp@dmc.com From vandys@cisco.com Fri Aug 27 17:52:18 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22847; Fri, 27 Aug 93 17:52:17 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10211; Fri, 27 Aug 93 17:56:23 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29921(netkeeper.sj.nec.com ); Fri, 27 Aug 93 17:56:20 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02947(archimedes.inoc.sj.nec.com ); Fri, 27 Aug 93 17:56:17 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA13502 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 17:47:23 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00415); Fri, 27 Aug 93 17:45:24 -0700 Received: from localhost by glare.cisco.com with SMTP id AA06472 (5.67a/IDA-1.5 for ); Fri, 27 Aug 1993 17:45:13 -0700 Message-Id: <199308280045.AA06472@glare.cisco.com> To: jrp@accint.dmc.com Cc: vsta@cisco.com Subject: Re: Shared libraries revisited In-Reply-To: Your message of "Fri, 27 Aug 1993 19:02:20 EDT." <9308272302.AA13012@accint.dmc.com> Date: Fri, 27 Aug 1993 17:45:12 -0700 From: Andrew Valencia Status: OR >[not overriding a library call from a user's definition]... >This implies poor dynamicity. I've found that replacing >system services with your own meta-service, which may, for >instance, count occurences, or something, is *extrememly* helpful >in debugging, especially so-called 'ring 3' services. Now you've confused me. On the one hand you were indicating that relocating a library to fixed addresses at "share time" was a win. I understand this, and agree. But now you indicate that you want to override the symbols called by the library at run time. If you've already relocated the library, then presumably you've nailed down, say, fprintf()'s call to malloc() in the offered image. How do you go back and change your mind when the user's program offers a new definition for malloc() (but inherits the libc fprintf())? Do you intend to keep the original, un-relocated library around as well, and spin off a new one as needed? Your claims concerning debugging are valid, but I think they could be covered by linking a static executable. This will give you the functionality. The extra memory/a.out size is probably irrelevant for a debugging version. Andy From jont@hsa.com.au Sun Aug 29 22:23:46 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04782; Sun, 29 Aug 93 22:23:43 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17991; Sun, 29 Aug 93 22:28:10 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03047(netkeeper.sj.nec.com ); Sun, 29 Aug 93 22:28:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05176(archimedes.inoc.sj.nec.com ); Sun, 29 Aug 93 22:28:02 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA03888 (5.67a/IDA-1.5 for ); Sun, 29 Aug 1993 22:22:03 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00493); Sun, 29 Aug 93 22:21:44 -0700 Received: from warrane.connect.com.au by dirt.cisco.com with SMTP id AA03880 (5.67a/IDA-1.5 for ); Sun, 29 Aug 1993 22:21:42 -0700 Received: by warrane.connect.com.au with UUCP id AA03661 (5.67a+/IDA-1.5 for vsta@cisco.com); Mon, 30 Aug 1993 15:21:31 +1000 Received: from eccles.com.au (eccles) by hsa.hsa.com.au with SMTP id AA14416 (5.65c/IDA-1.5 for ); Sat, 28 Aug 1993 16:33:56 +1000 From: Jonathon Tidswell Message-Id: <199308280633.AA14416@hsa.hsa.com.au> Subject: list archived and other (newbie) questions To: vsta@cisco.com Date: Sat, 28 Aug 1993 16:35:40 +1000 (EST) Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1276 Status: O A few introductory questions: Is there an archive of this list ? Is there any co-ordination - who is doing what ? Is there a consensus on priority items ? - SCSI / Shared Libs / More HD support / SVGA / Networking / ... In response to a comment Andy made in the discussion on shared libraries: I agree, servers should provide mechanism not policy, however X is an ungainly bloated beast. VSTa is intended to remain multi-platform. ISA bus architecture is a dog. Is there a need for bus/BIOS/IO-port scanning in more than one program ? Obviously such a program would have to recognise many PC hardware items, however if it left its results in a couple of files /hwconf/* then the task of all other low level drivers would be simplified. Maybe it should even attempt to map out any unwanted BIOSes (all of them ? :) [ Having used their presence to help find HW devices. ] Then an Adaptec SCSI driver would merely consult this file looking for some key info. Benifits - hopefully only one program has to scan the system, which is done once ( before or after booting the OS ? ) and other drivers would need less PC knowledge in them. Problem - obviously one program is expected to KNOW a lot. regards JonT PS Now I go home and try and boot vsta ... From jrp@accint.dmc.com Sat Aug 28 21:18:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28746; Sat, 28 Aug 93 21:18:15 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14290; Sat, 28 Aug 93 21:22:32 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02585(netkeeper.sj.nec.com ); Sat, 28 Aug 93 21:22:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04269(archimedes.inoc.sj.nec.com ); Sat, 28 Aug 93 21:22:28 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA01456 (5.67a/IDA-1.5 for ); Sat, 28 Aug 1993 21:17:31 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00667); Sat, 28 Aug 93 21:16:09 -0700 Received: from dmc.com (HULK.DMC.COM) by dirt.cisco.com with SMTP id AA01428 (5.67a/IDA-1.5 for ); Sat, 28 Aug 1993 21:16:08 -0700 Received: from accint by DMC.COM (MX V3.3 VAX) with UUCP; Sat, 28 Aug 1993 15:44:30 EST Received: by accint.dmc.com (4.1/SMI-4.1) id AA16751; Sat, 28 Aug 93 15:03:51 EDT Message-Id: <9308281903.AA16751@accint.dmc.com> To: vsta@cisco.com Subject: Re: Shared libraries revisited In-Reply-To: Your message of Fri, 27 Aug 93 17:45:12 -0700. <199308280045.AA06472@glare.cisco.com> Date: Sat, 28 Aug 93 15:03:46 EDT From: jrp@accint.dmc.com Status: O >>This implies poor dynamicity. I've found that replacing >>system services with your own meta-service, which may, for >>instance, count occurences, or something, is *extrememly* helpful >>in debugging, especially so-called 'ring 3' services. > >I understand this, and agree. But now you indicate that you want >to override the symbols called by the library at run time. If Definately. >you've already relocated the library, then presumably you've nailed >down, say, fprintf()'s call to malloc() in the offered image. Yes, in the shared image. >How do you go back and change your mind when the user's program offers >a new definition for malloc() (but inherits the libc fprintf())? You don't go back. You don't run it with /magic/path in your 'search list'. (If you feel this is a major problem, maybe some linker option can specify this search path on a per-program basis.) >Do you intend to keep the original, un-relocated library around >as well, and spin off a new one as needed? Yes. All you need is one file, the 'un-relocated' library, which you prerelocate in memory at boot time. If a process wants to use this shared image (i.e. has /magic/path in their LD_LIBRARY_PATH-type variable) then it gets the post-relocated memory-resident version. If it doesn't, then it gets the 'normal' one, non-relocated, and relocates normally, based on LD_LIBRARY_PATH. (To avoid any further confusion, I will point out that if you have LD_LB_PATH=/foo/bar;/magic/path then you will load the image, snap malloc being called from the executable to /foo/bar:malloc. However, if the image calls /magic/path/libc:fprintf, which calls malloc, this one will call the standard malloc, because everything in /magic/path will have already been snapped. It's generally considered not a great thing to do as production code, which is why I don't think this is important. If you really *want* to replace a system service, then create a standard shared library, make sure you pre-load it before libc.a.) This really isn't as complicated as it sounds, I'm probably over-explaining. It's probably easier to write it than to explain the impact on all cases. :) (No, I can't volenteer...:) >Your claims concerning debugging are valid, but I think they could >be covered by linking a static executable. This will give you the >functionality. The extra memory/a.out size is probably irrelevant >for a debugging version. This assumes you have the source, not valid in any RL sense. (Consider the case of error message "Can't Find Configuration File" from a (albeit poorly written) application. Consider your delight when you trace the fopen to find that it's looking for ~/.bagbiterc.) > Andy Thinking about it, I wonder if instead of search-lists of directories, you might want to have a search-list of files, also: LD_SEARCH_PATH=/foo/bar/bang.a;/magic/path/wubba.a;/magic/path;/foo/bar Which would get bang.a first, then wubba.a, then everything in /magic/path, then everything in /foo/bar. Just a thought.... -- Jason From vandys@cisco.com Sun Aug 29 08:14:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04679; Sun, 29 Aug 93 08:14:45 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16034; Sun, 29 Aug 93 08:19:05 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05977(netkeeper.sj.nec.com ); Sun, 29 Aug 93 08:19:04 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04628(archimedes.inoc.sj.nec.com ); Sun, 29 Aug 93 08:19:02 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA10632 (5.67a/IDA-1.5 for ); Sun, 29 Aug 1993 08:14:27 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00992); Sun, 29 Aug 93 08:14:18 -0700 Received: by glare.cisco.com id AA07466 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Sun, 29 Aug 1993 08:14:22 -0700 Date: Sun, 29 Aug 1993 08:14:22 -0700 From: Andrew Valencia Message-Id: <199308291514.AA07466@glare.cisco.com> To: vsta@cisco.com Subject: VSTa shared library sub-list Status: O We're having some very productive discussion on shared libraries, but I'm concerned that it will overwhelm those who are reading the main VSTa mailing list just to keep track of developments. Therefore, I have created a new mailing list, vsta-shlib@amri.cisco.com. Please direct discussion of shared libraries there; you can continue to use vsta-request@amri.cisco.com for administrative requests. Based on my archives, I have initially taken the liberty of putting the following folks on the list. If you are not on the list, but would like to be, just send mail to vsta-request@amri.cisco.com. Members: mackinla@cs.curtin.edu.au nick@nsis.cl.nec.co.jp hp@quasi.vmars.tuwien.ac.at jrp%accint.uucp@dmc.com stuart%bowen.UUCP@cs.ubc.ca Regards... Andy Valencia From mcpapen@cip.informatik.uni-erlangen.de Mon Aug 30 02:51:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04834; Mon, 30 Aug 93 02:51:35 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18620; Mon, 30 Aug 93 02:56:03 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04839(netkeeper.sj.nec.com ); Mon, 30 Aug 93 02:56:02 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05374(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 02:55:58 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA29391 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 02:50:22 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00671); Mon, 30 Aug 93 02:50:00 -0700 Received: from faui45.informatik.uni-erlangen.de by dirt.cisco.com with SMTP id AA29319 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 02:50:10 -0700 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA05635 (5.65c-5/7.3v-FAU); Mon, 30 Aug 1993 11:49:59 +0200 Received: from faui04f.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA15908 (5.65c-5/7.3m-FAU); Mon, 30 Aug 1993 11:49:58 +0200 From: "Marc Papen (CIP 90)" Message-Id: <199308300949.AA15908@faui01.informatik.uni-erlangen.de> Subject: VSTa is up and running To: vandys@cisco.com (Andrew Valencia) Date: Mon, 30 Aug 1993 11:49:57 +0200 (MET DST) Cc: vsta@cisco.com In-Reply-To: <199308271731.AA18046@glare.cisco.com> from "Andrew Valencia" at Aug 27, 93 10:31:56 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 522 Status: O Hi all my troubles went away after installing my new WD 2340. Booting works like a charm and I can login as anybody in the passwd file. But I do have a small problem: I can't run any programs on the disk(eg. emacs gcc ...) What do I have to do to run any of this? Is there some kind of magic with it? Thanks for helping me with my problems and also for this nice new environment. Bye Marc -- Marc Papen Henkestr. 41 91054 Erlangen Germany email: mcpapen@cip.informatik.uni-erlangen.de or marc@lft.uni-erlangen.de From hp@quasi.vmars.tuwien.ac.at Mon Aug 30 03:12:30 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04839; Mon, 30 Aug 93 03:12:28 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18665; Mon, 30 Aug 93 03:16:55 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05014(netkeeper.sj.nec.com ); Mon, 30 Aug 93 03:16:54 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05385(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 03:16:51 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA06690 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 03:12:01 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00683); Mon, 30 Aug 93 03:11:40 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA06654 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 03:11:53 -0700 Received: by quasi.vmars.tuwien.ac.at id AA06387 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 30 Aug 93 12:09:41 +0200 From: Peter Holzer Message-Id: <9308301009.AA06387@quasi.vmars.tuwien.ac.at> Subject: hard disk problems To: vsta@cisco.com Date: Mon, 30 Aug 93 12:09:38 MET DST Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: O This weekend I tried to find out why VSTa didn't like my hard disk (at home -- the one in the 386 here works fine). I compiled a standalone testsh and booted. I found out that I can read any single sector on the disk with sec. But while reading the root directory for the dos fs, wd gets an error 0x10 (address mark not found) at sector 52. Since this is the first sector on its track it seems possible that multi-sector reads spanning a cylinder/head switch don't work correctly. I also noticed that seeking is extremely slow and noisy (as if it did track-by-track seeks). I compared wd to the Minix at_wini driver, but it seems to do everything the same way. hp -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From hp@quasi.vmars.tuwien.ac.at Mon Aug 30 04:27:30 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04859; Mon, 30 Aug 93 04:27:26 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18861; Mon, 30 Aug 93 04:31:54 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05479(netkeeper.sj.nec.com ); Mon, 30 Aug 93 04:31:51 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05442(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 04:31:49 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04436 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 04:27:22 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00708); Mon, 30 Aug 93 04:27:01 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA04383 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 04:27:14 -0700 Received: by quasi.vmars.tuwien.ac.at id AA08307 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 30 Aug 93 13:25:03 +0200 From: Peter Holzer Message-Id: <9308301125.AA08307@quasi.vmars.tuwien.ac.at> Subject: Re: Shared libraries revisited To: vsta@cisco.com Date: Mon, 30 Aug 93 13:25:02 MET DST Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: O You (Stuart Ritchie) wrote: > > Have you guys looked at the Sun's experimental microkernel, Spring? I thought Spring is developed by the University of Massachusetts? Jack Stankovic talked about it a few months ago here. He was concentrating on real-time issues, though. > There is a set of tech reports on it, one of them describing their > shared library implementation: "High Performance Dynamic Linking > Though Caching." (SMLI TR-93-15). I am a little busy to go into > the details now, but I will quote the abstract: Is it available by FTP somewhere? hp PS: I tried to reply directly to Stuart, but the mail bounced. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From vandys@cisco.com Mon Aug 30 07:56:43 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04909; Mon, 30 Aug 93 07:56:42 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19347; Mon, 30 Aug 93 08:01:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07343(netkeeper.sj.nec.com ); Mon, 30 Aug 93 08:01:12 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05688(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 08:01:10 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA15437 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 07:52:47 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00780); Mon, 30 Aug 93 07:49:21 -0700 Received: from localhost by glare.cisco.com with SMTP id AA21531 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 07:49:36 -0700 Message-Id: <199308301449.AA21531@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: VSTa is up and running In-Reply-To: Your message of "Mon, 30 Aug 1993 11:49:57 +0200." <199308300949.AA15908@faui01.informatik.uni-erlangen.de> Date: Mon, 30 Aug 1993 07:49:35 -0700 From: Andrew Valencia Status: O >all my troubles went away after installing my new WD 2340. Just like cars--spend $$$'s, and all your problems go away! :-) >Booting works like a charm and I can login as anybody in the passwd file. >But I do have a small problem: > I can't run any programs on the disk(eg. emacs gcc ...) >What do I have to do to run any of this? >Is there some kind of magic with it? Well, it depends on your shell. For testsh and sh, you need to do something like: path /vsta/bin:. For rc, I believe it's: path=(/vsta/bin .) although there's a compatibility hook, and: PATH=/vsta/bin:. will probably work too. Note that the DOS hard disk in the default distribution is mounted as /vsta, which means that /bin under DOS is /vsta/bin under VSTa. The init file for rc is named "init.rc", as ".rcrc" doesn't work under a DOS filesystem. Glad to hear you're booting! Andy From vandys@cisco.com Mon Aug 30 08:30:08 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04919; Mon, 30 Aug 93 08:30:06 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19425; Mon, 30 Aug 93 08:34:37 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07714(netkeeper.sj.nec.com ); Mon, 30 Aug 93 08:34:36 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05771(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 08:34:34 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA01441 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 08:26:55 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00799); Mon, 30 Aug 93 08:25:00 -0700 Received: from localhost by glare.cisco.com with SMTP id AA22818 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 08:25:07 -0700 Message-Id: <199308301525.AA22818@glare.cisco.com> To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: list archived and other (newbie) questions In-Reply-To: Your message of "Sat, 28 Aug 1993 16:35:40 +1000." <199308280633.AA14416@hsa.hsa.com.au> Date: Mon, 30 Aug 1993 08:25:06 -0700 From: Andrew Valencia Status: O >Is there an archive of this list ? Not that I know of... I collect stuff from my inbox, but I don't record what I write. >Is there any co-ordination - who is doing what ? I guess I'm the coordinator, rather by default. >Is there a consensus on priority items ? > - SCSI / Shared Libs / More HD support / SVGA / Networking / ... There's a shared library mailing list (vsta-shlib@amri.cisco.com). Several folks have shown interest in SCSI support, although to the best of my knowledge nobody is writing code yet. My "Tenex" filesystem is written and I'm in the process of bringing it up. Nick has a bitblt server running. I am not aware of any other specific development--please mail me or post to the list if you're doing something! >I agree, servers should provide mechanism not policy, however >X is an ungainly bloated beast. One of our folks is writing his own window system from scratch, with some inspiration from Plan 9's windowing system. I expect he'll be posting regarding this soon. >VSTa is intended to remain multi-platform. It has only been ported to one platform. Yes, I tried to abstract out the machine-dependent parts. >ISA bus architecture is a dog. Let's avoid simple religion and flames. I have gotten entirely too much practical work done using this architecture to write it off. Yes, it is frayed around the edges. It's cheap, fast for the price, and it happens to be what I ported VSTa to first because of this. >Is there a need for bus/BIOS/IO-port scanning in more than one program ? We don't use the BIOS; everything is native 32-bit. Coordination is done from the individual driver programs (each its own user-mode process) via registry for IRQ and DMA vectors. There is also a level of coordination provided by the namer registry for port values. There is no central, monolithic autoconfig program. In fact, individual drivers can be started and stopped as the OS runs. I envision SCSI support as being broken into the adaptor-specific part and then the SCSI command set-specific part. Each would get its own process. Thus, the same SCSI disk code would run on top of servers for Adaptec or Ultrastor adaptors. I would guess that the adaptor server would provide hints concerning what SCSI addresses on his bus were occupied. Andy From abi@hpuxsv6.cup.hp.com Mon Aug 30 08:53:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05042; Mon, 30 Aug 93 08:53:11 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19438; Mon, 30 Aug 93 08:57:42 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07945(netkeeper.sj.nec.com ); Mon, 30 Aug 93 08:57:41 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05846(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 08:57:38 -0700 Received: from hpwsabi.cup.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA03527; Mon, 30 Aug 93 08:57:26 -0700 Received: by hpuxsv6.cup.hp.com (1.37.109.4/15.5+IOS 3.20+cup+OMrelay) id AA13014; Mon, 30 Aug 93 08:56:40 -0700 From: Abraham Amirtharaj Message-Id: <9308301556.AA13014@hpuxsv6.cup.hp.com> Subject: Thought for the day To: abbie@dcsd.sj.nec.com (Abbie Matthews), sbabu@microsoft.com (P. Suresh Babu), anand@ravitech.com (Anand), Durairaj@sceng.UB.com (Krishna Kumar), Isaac@Cadence.COM (Isaac Sundarajan), vvase@starlite.Convergent.COM (Virendra Vase), samh@informix.com (Sam Hamilton), aloysius_john@tandem.com (Aloysius), abi@hpuxsv6.cup.hp.com, sjames@ingres.com (Suresh James), dsavio@ismdqa.intel.com (Dominic Savio), raju@cast.msstate.edu (Raju), lynne@dcsd.sj.nec.com (Lynne), deanna@tdd.sj.nec.com (Deanna Amodeo), chrisc@hpindbu.cup.hp.com (Chris), shian@dcsd.sj.nec.com, liu@dcsd.sj.nec.com, pradeep@dcsd.sj.nec.com, rachel@dcsd.sj.nec.com, davids@comu2.auckland.ac.nz, kumar@actel.com (David Kumar), pok@sceng.UB.com (Pok), manchala@cs.tamu.edu (Daniel) Date: Mon, 30 Aug 93 8:56:38 PDT Mailer: Elm [revision: 70.85] Status: O #include <1 Corinthians 12:12-27> The Christian who pulls on the oars has no time to rock the boat. From hp@petrus.vmars.tuwien.ac.at Mon Aug 30 08:56:06 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05047; Mon, 30 Aug 93 08:56:05 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19443; Mon, 30 Aug 93 09:00:36 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08034(netkeeper.sj.nec.com ); Mon, 30 Aug 93 09:00:35 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05854(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 09:00:32 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA02924 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 08:53:45 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00811); Mon, 30 Aug 93 08:51:08 -0700 Received: from petrus.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA02724 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 08:51:20 -0700 Received: by petrus.vmars.tuwien.ac.at id AA05608 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 30 Aug 93 17:49:09 +0200 From: Peter Holzer Message-Id: <9308301549.AA05608@petrus.vmars.tuwien.ac.at> Subject: Re: list archived and other (newbie) questions To: vsta@cisco.com Date: Mon, 30 Aug 93 17:49:08 MET DST In-Reply-To: <199308301525.AA22818@glare.cisco.com>; from "Andrew Valencia" at Aug 30, 93 8:25 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: O You (Andrew Valencia) wrote: > > >Is there an archive of this list ? > > Not that I know of... I collect stuff from my inbox, but I don't > record what I write. I record both. I just copied the archive to /pub/VSTa/log.vsta. I'll update it regularly, but don't expect it to be up-to-date all the time (Although elm's filter should be able to do this automatically -- time to read the man page :-) hp -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From hp@quasi.vmars.tuwien.ac.at Mon Aug 30 09:12:34 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05055; Mon, 30 Aug 93 09:12:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19458; Mon, 30 Aug 93 09:17:04 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08154(netkeeper.sj.nec.com ); Mon, 30 Aug 93 09:17:03 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05869(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 09:17:00 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04001 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 09:09:41 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00085); Mon, 30 Aug 93 09:06:51 -0700 Received: from quasi.vmars.tuwien.ac.at by dirt.cisco.com with SMTP id AA03284 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 08:58:37 -0700 Received: by quasi.vmars.tuwien.ac.at id AA14556 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 30 Aug 93 17:56:24 +0200 From: Peter Holzer Message-Id: <9308301556.AA14556@quasi.vmars.tuwien.ac.at> Subject: Re: list archived and other (newbie) questions To: vsta@cisco.com Date: Mon, 30 Aug 93 17:56:23 MET DST In-Reply-To: <199308301555.AA24757@glare.cisco.com>; from "Andrew Valencia" at Aug 30, 93 8:55 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: O You (Andrew Valencia) wrote: > > >I record both. I just copied the archive to /pub/VSTa/log.vsta. > >I'll update it regularly, but don't expect it to be up-to-date all the > >time (Although elm's filter should be able to do this automatically -- > >time to read the man page :-) > > Could you also supply a host name and IP address? I tried the > obvious ones based on your return-address, and had no luck. Oops, sorry: ftp.vmars.tuwien.ac.at (128.130.39.16) -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From jyl@toss.Eng.Sun.COM Mon Aug 30 10:50:29 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05203; Mon, 30 Aug 93 10:50:27 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19529; Mon, 30 Aug 93 10:54:58 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00805(netkeeper.sj.nec.com ); Mon, 30 Aug 93 10:54:57 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06124(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 10:54:54 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA21933 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 10:48:33 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00123); Mon, 30 Aug 93 10:46:47 -0700 Received: from Sun.COM by dirt.cisco.com with SMTP id AA19180 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 10:47:06 -0700 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09490; Mon, 30 Aug 93 10:47:04 PDT Received: from toss.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28757; Mon, 30 Aug 93 10:47:58 PDT Received: from burgess.Eng.Sun.COM by toss.Eng.Sun.COM (4.1/SMI-4.1) id AA27980; Mon, 30 Aug 93 10:47:01 PDT Date: Mon, 30 Aug 93 10:47:01 PDT From: jyl@toss.Eng.Sun.COM (Jacob Levy) Message-Id: <9308301747.AA27980@toss.Eng.Sun.COM> Received: by burgess.Eng.Sun.COM (4.1/SMI-4.1) id AA17046; Mon, 30 Aug 93 10:48:55 PDT To: vsta@cisco.com Subject: How to obtain Spring technical reports Reply-To: jyl@toss.Eng.Sun.COM Status: OR Since there's been some interest in the Spring OS work done at Sun Microsystems, I thought I'd post how people can obtain copies of the publicly available papers. Here goes: To get hold of hardcopy versions of the Spring technical reports, send email with your postal address to "spring-reports@smli.eng.sun.com". We will happily mail you the complete set, and also add you to our mailing list for future reports. Reports currently available include: "An Implementation of Unix on an Object-oriented Operating System", Y. A. Khalidi & M. N. Nelson "The Spring Virtual Memory System", Y. A. Khalidi & M. N. Nelson "The Spring File System", M. N. Nelson, Y. A. Khalidi & P. W. Madany "Subcontract: A Flexible Base for Distributed Programming", G. Hamilton, M. L. Powell, J. G. Mitchell "The Spring Nucleus: A Microkernel for Objects", G. Hamilton & P. Kougiouris "High Performance Dynamic Linking Through Caching", M. N. Nelson & G. Hamilton There are other reports in preparation on naming, stackable filesystems, and caching frameworks. Sorry, but at the moment postscript isn't available. (However, we do plan in the future to set up anonymous ftp access for the report series.) --JYL From vandys@cisco.com Mon Aug 30 15:55:47 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08579; Mon, 30 Aug 93 15:55:46 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20760; Mon, 30 Aug 93 16:00:20 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04586(netkeeper.sj.nec.com ); Mon, 30 Aug 93 16:00:19 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07010(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 16:00:17 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA24293 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 15:53:03 -0700 Received: from barley.cisco.com by amri.cisco.com (AA00233); Mon, 30 Aug 93 15:48:58 -0700 Received: by barley.cisco.com id AA14429 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Mon, 30 Aug 1993 15:49:15 -0700 Date: Mon, 30 Aug 1993 15:49:15 -0700 From: Andrew Valencia Message-Id: <199308302249.AA14429@barley.cisco.com> To: vsta@cisco.com Subject: pat.6 Status: OR This patch fixes a problem where your waits() (and functions based on it, including all the POSIX process-waiting interfaces like waitpid()) will block even though you've specified non- blocking. *** c:/tmp/T0AA.AAA Mon Aug 30 15:48:24 1993 --- mach/syscall.c Mon Aug 30 15:45:10 1993 *************** *** 52,64 **** {page_release, 1}, /* 19 */ {enable_dma, 0}, /* 20 */ {time_get, 1}, /* 21 */ {time_sleep, 1}, /* 22 */ {do_dbg_enter, 0}, /* 23 */ {exec, 3}, /* 24 */ ! {waits, 1}, /* 25 */ {perm_ctl, 3}, /* 26 */ {set_swapdev, 1}, /* 27 */ {run_qio, 0}, /* 28 */ {set_cmd, 1}, /* 29 */ {pageout, 0}, /* 30 */ {getid, 1}, /* 31 */ --- 52,64 ---- {page_release, 1}, /* 19 */ {enable_dma, 0}, /* 20 */ {time_get, 1}, /* 21 */ {time_sleep, 1}, /* 22 */ {do_dbg_enter, 0}, /* 23 */ {exec, 3}, /* 24 */ ! {waits, 2}, /* 25 */ {perm_ctl, 3}, /* 26 */ {set_swapdev, 1}, /* 27 */ {run_qio, 0}, /* 28 */ {set_cmd, 1}, /* 29 */ {pageout, 0}, /* 30 */ {getid, 1}, /* 31 */ From vandys@cisco.com Mon Aug 30 19:04:38 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13715; Mon, 30 Aug 93 19:04:34 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21098; Mon, 30 Aug 93 19:09:08 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07105(netkeeper.sj.nec.com ); Mon, 30 Aug 93 19:09:07 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07483(archimedes.inoc.sj.nec.com ); Mon, 30 Aug 93 19:09:06 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA12573 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 19:03:53 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00325); Mon, 30 Aug 93 19:02:31 -0700 Received: from localhost by glare.cisco.com with SMTP id AA02343 (5.67a/IDA-1.5 for ); Mon, 30 Aug 1993 19:02:53 -0700 Message-Id: <199308310202.AA02343@glare.cisco.com> To: vsta@cisco.com Subject: vstafs bringup Date: Mon, 30 Aug 1993 19:02:53 -0700 From: Andrew Valencia Status: OR Well, just tonight: Welcome to VSTa v1.0! login: vandys password: ********* Welcome, vandys ; testsh % cd /vsta/vsta/vstafs New dir: /vsta/vsta/vstafs % path . % run vstafs fstest fs/vfs & 24 & vfs mount fs/vfs 2000 sectors 1 free extents, longest 1997 sectors % cd /namer/fs New dir: /namer/fs % ls pipe tmp root vfs % cat vfs 1028% mount 1028 /vfs % cd /vfs New dir: /vfs % cat > x foob % ls x % ls -l x: size=5, type=f, owner=1, inode=3, perm=3/1, acc=0/0/70 % cat x foob % So my filesystem is limping to life! This sequence also shows you how to fire up filesystems on demand, and mount them into your pathname space. I'm currently running against a 1 meg DOS file, instead of a disk partition. It spares me having to juggle disk partitions. Now all that's left to test is file versioning, contiguous allocation, multiple extents, free list balancing, subdirectories, file deletion, and probably large files. :-) Andy From mcpapen@cip.informatik.uni-erlangen.de Tue Aug 31 04:14:39 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16732; Tue, 31 Aug 93 04:14:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21516; Tue, 31 Aug 93 04:19:10 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12009(netkeeper.sj.nec.com ); Tue, 31 Aug 93 04:19:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08014(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 04:19:06 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA04986 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 04:11:05 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00602); Tue, 31 Aug 93 04:09:00 -0700 Received: from faui45.informatik.uni-erlangen.de by dirt.cisco.com with SMTP id AA01032 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 04:09:21 -0700 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA18466 (5.65c-5/7.3v-FAU); Tue, 31 Aug 1993 13:09:13 +0200 Received: from faui04f.informatik.uni-erlangen.de by cip.informatik.uni-erlangen.de with SMTP; id AA26421 (5.65c-5/7.3m-FAU); Tue, 31 Aug 1993 13:09:11 +0200 From: "Marc Papen (CIP 90)" Message-Id: <199308311109.AA26421@faui01.informatik.uni-erlangen.de> Subject: Is anybody working on extending libc?(and other questions) To: vandys@cisco.com (Andrew Valencia) Date: Tue, 31 Aug 1993 13:09:10 +0200 (MET DST) Cc: vsta@cisco.com In-Reply-To: <199308310202.AA02343@glare.cisco.com> from "Andrew Valencia" at Aug 30, 93 07:02:53 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 648 Status: OR Now that I'm up and running I was thinking about porting some tools to VSTa. I tried to compile a make for native VSTa but there are some things missing in libc. Is anybody working on extending libc? If not, I'd be willing to do so.(I don't have this much experience in writing libs but I got the Posix Programmer's manual and would like to implement the missing features) Also I'd like to work on CD-ROM IS9660 Filessystem and a driver for my Soundblaster CD-ROM. Please tell me what you think about it. Bye Marc -- Marc Papen Henkestr. 41 91054 Erlangen Germany email: mcpapen@cip.informatik.uni-erlangen.de or marc@lft.uni-erlangen.de From vandys@cisco.com Tue Aug 31 08:15:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19679; Tue, 31 Aug 93 08:15:55 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21664; Tue, 31 Aug 93 08:20:35 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA14710(netkeeper.sj.nec.com ); Tue, 31 Aug 93 08:20:34 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08570(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 08:20:32 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA13219 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 08:13:20 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00080); Tue, 31 Aug 93 08:10:45 -0700 Received: from localhost by glare.cisco.com with SMTP id AA13774 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 08:11:15 -0700 Message-Id: <199308311511.AA13774@glare.cisco.com> To: "Marc Papen (CIP 90)" Cc: vsta@cisco.com Subject: Re: Is anybody working on extending libc?(and other questions) In-Reply-To: Your message of "Tue, 31 Aug 1993 13:09:10 +0200." <199308311109.AA26421@faui01.informatik.uni-erlangen.de> Date: Tue, 31 Aug 1993 08:11:15 -0700 From: Andrew Valencia Status: OR Nick did some more C library routines--memXXX() and strXXX() ones, if I recall correctly. You're welcome to submit more routines; I ask that you supply them as patches for existing files (don't forget prototypes for the .h!) and new files in their entirety. We're trying to keep coding styles aligned on a per-subsystem basis. I've recently written a document which is basically Henry Spencer's "10 Rules of C" followed by some explicit examples. If you're not familiar with this style of coding, I can forward you a copy of the document. Plus or minus my own fallibility, the current kernel and library code should also be useful as a guide. >Now that I'm up and running I was thinking about porting some tools to >VSTa. I tried to compile a make for native VSTa but there are some things >missing in libc. Is anybody working on extending libc? >If not, I'd be willing to do so.(I don't have this much experience in >writing libs but I got the Posix Programmer's manual and would like to >implement the missing features) >Also I'd like to work on CD-ROM IS9660 Filessystem and a driver for my >Soundblaster CD-ROM. Soundblaster uses a proprietary SCSI interface, I believe. Unless they've changed their policy recently, I don't think they want to document the board-level registers. They just want you to buy a DOS driver. :-( If you buy a PAS-16 instead I have a contact at MediaVision who can supply technical documentation on their SCSI port instead. Until we have a SCSI driver of some sort a CDROM filesystem driver would not be worth writing, since you'd have no way to test it! Andy From mackinla@cs.curtin.edu.au Tue Aug 31 08:53:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19704; Tue, 31 Aug 93 08:53:15 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21699; Tue, 31 Aug 93 08:57:55 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15253(netkeeper.sj.nec.com ); Tue, 31 Aug 93 08:57:53 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08686(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 08:57:50 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA21011 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 08:49:53 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00112); Tue, 31 Aug 93 08:47:27 -0700 Received: from marsh.cs.curtin.edu.au by dirt.cisco.com with SMTP id AA17159 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 08:47:47 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA15227 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 23:48:21 +0800 Received: by lillee.cs.curtin.edu.au id AA05955 (5.67a/IDA-1.4.4 for vsta@cisco.com); Tue, 31 Aug 1993 23:48:20 +0800 From: Pat Mackinlay Message-Id: <199308311548.AA05955@lillee.cs.curtin.edu.au> Subject: Re: Is anybody working on extending libc?(and other questions) To: vandys@cisco.com (Andrew Valencia) Date: Tue, 31 Aug 1993 23:47:38 +0800 (WST) In-Reply-To: <199308311511.AA13774@glare.cisco.com> from "Andrew Valencia" at Aug 31, 93 08:11:15 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2032 Sender: mackinla@cs.curtin.edu.au Status: OR > We're trying to keep coding styles aligned on a per-subsystem basis. > I've recently written a document which is basically Henry Spencer's > "10 Rules of C" followed by some explicit examples. If you're not > familiar with this style of coding, I can forward you a copy of the > document. Plus or minus my own fallibility, the current kernel and > library code should also be useful as a guide. This shouldn't really be going to the list, I suppose, but firstly, I'm still here - just swamped with real work. I would like a copy of that document if you wouldn't mind Andy. Just so everyone knows, when I get a bit of time, I'll be making a serious attempt at dmake. This will very likely require some substantial additions to the libc. > >Also I'd like to work on CD-ROM IS9660 Filessystem and a driver for my > >Soundblaster CD-ROM. > > Soundblaster uses a proprietary SCSI interface, I believe. Unless > they've changed their policy recently, I don't think they want to document > the board-level registers. They just want you to buy a DOS driver. :-( Actually, someone must have squeezed the information out of Creative Labs because Linux (what else, ) has a driver for the SB CD... This would very likely make a useful guide. Isn't it nice that all this has been done before . I suspect the Linux kernel is going to become the definitive reference for programming PC hardware... > Until we have a SCSI driver of some sort a CDROM filesystem driver would > not be worth writing, since you'd have no way to test it! As above, drivers for most non-SCSI CDROM drives exist for Linux, so it's quite possible to write them without any sticky NDAs. One final question: how do I get DOS RCS to put a patch in for me? The only way I've been able to patch VSTa is by running patch manually under Linux - not an optimal solution... Pat -- "There's only one thing left to do Mama, I got to ding a ding dang my dang a long ling long" (Jesus Built My Hotrod -- Ministry) GCS d* -p+ c++ l++ m--- s+/- !g w- t- r From mackinla@cs.curtin.edu.au Tue Aug 31 09:13:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19736; Tue, 31 Aug 93 09:13:31 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21755; Tue, 31 Aug 93 09:18:11 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15555(netkeeper.sj.nec.com ); Tue, 31 Aug 93 09:18:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08771(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 09:18:06 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA28006 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 09:09:23 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00123); Tue, 31 Aug 93 09:06:26 -0700 Received: from marsh.cs.curtin.edu.au by dirt.cisco.com with SMTP id AA23676 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 09:06:53 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA15406 (5.67a/IDA-1.5); Wed, 1 Sep 1993 00:07:25 +0800 Received: by lillee.cs.curtin.edu.au id AA06039 (5.67a/IDA-1.4.4); Wed, 1 Sep 1993 00:07:24 +0800 From: Pat Mackinlay Message-Id: <199308311607.AA06039@lillee.cs.curtin.edu.au> Subject: Stuff... To: vandys@cisco.com (Andrew Valencia) Date: Wed, 1 Sep 1993 00:07:24 +0800 (WST) Cc: vsta@cisco.com In-Reply-To: <199308311551.AA15620@glare.cisco.com> from "Andrew Valencia" at Aug 31, 93 08:51:39 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1712 Status: OR > In fact, I think I'll put a copy on the FTP site. Ok, thanks for that. > I took a quick look at dmake. It didn't look *too* bad. Nothing like > GNU make where I would have to implement select() or anything! No, it looks ok to me too. There are bound to be some small things missing though... We'll see. What's your policy on releases? If/when I get the thing compiled and working, should I just make a single tar with source and binaries? > >before . I suspect the Linux kernel is going to become the definitive > >reference for programming PC hardware... > > What a pity that all that has to go in the *kernel*, though! My goal > will always be to have NONE of it in the kernel. There's too much of > it, so don't put it where you would have to trust it! :-) Oh, for sure. The point stands though - however the source is arranged, it still holds as good documentation on all that wacky hardware that's available for the PC. > >One final question: how do I get DOS RCS to put a patch in for me? The > >only way I've been able to patch VSTa is by running patch manually under > >Linux - not an optimal solution... > > Patch should've come with your DJ Delorie package. If not, I can put > my .exe on the FTP location. Yeah, I have patch, but there was some problem actually trying to get it to go in. I forget the exact problem now, but I think it was to do with RCS. That is, you want RCS to check the files out before trying to patch them... Is there some rcs command that will take a patchfile and apply it? Pat -- "There's only one thing left to do Mama, I got to ding a ding dang my dang a long ling long" (Jesus Built My Hotrod -- Ministry) GCS d* -p+ c++ l++ m--- s+/- !g w- t- r From vandys@cisco.com Tue Aug 31 10:28:50 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20397; Tue, 31 Aug 93 10:28:48 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00409; Tue, 31 Aug 93 10:33:29 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08035(netkeeper.sj.nec.com ); Tue, 31 Aug 93 10:33:28 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09013(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 10:33:25 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA27184 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 10:27:50 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00166); Tue, 31 Aug 93 10:25:36 -0700 Received: from localhost by glare.cisco.com with SMTP id AA22908 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 10:26:06 -0700 Message-Id: <199308311726.AA22908@glare.cisco.com> To: vsta@cisco.com Subject: C style documentation Date: Tue, 31 Aug 1993 10:26:05 -0700 From: Andrew Valencia Status: OR I've put two documents on ftp.cisco.com:vandys/vsta: ten.doc - Henry Spencer's classic text coding.txt - A little amplification by myself Coding style discussions always end in a lot of angry people. Please send complaints/comments directly to me. I would really prefer that our mailing list not be consumed with the inevitable shouting match. Remember, the rules are per subsystem--I picked some "classic" rules for the kernel, library, and primary servers. Nick is picking his own set for the window manager. Networking servers could pick their own as well. I want uniformity within a subsystem, but I think distinct sets of code should be able to pick the style which works best for them. Andy From miguel@roxanne.nuclecu.unam.mx Tue Aug 31 19:26:38 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24118; Tue, 31 Aug 93 19:26:37 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01207; Tue, 31 Aug 93 19:31:21 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA14951(netkeeper.sj.nec.com ); Tue, 31 Aug 93 19:31:20 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA10456(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 19:31:18 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA11269 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 19:24:02 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00352); Tue, 31 Aug 93 19:22:45 -0700 Received: from roxanne.nuclecu.unam.mx by dirt.cisco.com with SMTP id AA09043 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 19:23:13 -0700 Received: by roxanne.nuclecu.unam.mx (5.65/Ultrix3.0-C) id AA21406; Tue, 31 Aug 1993 20:23:54 -0600 Date: Tue, 31 Aug 1993 20:23:54 -0600 From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza) Message-Id: <9309010223.AA21406@roxanne.nuclecu.unam.mx> To: vsta@cisco.com In-Reply-To: <199308311726.AA22908@glare.cisco.com> (message from Andrew Valencia on Tue, 31 Aug 1993 10:26:05 -0700) Subject: Re: C style documentation Status: OR Would it be possible to have a message handled by the kernel to go back to real mode and execute some code there? This way we could write a server for real-mode hard disk access and use all the hardware that we have while the drivers get developed? Miguel. From vandys@cisco.com Tue Aug 31 22:30:48 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24173; Tue, 31 Aug 93 22:30:47 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01282; Tue, 31 Aug 93 22:35:32 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16697(netkeeper.sj.nec.com ); Tue, 31 Aug 93 22:35:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA10646(archimedes.inoc.sj.nec.com ); Tue, 31 Aug 93 22:35:29 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA13112 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 22:25:19 -0700 Received: from [131.108.11.56] by amri.cisco.com (AA00386); Tue, 31 Aug 93 20:55:30 -0700 Received: from localhost by glare.cisco.com with SMTP id AA25082 (5.67a/IDA-1.5 for ); Tue, 31 Aug 1993 20:55:56 -0700 Message-Id: <199309010355.AA25082@glare.cisco.com> To: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza) Cc: vsta@cisco.com Subject: Re: C style documentation In-Reply-To: Your message of "Tue, 31 Aug 1993 20:23:54 MDT." <9309010223.AA21406@roxanne.nuclecu.unam.mx> Date: Tue, 31 Aug 1993 20:55:55 -0700 From: Andrew Valencia Status: OR >Would it be possible to have a message handled by the kernel to go >back to real mode and execute some code there? It is interesting to note that, unlike Plan 9, the microkernel currently does not respond to any messages. It passes them on to a server, but the kernel does not contain any code which *acts* as a server. I was rather surprised when I finished writing the message handling code at how un-natural it would be to bolt kernel handling onto the messaging code. I decided to run with my first impression. So far, it's done OK. >This way we could write a server for real-mode hard disk access and >use all the hardware that we have while the drivers get developed? There would be real challenges. ALL memory has been taken over by VSTa, so you have no real guarantees that you can assemble a workable environment in which to run a card's BIOS. Lots of problems with interrupts and the like. It's something of a pain to wander back and forth from protected mode to real mode, too. When I was first writing VSTa, I pondered long and hard on how to get myself bootstrapped. I decided that the best way to keep access to all my hardware was to cross-compile from another OS. I chose DOS because it's easy to take the machine over once you've generated an image. The djgpp compiler is full GCC 2.X, there are lots of very reasonable editors for DOS, and a boot into VSTa takes ~10 seconds. You don't need a disk driver to boot VSTa; comment out the dos filesystem, the disk drivers, and init. Add back in a -DSTAND version of testsh, and you can talk to the tmp filesystem, namer, etc. without any hard disk storage at all! As you write a disk driver you can boot up VSTa and talk to your driver via testsh. This is how I brought up VSTa, and it works pretty well. As you saw from my status message last night it's still pretty much how I work, except that I now have the luxury of using a DOS file as my "disk" for testing instead of having to use a real disk. When we have dmake and RCS ported it should be possible to entirely self-host the development process. For the foreseeable future I want to continue to support DOS cross-compilations for situations exactly like yours. Regards, Andy From myl@genrad.com Wed Sep 1 06:57:59 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06229; Wed, 1 Sep 93 06:57:57 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01683; Wed, 1 Sep 93 07:02:46 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21404(netkeeper.sj.nec.com ); Wed, 1 Sep 93 07:02:45 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11168(archimedes.inoc.sj.nec.com ); Wed, 1 Sep 93 07:02:44 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA27684 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 06:54:11 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00684); Wed, 1 Sep 93 06:50:13 -0700 Received: from genrad.com (genrad.genrad.com) by dirt.cisco.com with SMTP id AA27618 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 06:50:47 -0700 Received: by genrad.com (5.57) id AA17711; Wed, 1 Sep 93 09:50:37 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA08898; Wed, 1 Sep 93 09:50:35 EDT Date: Wed, 1 Sep 93 09:50:35 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309011350.AA08898@bronco.genrad.com> To: vsta@cisco.com Subject: adding support for logical partitions to wd Status: OR Hi, I would like to add support for msdos logical partitions to wd. Here's the way I currently have my hard disk partitioned: type start finish size ------- ----- ------ ---- c: PRI DOS 0 256 257 EXT DOS 257 914 658 (the numbers are from memory, so they may be slightly off). Within the extended partition, I have 3 logical partitions: start finish size ----- ------ ---- d: 257 513 257 e: 514 770 257 f: 771 914 144 It appears that the partition table that resides on block 0 contains a partition information for the primary and extended dos partitions, while each logical partition has a partition table of its own. The question is: what is the best way to modify wd to: 1) read partition tables from blocks other than block 0? 2) read multiple partition tables per unit (hard disk)? It appears that wd only looks for boot information in sector 0. Also, init_part() gets a buffer containing boot sector passed to it. To support logical msdos partitions, it would be nice if init_part() could (synchronously) read sectors itself. Suggestions? Best Regards, Mike Larson From vandys@cisco.com Wed Sep 1 07:59:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06304; Wed, 1 Sep 93 07:59:52 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01749; Wed, 1 Sep 93 08:04:40 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22207(netkeeper.sj.nec.com ); Wed, 1 Sep 93 08:04:39 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11335(archimedes.inoc.sj.nec.com ); Wed, 1 Sep 93 08:04:37 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA29580 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 07:56:17 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00079); Wed, 1 Sep 93 07:52:56 -0700 Received: from localhost by glare.cisco.com with SMTP id AA09535 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 07:40:31 -0700 Message-Id: <199309011440.AA09535@glare.cisco.com> To: myl@genrad.com (Michael A. Larson) Cc: vsta@cisco.com Subject: Re: adding support for logical partitions to wd In-Reply-To: Your message of "Wed, 01 Sep 1993 09:50:35 EDT." <9309011350.AA08898@bronco.genrad.com> Date: Wed, 01 Sep 1993 07:40:31 -0700 From: Andrew Valencia Status: OR >It appears that the partition table that resides on block 0 contains a >partition information for the primary and extended dos partitions, >while each logical partition has a partition table of its own. Aha! Yes, I knew that DOS had added a further layer of partitioning, but all my manuals date from when the AT was the newest kid on the block. I couldn't find anything to deal with it in 386BSD or Minix either, so I just let it slide. If you understand this stuff, it would be good to teach it to VSTa. Maybe in wd, maybe somewhere else. More on this in a second. >It appears that wd only looks for boot information in sector 0. Also, >init_part() gets a buffer containing boot sector passed to it. To >support logical msdos partitions, it would be nice if init_part() could >(synchronously) read sectors itself. If I understand what you're implying, logical partitions under an extended partition use the same format as the boot sector for the disk? Now this is getting crazy, but can an extended partition hold an extended partition? That is, is this arbitrarily recursive, or bounded for a depth of two? What I would do is break out the part which walks through a block describing partitions, and make it a standalone routine. Then call this routine once for the boot block, and once again for each extended partition. Arguments to the routine would need to include a prefix string, the sector buffer, a pointer to a struct disk, and a count of struct disk's available. Once you have this working, consider moving the interpretation stuff over to lib/libusr.a. We eventually will have other hard disk drivers, and it would be nice to share this code among all of them. Andy From myl@genrad.com Wed Sep 1 11:34:00 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07774; Wed, 1 Sep 93 11:33:59 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02074; Wed, 1 Sep 93 11:38:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16561(netkeeper.sj.nec.com ); Wed, 1 Sep 93 11:38:48 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11906(archimedes.inoc.sj.nec.com ); Wed, 1 Sep 93 11:38:44 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA09801 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 11:31:51 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00158); Wed, 1 Sep 93 11:29:34 -0700 Received: from genrad.com (genrad.genrad.com) by dirt.cisco.com with SMTP id AA09732 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 11:30:13 -0700 Received: by genrad.com (5.57) id AA02215; Wed, 1 Sep 93 14:29:57 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA09049; Wed, 1 Sep 93 13:25:39 EDT Date: Wed, 1 Sep 93 13:25:39 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309011725.AA09049@bronco.genrad.com> To: vsta@cisco.com Subject: Re: adding support for logical partitions to wd Status: OR Andy, > .... If you understand this stuff, it would be good to > teach it to VSTa. Maybe in wd, maybe somewhere else. More on this in > a second. Well, one of the DOS programming books that have just touches on this subject. Beyond that, I just dumped a number of sectors. What I saw seemed to be reasonable - it looked like the extended partition did in fact have 3 logical partitions and one logical partition began just after the previous one ended. I'll try to find a better source of information for this. > If I understand what you're implying, logical partitions under an extended > partition use the same format as the boot sector for the disk? Now this is > getting crazy, but can an extended partition hold an extended partition? > That is, is this arbitrarily recursive, or bounded for a depth of two? I don't think the scheme is recursive. The extended partition can contain one or more logical partitions, and that's it. > What I would do is break out the part which walks through a block > describing partitions, and make it a standalone routine. Then call > this routine once for the boot block, and once again for each extended > partition. > Arguments to the routine would need to include a prefix string, the sector > buffer, a pointer to a struct disk, and a count of struct disk's available. > Once you have this working, consider moving the interpretation stuff over > to lib/libusr.a. We eventually will have other hard disk drivers, and > it would be nice to share this code among all of them. Ok, I'll try this. Mike Larson From vandys@cisco.com Wed Sep 1 12:54:12 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07958; Wed, 1 Sep 93 12:54:11 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02587; Wed, 1 Sep 93 12:59:01 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17693(netkeeper.sj.nec.com ); Wed, 1 Sep 93 12:59:00 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA12164(archimedes.inoc.sj.nec.com ); Wed, 1 Sep 93 12:58:57 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA13919 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 12:51:56 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00188); Wed, 1 Sep 93 12:49:41 -0700 Received: from localhost by glare.cisco.com with SMTP id AA26541 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 12:50:24 -0700 Message-Id: <199309011950.AA26541@glare.cisco.com> To: vsta@cisco.com Subject: Some approachable projects for VSTa Date: Wed, 01 Sep 1993 12:50:24 -0700 From: Andrew Valencia Status: OR Some folks have wondered privately if there are only big, scary projects like shared libraries to be undertaken. Not at all! Here's a list of relatively approachable projects which will still be heartily welcomed (and are very much needed!): - Teach the DOS filesystem about date and time stamps for the files and directories it creates. - Flesh out VST'a date/time handling. First thing is to have a program which extracts the date/time from the PC's NVRAM. Next is to have it massage into a convenient format and feed to the kernel. - Enhance "ls". It currently only knows how to dump entries within a directory. Its output format is questionable. It needs all sorts of sorting options. You might want to try porting the GNU version of ls instead. You will still have to enhance it to understand the protection labels VSTa uses. - Port any of the file handling utilities. cat, awk, dd, od, sed, pr, bc, cal, sleep, sort, col, cpio, tar, etc. - Port the vim editor. A great clone of vi! Already has code for System V-ish systems, so the TTY stuff shouldn't be too bad. - Test events. I wrote the stuff, but its testing has been minimal. Events are the kinda-sorta equivalent of UNIX signals. This will probably get you familiar with the kernel debugger! :-) They need to be tested for both killing of processes as well as event handlers. Regards... Andy From nick@nsis.cl.nec.co.jp Wed Sep 1 16:22:21 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09347; Wed, 1 Sep 93 16:22:18 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03703; Wed, 1 Sep 93 16:27:08 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21459(netkeeper.sj.nec.com ); Wed, 1 Sep 93 16:27:07 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA12979(archimedes.inoc.sj.nec.com ); Wed, 1 Sep 93 16:27:05 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA26792 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 16:19:10 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00276); Wed, 1 Sep 93 16:16:18 -0700 Received: from TYO.gate.nec.co.jp by dirt.cisco.com with SMTP id AA26730 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 16:16:59 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA03848; Thu, 2 Sep 1993 08:16:55 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA10948; Thu, 2 Sep 1993 08:16:53 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-93930818.1) id AA19551; Thu, 2 Sep 1993 08:16:52 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA09108; Thu, 2 Sep 93 08:16:50 JST Date: Thu, 2 Sep 93 08:16:50 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309012316.AA09108@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Wed, 01 Sep 1993 07:40:31 -0700 <199309011440.AA09535@glare.cisco.com> Subject: adding support for logical partitions to wd Status: OR I believe that Linux and/or 386BSD support extended partitions. At least in the pc9801 version for one of these I've seen the code for dealing with them. If you don't find anything else, I'll see if I can dig it up. nick From jont@hsa.com.au Thu Sep 2 01:34:58 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10797; Thu, 2 Sep 93 01:34:45 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04368; Thu, 2 Sep 93 01:39:39 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27453(netkeeper.sj.nec.com ); Thu, 2 Sep 93 01:39:38 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13933(archimedes.inoc.sj.nec.com ); Thu, 2 Sep 93 01:39:31 -0700 Received: from amri.cisco.com by dirt.cisco.com with SMTP id AA13687 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 01:22:12 -0700 Received: from dirt.cisco.com by amri.cisco.com (AA00455); Thu, 2 Sep 93 01:19:51 -0700 Received: from warrane.connect.com.au by dirt.cisco.com with SMTP id AA13670 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 01:20:15 -0700 Received: by warrane.connect.com.au with UUCP id AA13263 (5.67a+/IDA-1.5 for vsta@cisco.com); Thu, 2 Sep 1993 18:19:42 +1000 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA14805 (5.65c/IDA-1.5 for ); Thu, 2 Sep 1993 18:14:47 +1000 From: Jonathon Tidswell Message-Id: <199309020814.AA14805@hsa.hsa.com.au> Subject: ELF binaries and shlibs To: vsta@cisco.com Date: Thu, 2 Sep 1993 18:11:21 +1000 (EST) Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3038 Status: OR The background is that the Linux community is working to support the ELF binary file format, and that most of this code is available, GPL or otherwise. Eric Youngdale wrote in response to a question from me to the Linux intel binary compatability list: > > >Is there an Electronic spec of ELF ? > > Not that I am aware of. > > >I am under the impression that people think shared libraries will be easier > >under ELF than currently ? > >Is this a total misconception ? > > Yes, I believe that it will be easier. > > >I thought ELF was a file format, or is it that iBSC2 support requires new > >syscalls (likely) and that ELF indicates an origin (SVID3) and hence is used > >as an indirect indicator of which syscals are needed. > >[ I though ELF was hardware independent with extension options for various > >cpus/systems. ] > > Well, ELF is a file format, but it specifies a method to be used for > dynamic linking. Therefore if a user program needs to call printf, there is > an entry in the relocation tables indicating where the actual address of printf > should be patched in. The program loader reads these and performs this linking > step at run time. In principle, no program binaries should ever contain > syscalls by themself, they should be calling the stub functions in libc to do > this (i.e. write, read, etc), so it is the responsibility of libc, not the user > application to use the appropriate syscall for the local system. The > specification explicitly states that binary compatibility is to be maintained > by providing a compatibile set of shared libraries - nothing is explicitly > mentioned about compatible syscalls. > > iBSC2 predates ELF, and there is no specification for the dynamic > linking. There are specifications for shared libraries which are similar to > the linux shared libraries prior to the DLL libraries, but the key point is > that the iBSC2 specification explicitly states that syscalls are to be made via > the "lcall 7,0" mechanism, and binary compatibility is to be maintained by > providing a compatible lcall interface. > > Even though ELF does not require compatible syscalls, a SVr4 machine > does implement the iBSC2 syscalls to provide backwards compatibility. Also, > some of the semantics (i.e. structure definitions, constants, etc) differ from > linux to SVr4, and it turns out that iBSC2 is much closer to SVr4 than it is to > linux. Thus while ELF does not directly need the compatible syscalls, it would > make ELF easier to have them (there would be no need to convert structures in > libc and so forth). > > There are also things in ELF to handle hardware independent things, but > this is more or less a side issue as far as I am concerned. I understand that VSTa's binary format is handled largely by execv() and general executables (file,nm,ld,as,...) it should be as easy to add ELF support to VSTa as Linux and some of the code framework exists. Does anybody care about iBSC2 ? Does anybody have more info on ELF ? Comments ... ? regards, JonT From myl@genrad.com Thu Sep 2 11:20:59 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17699; Thu, 2 Sep 93 11:20:58 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04919; Thu, 2 Sep 93 11:25:56 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25955(netkeeper.sj.nec.com ); Thu, 2 Sep 93 11:25:55 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA15121(archimedes.inoc.sj.nec.com ); Thu, 2 Sep 93 11:25:50 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA26238 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 11:18:29 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00163); Thu, 2 Sep 93 11:13:58 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA26197 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 11:14:51 -0700 Received: by genrad.com (5.57) id AA02136; Thu, 2 Sep 93 14:14:43 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA09722; Thu, 2 Sep 93 14:14:38 EDT Date: Thu, 2 Sep 93 14:14:38 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309021814.AA09722@bronco.genrad.com> To: vsta@cisco.com Subject: Re: adding support for logical partitions to wd Status: OR nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes: > I believe that Linux and/or 386BSD support extended partitions. At > least in the pc9801 version for one of these I've seen the code for > dealing with them. If you don't find anything else, I'll see if I can > dig it up. Thanks. I'll let you know. In the mean time, I've determined the basic extended/logical partition structure by dumping sectors on my dos hard disk. Armed with this information, I was able to make changes to init_part() and iodone() and get wd to "see" the logical partitions (d:, e:, and f:) on my hard disk. When I get more definitive information on extended dos partitions, I'll make any changes necessary and package the code so it can be called as library routine. BTW: the reason I started to look into this in the first place is because I wanted to give vsta a partition of its own (i'm running the MKS toolkit, and there are some filename conflicts between the two environments). Anyway, I made the following change to boot.lst: 27c27 < ../dos/dos -p disk/wd wd0_dos0 fs/root --- > ../dos/dos -p disk/wd wd0_dos3 fs/root (Note that dos and MKS are on c:, and vsta is on f:). Is this reasonable? It seems to work. Mike Larson From myl@genrad.com Thu Sep 2 12:30:08 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18018; Thu, 2 Sep 93 12:30:07 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05045; Thu, 2 Sep 93 12:35:07 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27030(netkeeper.sj.nec.com ); Thu, 2 Sep 93 12:35:06 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA15425(archimedes.inoc.sj.nec.com ); Thu, 2 Sep 93 12:35:04 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA27583 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 12:28:44 -0700 Received: from genrad.genrad.com by amri.cisco.com (AA00209); Thu, 2 Sep 93 12:26:13 -0700 Received: by genrad.com (5.57) id AA28352; Tue, 31 Aug 93 12:17:07 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA08505; Tue, 31 Aug 93 12:17:04 EDT Date: Tue, 31 Aug 93 12:17:04 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9308311617.AA08505@bronco.genrad.com> To: vsta@cisco.com Subject: adding support for msdos logical partitions Status: OR Hi, I would like to add support for msdos logical partitions to wd. Here's the way I currently have my hard disk partitioned: type start finish size ------- ----- ------ ---- c: PRI DOS 0 256 257 EXT DOS 257 914 658 (the numbers are from memory, so they may be slightly off). Within the extended partition, I have 3 logical partitions: start finish size ----- ------ ---- d: 257 513 257 e: 514 770 257 f: 771 914 144 It appears that the partition table that resides on block 0 contains a partition information for the primary and extended dos partitions, while each logical partition has a partition table of its own. The question is: what is the best way to modify wd to: 1) read partition tables from blocks other than block 0? 2) read multiple partition tables per unit (hard disk)? It appears that wd only looks for boot block information in sector 0. Also, init_part() gets a buffer containing boot sector passed to it. To support logical msdos partitions, it would be nice if init_part() could (synchronously) read sectors itself. Suggestions? Best Regards, Mike Larson From hp@idefix.vmars.tuwien.ac.at Thu Sep 2 12:19:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18001; Thu, 2 Sep 93 12:19:47 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05032; Thu, 2 Sep 93 12:24:43 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26838(netkeeper.sj.nec.com ); Thu, 2 Sep 93 12:24:39 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA15370(archimedes.inoc.sj.nec.com ); Thu, 2 Sep 93 12:24:37 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA27428 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 12:16:35 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00193); Thu, 2 Sep 93 12:12:46 -0700 Received: from idefix.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA27402 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 12:13:39 -0700 Received: by idefix.vmars.tuwien.ac.at id AA05296 (5.64+/IDA-1.3.4 for vsta@cisco.com); Thu, 2 Sep 93 21:11:27 +0200 From: Peter Holzer Message-Id: <9309021911.AA05296@idefix.vmars.tuwien.ac.at> Subject: Re: adding support for logical partitions to wd To: vsta@cisco.com Date: Thu, 2 Sep 93 21:11:26 MET DST In-Reply-To: <9309021814.AA09722@bronco.genrad.com>; from "Michael A. Larson" at Sep 2, 93 2:14 pm Reply-To: hp@vmars.vmars.tuwien.ac.at X-No-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Michael A. Larson) wrote: > > In the mean time, I've determined the basic extended/logical partition > structure by dumping sectors on my dos hard disk. Armed with this > information, I was able to make changes to init_part() and iodone() and > get wd to "see" the logical partitions (d:, e:, and f:) on my hard > disk. > > Anyway, I made the following change to boot.lst: > > 27c27 > < ../dos/dos -p disk/wd wd0_dos0 fs/root > --- > > ../dos/dos -p disk/wd wd0_dos3 fs/root > So you are flattening to partition structure? Is there still an entry for the extended partition, or is replaced by its subpartitions? hp -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From myl@genrad.com Fri Sep 3 06:42:08 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27201; Fri, 3 Sep 93 06:42:06 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06151; Fri, 3 Sep 93 06:47:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09749(netkeeper.sj.nec.com ); Fri, 3 Sep 93 06:47:12 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17404(archimedes.inoc.sj.nec.com ); Fri, 3 Sep 93 06:47:10 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA10007 (5.67a/IDA-1.5 for ); Fri, 3 Sep 1993 06:39:59 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00722); Fri, 3 Sep 93 06:38:07 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA09993 (5.67a/IDA-1.5 for ); Fri, 3 Sep 1993 06:39:07 -0700 Received: by genrad.com (5.57) id AA27101; Fri, 3 Sep 93 09:38:58 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA10216; Fri, 3 Sep 93 09:38:56 EDT Date: Fri, 3 Sep 93 09:38:56 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309031338.AA10216@bronco.genrad.com> To: vsta@cisco.com Subject: Re: adding support for logical partitions to wd Status: OR Peter Holzer (hp@idefix.vmars.tuwien.ac.at) asks: > So you are flattening to partition structure? Is there still an entry > for the extended partition, or is replaced by its subpartitions? The way I have my hard disk set up (using the MSDOS fdisk utility) is C: is the primary partition. After the primary partition, there is an extended partition. The extended partition contains 3 logical (sub) partitions. MSDOS sees the logical partitions as D:, E:, and F:. With this setup, the extended partition is just a container for the logical partitions. So, the answer to your question is there is no entry for the extended partition - it is replaced by its subpartitions. Mike Larson From nick@nsis.cl.nec.co.jp Wed Sep 8 16:42:51 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23625; Wed, 8 Sep 93 16:42:49 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10848; Wed, 8 Sep 93 16:47:46 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24241(netkeeper.sj.nec.com ); Wed, 8 Sep 93 16:47:44 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA27450(archimedes.inoc.sj.nec.com ); Wed, 8 Sep 93 16:47:41 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA07145 (5.67a/IDA-1.5 for ); Wed, 8 Sep 1993 16:40:13 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00245); Wed, 8 Sep 93 16:37:06 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by hubbub.cisco.com with SMTP id AA07126 (5.67a/IDA-1.5 for ); Wed, 8 Sep 1993 16:39:07 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA08062; Thu, 9 Sep 1993 08:39:01 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA08467; Thu, 9 Sep 1993 08:38:59 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930903.1) id AA11379; Thu, 9 Sep 1993 08:38:58 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA00901; Thu, 9 Sep 93 08:38:56 JST Date: Thu, 9 Sep 93 08:38:56 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309082338.AA00901@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: strange silence, and.. Status: OR Well, to dispel any thought that VSTa is not active, I decided to post to the list :-) [Andy writes:] >So far as I know it's healthy. The window stuff is rolling along, although >I guess Nick sent me E-mail directly. Yep. Unfortunately, I don't run an IBM compatible (I must say VSTa was *easy* to port. Compared to 386bsd and Linux), so I can't develop the vga side, or rather, I can't *test* it (I'll be doing the device-specific stuff on my machine). Anyone on the list interested in doing a vga port? When I have the device-independent skeleton well tested, I'll send you the code, and you could write the vga specific stuff. [songdog!roman@eskimo.com writes:] >I am still quite interested in VSTa. Active participation in development >has to wait for me to have an opportunity to repartition my hard disk, as I *removed* Linux and 386bsd from my development machine. Solved the problem, and helps me to focus on VSTa (when I boot DOS I always think "ahh what a crappy thing this is!" so makes me want to get VSTa development done ASAP) :-) Now, something that may be useful for everyone. I'm probably missing something incredibly obvious, but I cant get bitblt to return more that a single byte of data. For example, in the test program, I do something like: write(bitblt_fd,&message,sizeof(message)); read(bitblt_fd,&max_colors, sizeof(long)); but read() only reads the first byte of data. The relevent code in bitblt_read() is: bytes_available = f->f_bend - f->f_bpos; count = msg->m_buflen; if (count > bytes_available) { count = bytes_available; } msg->m_buf = f->f_buffer+f->f_bpos; msg->m_buflen = count; msg->m_arg = count; msg->m_nseg = (count ? 1 : 0); msg->m_arg1 = 0; msg_reply(msg->m_sender, msg); f->f_buffer is a dynamic ring buffer, and it hold the correct data. Likewise count holds 4. msg is the message from the user program. What am I doing wrong? From hp@gipsy.vmars.tuwien.ac.at Thu Sep 9 04:38:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27572; Thu, 9 Sep 93 04:38:29 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11253; Thu, 9 Sep 93 04:43:29 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01164(netkeeper.sj.nec.com ); Thu, 9 Sep 93 04:43:27 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28482(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 04:43:22 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA14297 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 04:33:16 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00641); Thu, 9 Sep 93 04:29:03 -0700 Received: from gipsy.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA14286 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 04:31:01 -0700 Received: by gipsy.vmars.tuwien.ac.at id AA02216 (5.64+/IDA-1.3.4 for vsta@cisco.com); Thu, 9 Sep 93 13:28:45 +0200 From: Peter Holzer Message-Id: <9309091128.AA02216@gipsy.vmars.tuwien.ac.at> Subject: Hard disk problem solved To: vsta@cisco.com Date: Thu, 9 Sep 93 13:28:44 MET DST Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR Yesterday I managed to coax my hard drive into seeking at maximum speed. Here are the patches to wd.c and wd.h. They also limit read and write operations to a single track, because my drive obviously had trouble with track switching. *** wd.c 1993/08/02 20:17:07 1.5 --- wd.c 1993/09/08 23:06:42 *************** *** 14,21 **** static int wd_cmd(int); static void wd_start(), wd_readp(int), wd_cmos(int), wd_parseparms(int, char *); ! uint first_unit; /* Lowerst unit # configured */ /* * The parameters we read on each disk, and a flag to ask if we've --- 14,22 ---- static int wd_cmd(int); static void wd_start(), wd_readp(int), wd_cmos(int), wd_parseparms(int, char *); + static void wd_calibrate (int); ! uint first_unit; /* Lowest unit # configured */ /* * The parameters we read on each disk, and a flag to ask if we've *************** *** 23,28 **** --- 24,30 ---- */ struct wdparms parm[NWD]; char configed[NWD]; + char calibrated[NWD]; /* * Miscellaneous counters *************** *** 160,165 **** --- 162,168 ---- if (configed[unit]) { uint s = parm[unit].w_size * SECSZ; const uint m = 1024*1024; + int status; printf("wd%d: %d.%dM\n", unit, s / m, (s % m) / (m/10)); *************** *** 167,172 **** --- 170,176 ---- if (unit < first_unit) { first_unit = unit; } + wd_calibrate (unit); } } if (!found_first) { *************** *** 239,249 **** /* * Given disk geometry, calculate parameters for next I/O */ cyl = cur_sec / w->w_secpercyl; sect = cur_sec % w->w_secpercyl; - lsect = w->w_secpercyl - sect; trk = sect / w->w_secpertrk; sect = (sect % w->w_secpertrk) + 1; /* * Transfer size--either the rest, or the remainder of this track --- 243,255 ---- /* * Given disk geometry, calculate parameters for next I/O */ + + if (!calibrated [cur_unit]) wd_calibrate (cur_unit); cyl = cur_sec / w->w_secpercyl; sect = cur_sec % w->w_secpercyl; trk = sect / w->w_secpertrk; sect = (sect % w->w_secpertrk) + 1; + lsect = w->w_secpertrk + 1 - sect; /* * Transfer size--either the rest, or the remainder of this track *************** *** 564,566 **** --- 570,630 ---- w->w_size = w->w_secpercyl * w->w_cyls; configed[unit] = 1; } + + /* + * specify: part one of drive calibration + */ + + static void wd_specify (int unit) { + + cur_op = WDC_SPECIFY; + outportb(WD_PORT+WD_CTLR, 0); + outportb(WD_PORT+WD_ERROR, 0xFF); + outportb(WD_PORT+WD_SCNT, parm[unit].w_secpertrk); + outportb(WD_PORT+WD_SNUM, 0); + outportb(WD_PORT+WD_CYL0, 0); + outportb(WD_PORT+WD_CYL1, 0); + outportb(WD_PORT+WD_SDH, + WDSDH_EXT|WDSDH_512 | parm[unit].w_tracks | (unit << 4)); + outportb(WD_PORT+WD_CMD, + WDC_SPECIFY); + } + + /* + * calibrate: part two of drive calibration + */ + + static void + wd_calibrate (int unit) + { + int status; + + cur_op = WDC_CALIBRATE; + outportb(WD_PORT+WD_CTLR, 0); + outportb(WD_PORT+WD_ERROR, 0xFF); + outportb(WD_PORT+WD_SCNT, parm[unit].w_secpertrk); + outportb(WD_PORT+WD_SNUM, 0); + outportb(WD_PORT+WD_CYL0, 0); + outportb(WD_PORT+WD_CYL1, 0); + outportb(WD_PORT+WD_SDH, + WDSDH_EXT|WDSDH_512 | 0 | (unit << 4)); + outportb(WD_PORT+WD_CMD, WDC_CALIBRATE); + + while (inportb (WD_PORT+WD_STATUS) & WDS_BUSY); + status = inportb (WD_PORT+WD_STATUS); + if (status & WDS_ERROR) { + printf ("calibrate %d: status %x, error %x\n", + unit, status, inportb (WD_PORT+WD_ERROR)); + } else { + calibrated [unit] = 1; + } + } + + char wd_c_rcs_id [] = + "$Id: wd.c 1.5.1.1 1993/09/08 23:04:51 hjp Exp $"; + /* $Log: wd.c $ + * Revision 1.5.1.1 1993/09/08 23:04:51 hjp + * Added calibration at start to set step rate to fastest value. + * Limited read ops to one track to avoid read errors at start of track. + * + */ *** wd.h 1993/08/02 20:17:58 1.4 --- wd.h 1993/09/08 23:08:42 *************** *** 2,8 **** #define _WD_H /* * wd.h ! * Wester Digital ST-506 type hard disk interface definitions */ #include #include --- 2,8 ---- #define _WD_H /* * wd.h ! * Western Digital ST-506 type hard disk interface definitions */ #include #include *************** *** 36,43 **** --- 36,47 ---- * Status bits */ #define WDS_ERROR 0x1 /* Error */ + #define WDS_INDEX 0x2 /* Index pulse */ #define WDS_ECC 0x4 /* Soft ECC error */ #define WDS_DRQ 0x8 /* Data request */ + #define WDS_SEEKCMPL 0x10 /* Seek completed */ + #define WDS_WRITEFLT 0x20 /* Write fault */ + #define WDS_READY 0x40 /* Ready (obviously not the same as not busy) */ #define WDS_BUSY 0x80 /* Busy */ /* *************** *** 56,65 **** /* * Commands */ ! #define WDC_READ 0x20 /* Command: read */ #define WDC_WRITE 0x30 /* ...write */ #define WDC_READP 0xEC /* ...read parameters */ - #define WDC_DIAG 0x90 /* Run controller diags */ /* * Read parameters command (WDC_READP) returns this. I think this --- 60,71 ---- /* * Commands */ ! #define WDC_CALIBRATE 0x10 /* Command: calibrate */ ! #define WDC_READ 0x20 /* ...read */ #define WDC_WRITE 0x30 /* ...write */ + #define WDC_DIAG 0x90 /* ...run controller diags */ + #define WDC_SPECIFY 0x91 /* ...specify parameters */ #define WDC_READP 0xEC /* ...read parameters */ /* * Read parameters command (WDC_READP) returns this. I think this *************** *** 159,163 **** --- 165,176 ---- extern void wd_init(int, char **); extern void iodone(); extern char configed[]; + + /* $Id: wd.h 1.4.1.1 1993/09/08 23:08:19 hjp Exp $ + * $Log: wd.h $ + * Revision 1.4.1.1 1993/09/08 23:08:19 hjp + * add calibrate and specify commands and missing bits from status + * + */ #endif /* _WD_H */ -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From jont@hsa.com.au Thu Sep 9 08:31:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00648; Thu, 9 Sep 93 08:31:48 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11371; Thu, 9 Sep 93 08:36:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03824(netkeeper.sj.nec.com ); Thu, 9 Sep 93 08:36:48 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28846(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 08:36:45 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA17683 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:26:50 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00086); Thu, 9 Sep 93 08:22:24 -0700 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA17622 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:23:56 -0700 Received: by warrane.connect.com.au with UUCP id AA11604 (5.67a+/IDA-1.5 for vsta@cisco.com); Fri, 10 Sep 1993 01:22:29 +1000 Received: from eccles.com.au (eccles) by hsa.hsa.com.au with SMTP id AA10645 (5.65c/IDA-1.5 for ); Thu, 9 Sep 1993 23:48:45 +1000 From: Jonathon Tidswell Message-Id: <199309091348.AA10645@hsa.hsa.com.au> Subject: boot problems. scsi. 9P. To: vsta@cisco.com Date: Thu, 9 Sep 1993 23:50:38 +1000 (EST) In-Reply-To: <199309091306.AA10376@hsa.hsa.com.au> from "Operator" at Sep 9, 93 11:06:39 pm Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2566 Status: OR [ Sometimnes the uucp delay can be put to good use. Stopping an item and editing it before re-sending ... :-] ----- BOOT PROBLEMS ----- > From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) [ ... regarding disk partitions and Linux ... ] I also scrapped Linux to create the DOS partition needed for VSTa, though I have had some troubles bootstrapping VSTa :-( | I grabbed a a few different versions of make for dos and rm/touch for dos | so far I have not found a combination that works. | [ Im a DOS newbie, this is basically my first dos partition ;-/ ] Since writing this I managed to get an 'rm' that worked with dmake3.8 and Im almost happy. Ive come accross a few problems [ I just checked the patches and they fix most of them ] the one remaining concerns "an unknown error" from login scrolling down my screen when boot runs init. I might try playing with init and adding the patches :-) ----- SCSI ----- Is anybody else considering working on scsi ? [ I have both IDE disk and scsi disk, tape and cdrom. ] My thoughts are rather abstract sofar, mostly a server that would create a directory tree like the following (/dev/??) scsi/ n/ info - things like name, [a]sync, device id, ... chnl - access for device hba - this is a duplicate of the info file for whichever device id is used by the hba. The directory would be present iff a device was found on the bus. The scsi server would be written to allow only one open connection to any particular device chnl. [ Im not sure about FS_DUP ? ] A tape server would then attempt to search through scsi/?/info for any name that matched a device it knew how to handle at which point it would open RD.WR the chnl for that device. It may then make another directory tree available ... My current status is that I am looking at adaptec 1542, PC/ISA-BUS info and VSTa info to figure out the scsi server, I have not looked yet at the record structure required for messages down the device chnl. My plan is to write a simple server that creates the directory tree according to some config file, and test my VSTa interface, then to work on the scsi part and test my SCSI code, which wont autoconfig-IRQ. comments ... ? [ Since Ive never been kernel hacking before I dont presume to cluefulnes(*) so if you arent sure if I have thought of something I quite probably havent. ] ----- 9P ----- Andrew made a reference to similarity between vsta messages and 9P in one of his docs, is anyone considering a library mapping one to the other ? thanks JonT (*) Nor good english. :-) From vandys@cisco.com Thu Sep 9 08:43:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00653; Thu, 9 Sep 93 08:43:55 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11377; Thu, 9 Sep 93 08:48:57 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04048(netkeeper.sj.nec.com ); Thu, 9 Sep 93 08:48:55 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28893(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 08:48:53 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA17967 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:40:09 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00095); Thu, 9 Sep 93 08:35:46 -0700 Received: from localhost by glare.cisco.com with SMTP id AA09369 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:37:57 -0700 Message-Id: <199309091537.AA09369@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Hard disk problem solved In-Reply-To: Your message of "Thu, 09 Sep 1993 13:28:44 +0700." <9309091128.AA02216@gipsy.vmars.tuwien.ac.at> Date: Thu, 09 Sep 1993 08:37:57 -0700 From: Andrew Valencia Status: OR [Peter Holzer writes:] >Yesterday I managed to coax my hard drive into seeking at maximum >speed. Here are the patches to wd.c and wd.h. They also limit read and >write operations to a single track, because my drive obviously had >trouble with track switching. >From my reading of your diffs, it looks like your controller won't automatically advance to the next head. I'm guessing that this is because you have to use a pseudo-geometry (did the readp or the cmos command work for you in boot/boot.lst?) and thus the wd driver isn't able to tell when it would be OK to ask for multiple tracks. Thus, perhaps I should add a flag so that CMOS geometries will not use multiple track reads, but readp geometries will (because they're more likely to be right). I'm puzzled by why your drive needed a recalibrate. Since we boot from DOS, it should've been recalibrated already? It's good to add such initialization, but I'd like to understand how the drive got into an uncalibrated state in the first place. Is it necessary that the drive be calibrated twice? I see a recal once during the scan for disks, and again on the first I/O setup. Is this needed? There's no place which clears the calibrated[] entry, so why does this flag (calibrated[unit]) need to be kept? Regards, Andy From vandys@cisco.com Thu Sep 9 08:56:42 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00667; Thu, 9 Sep 93 08:56:41 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11385; Thu, 9 Sep 93 09:01:43 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04164(netkeeper.sj.nec.com ); Thu, 9 Sep 93 09:01:41 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28914(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 09:01:39 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA18259 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:51:03 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00104); Thu, 9 Sep 93 08:47:12 -0700 Received: from localhost by glare.cisco.com with SMTP id AA10042 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 08:49:24 -0700 Message-Id: <199309091549.AA10042@glare.cisco.com> To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: boot problems. scsi. 9P. In-Reply-To: Your message of "Thu, 09 Sep 1993 23:50:38 +1000." <199309091348.AA10645@hsa.hsa.com.au> Date: Thu, 09 Sep 1993 08:49:23 -0700 From: Andrew Valencia Status: OR [Jonathon Tidswell writes:] >| I grabbed a a few different versions of make for dos and rm/touch for dos >| so far I have not found a combination that works. Yes, I'm still hunting for such a beast myself. Some don't honor I/O redirection, others don't honor generic rules. I didn't realize the DOS "make" world was such a mess! >The scsi server would be written to allow only one open connection to any >particular device chnl. [ Im not sure about FS_DUP ? ] You would only see these if your SCSI device handler did a fork(). Not too likely to happen, but I guess you could return failure and thus children would not have access to the device. >A tape server would then attempt to search through scsi/?/info for any name >that matched a device it knew how to handle at which point it would open >RD.WR the chnl for that device. Actually, I'd just have the tape server written to be told what to open. Use a shell script to walk the SCSI hierarchy and run servers on devices. >It may then make another directory tree available ... Depends on the SCSI device. Tape would not necessarily need a dir tree--the top node would be the place you do everything. Disks could need a dir tree, since they might offer partitions. >My plan is to write a simple server that creates the directory tree according >to some config file, and test my VSTa interface, then to work on the scsi >part and test my SCSI code, which wont autoconfig-IRQ. Don't use a config file! The config file is on the SCSI disk, so your SCSI disk server has to be up. But it needs a config file.... :-) >[ Since Ive never been kernel hacking before I dont presume to cluefulnes(*) >so if you arent sure if I have thought of something I quite probably havent. ] Well, this isn't really kernel hacking! It's system code, but it runs in ring 3. That's why I like microkernels. If you have a copy of the technical spec for the 1542, I would really like to see it. I also don't have the SCSI spec for hard disks. All my PC technical documentation is rather old.... Andy From hp@petrus.vmars.tuwien.ac.at Thu Sep 9 09:34:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00747; Thu, 9 Sep 93 09:34:03 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11442; Thu, 9 Sep 93 09:39:05 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09714(netkeeper.sj.nec.com ); Thu, 9 Sep 93 09:39:03 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA29036(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 09:38:59 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA19635 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 09:31:07 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00118); Thu, 9 Sep 93 09:27:15 -0700 Received: from petrus.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA19492 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 09:29:24 -0700 Received: by petrus.vmars.tuwien.ac.at id AA20639 (5.64+/IDA-1.3.4 for vsta@cisco.com); Thu, 9 Sep 93 18:27:10 +0200 From: Peter Holzer Message-Id: <9309091627.AA20639@petrus.vmars.tuwien.ac.at> Subject: Re: Hard disk problem solved To: vsta@cisco.com Date: Thu, 9 Sep 93 18:27:09 MET DST In-Reply-To: <199309091537.AA09369@glare.cisco.com>; from "Andrew Valencia" at Sep 9, 93 8:37 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Andrew Valencia) wrote: > >From my reading of your diffs, it looks like your controller won't > automatically advance to the next head. Yes. > I'm guessing that this is > because you have to use a pseudo-geometry (did the readp or the cmos > command work for you in boot/boot.lst?) No. I didn't expect cmos to work (The cmos entries are for type 1 (10MB disk), ands are obviously ignored by the BIOS), but readp didn't either. The Minix driver takes info from the BIOS parameter tables (int 41 and 45, I think). Could wd do the same? We just needed to map the first 1MB physical memory into the wd's memory somewhere. I don't think I have a pseudo-geometry. 26 sectors, 8 heads sounds reasonable for an RLL drive. > I'm puzzled by why your drive needed a recalibrate. Since we boot > from DOS, it should've been recalibrated already? It's good to add > such initialization, but I'd like to understand how the drive got into > an uncalibrated state in the first place. It isn't really uncalibrated. Just the step-rate is off (seeking from the first to the last cylinder takes several seconds). I have no idea why DOS (MS-DOS 6.0) or the BIOS (AMI BIOS, 4 years old) changes the step rate, but it obviously does. There are two possibilities to set the step rate, and I chose the more radical. > Is it necessary that the drive be calibrated twice? I see a recal once > during the scan for disks, and again on the first I/O setup. No, calibrated [unit] is set in wd_calibrate, if calibrate succeeded, so the firstI/O will normally not recalibrate the drive again. > There's no place which clears the calibrated[] entry, so why > does this flag (calibrated[unit]) need to be kept? I reset the flag after a hard error to force recalibration before the next I/O. It seems I deleted this together with a bunch of debugging printfs :-( I also noticed that I hadn't deleted the status variable (in line 164) when I moved the check whether calibrate had succeeded into wd_calibrate, and that the wd_specify function still exists, but isn't called anymore. hp -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Computer Science/Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand | From vandys@cisco.com Thu Sep 9 11:03:20 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01483; Thu, 9 Sep 93 11:03:19 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11555; Thu, 9 Sep 93 11:08:22 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27556(netkeeper.sj.nec.com ); Thu, 9 Sep 93 11:08:20 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA29433(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 11:08:18 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA22177 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 11:01:00 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00095); Thu, 9 Sep 93 10:57:28 -0700 Received: from localhost by glare.cisco.com with SMTP id AA19434 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 10:59:41 -0700 Message-Id: <199309091759.AA19434@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Hard disk problem solved In-Reply-To: Your message of "Thu, 09 Sep 1993 13:28:44 +0700." <9309091128.AA02216@gipsy.vmars.tuwien.ac.at> Date: Thu, 09 Sep 1993 10:59:41 -0700 From: Andrew Valencia Status: OR [Peter Holzer writes:] >Yesterday I managed to coax my hard drive into seeking at maximum >speed. Here are the patches to wd.c and wd.h. They also limit read and >write operations to a single track, because my drive obviously had >trouble with track switching. Peter, Limiting reads to a single track will have little impact on the current filesystems, since they only read a cluster at a time anyway (~4K). But my new filesystem is purposely set up so that contiguous reads of ~64K will be common to the disk. Could we perhaps allow large reads until some specific error is detected, and *then* drop back to single-track reads? Andy From mackinla@cs.curtin.edu.au Thu Sep 9 10:59:51 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01467; Thu, 9 Sep 93 10:59:50 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11548; Thu, 9 Sep 93 11:04:51 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27521(netkeeper.sj.nec.com ); Thu, 9 Sep 93 11:04:50 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA29413(archimedes.inoc.sj.nec.com ); Thu, 9 Sep 93 11:04:46 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA22072 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 10:56:25 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00091); Thu, 9 Sep 93 10:52:27 -0700 Received: from marsh.cs.curtin.edu.au by hubbub.cisco.com with SMTP id AA20149 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 09:52:28 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA06476 (5.67a/IDA-1.5); Fri, 10 Sep 1993 00:52:57 +0800 Received: by lillee.cs.curtin.edu.au id AA17529 (5.67a/IDA-1.4.4); Fri, 10 Sep 1993 00:52:56 +0800 From: Pat Mackinlay Message-Id: <199309091652.AA17529@lillee.cs.curtin.edu.au> Subject: Re: boot problems. scsi. 9P. To: vandys@cisco.com (Andrew Valencia) Date: Fri, 10 Sep 1993 00:52:56 +0800 (WST) Cc: vsta@cisco.com In-Reply-To: <199309091549.AA10042@glare.cisco.com> from "Andrew Valencia" at Sep 9, 93 08:49:23 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 636 Status: OR > If you have a copy of the technical spec for the 1542, I would really > like to see it. I also don't have the SCSI spec for hard disks. All > my PC technical documentation is rather old.... If you're at all interested, a text version of the draft SCSI-II spec. is available on a few FTP sites around the place. I think it's on sunsite.unc.edu under /pub/Linux/docs or something like that. The spec. is pretty useful, listing all the commands and going through the entire arbitration/selection/etc process. Unfortunately, it's all in Engineer- speak, so it's a bit dreary... -- Pat -- Alien lands on head, gives birth to mutant. From myl@genrad.com Fri Sep 10 09:38:44 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23876; Fri, 10 Sep 93 09:38:41 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12536; Fri, 10 Sep 93 09:43:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21557(netkeeper.sj.nec.com ); Fri, 10 Sep 93 09:43:46 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02239(archimedes.inoc.sj.nec.com ); Fri, 10 Sep 93 09:43:43 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA13307 (5.67a/IDA-1.5 for ); Fri, 10 Sep 1993 09:36:17 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00106); Fri, 10 Sep 93 09:32:12 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA13254 (5.67a/IDA-1.5 for ); Fri, 10 Sep 1993 09:34:34 -0700 Received: by genrad.com (5.57) id AA26840; Fri, 10 Sep 93 12:34:21 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA18594; Fri, 10 Sep 93 12:34:18 EDT Date: Fri, 10 Sep 93 12:34:18 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309101634.AA18594@bronco.genrad.com> To: vsta@cisco.com Subject: Re: boot problems. scsi. 9P. Status: OR Hi, [Jonathon Tidswell writes:] > ----- SCSI ----- > Is anybody else considering working on scsi ? > [ I have both IDE disk and scsi disk, tape and cdrom. ] I am also considering working on SCSI. I just got my Adaptec 1542C up and running last Saturday. > My thoughts are rather abstract sofar, mostly a server that would > create a directory tree like the following > (/dev/??) > scsi/ > n/ > info - things like name, [a]sync, device id, ... > chnl - access for device > hba - this is a duplicate of the info file for whichever device id > is used by the hba. > > The directory would be present iff a device was found on the bus. > > The scsi server would be written to allow only one open connection to any > particular device chnl. [ Im not sure about FS_DUP ? ] > > A tape server would then attempt to search through scsi/?/info for any name > that matched a device it knew how to handle at which point it would open > RD.WR the chnl for that device. > > It may then make another directory tree available ... What would the interface to the tape (disk, etc.) server look like? For example, on *nix systems, you might write something like this: tar tvf /dev/rmt0h > My current status is that I am looking at adaptec 1542, PC/ISA-BUS info > and VSTa info to figure out the scsi server, I have not looked yet at the > record structure required for messages down the device chnl. May I suggest looking at CAM? From the SCSI FAQ: QUESTION: What is CAM? ANSWER From: ctjones@bnr.ca (Clifton Jones) ==== Common Access Method. It is a proposed ANSI standard to make it easier to program SCSI applications by encapsulating the SCSI functions into a standardized calling convention. In CAM, the record structure that you that you are refering to is called a CCB (CAM Control Block). [Andrew Valencia writes:] > If you have a copy of the technical spec for the 1542, I would really > like to see it. I also don't have the SCSI spec for hard disks. All > my PC technical documentation is rather old.... I called Adaptec's literature dept. yesterday. They are sending me (free of charge) something called a "Technical Reference" manual for the 1542. When I receive the manual, I'll let you know if it is usable for driver writing. Mike Larson From myl@genrad.com Sun Sep 12 12:05:55 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19952; Sun, 12 Sep 93 12:05:51 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14361; Sun, 12 Sep 93 12:11:10 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09279(netkeeper.sj.nec.com ); Sun, 12 Sep 93 12:11:06 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05642(archimedes.inoc.sj.nec.com ); Sun, 12 Sep 93 12:11:03 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09947 (5.67a/IDA-1.5 for ); Sun, 12 Sep 1993 12:01:25 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00151); Sun, 12 Sep 93 11:55:12 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA09929 (5.67a/IDA-1.5 for ); Sun, 12 Sep 1993 11:57:57 -0700 Received: by genrad.com (5.57) id AA05047; Sun, 12 Sep 93 14:57:48 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA00520; Sun, 12 Sep 93 14:57:44 EDT Date: Sun, 12 Sep 93 14:57:44 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309121857.AA00520@bronco.genrad.com> To: vsta@cisco.com Subject: SCSI CAM Status: OR [Andrew Valencia writes:] > Your comments concerning CAM are good. If I understand the > architecture, we would talk CAM down into the 1542x adaptor server, and > implement SCSI-command-set specific servers to sit on top, talk CAM > down to a particular adaptor, and provide the appropriate interface > upwards to the clients (SCSI disk would probably look like a WD server, > perhaps tape would present a single file instead of a directory). In general, this is true, although the details about the "SCSI-command- set servers" are also specified in CAM. In CAM's world, the disk and tape drivers (servers) are called peripheral drivers (PDRV's for short). At the top, PDRV's system level interface similar to that of any other device driver in the operating system (open/close/read/write/ioctl entry points for *nix, for example). PDRV's do their job by sending SCSI commands down to the next CAM layer, called the transport (or XPT) layer. The commands are contained in a data structure called a CCB (CAM Control Block). One of the jobs of the XPT layer is to route requests from the PDRV's above to one of the SCSI Interface Modules (SIM's) below. There may be more than one SIM per system. SIM's contain HBA (or dumb SCSI chip, etc.) specific code. The 1542x adptor server would be a SIM module, for example. There could also be another (probably much larger) SIM responsible for directly handling an on board NCR53C9x chip. In general, I think that the CAM architecture maps fairly well into what people having been talking about doing for vsta. Comments? Mike Larson From mackinla@cs.curtin.edu.au Sun Sep 12 03:19:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15849; Sun, 12 Sep 93 03:19:45 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14173; Sun, 12 Sep 93 03:25:01 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA14601(netkeeper.sj.nec.com ); Sun, 12 Sep 93 03:24:57 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05394(archimedes.inoc.sj.nec.com ); Sun, 12 Sep 93 03:24:55 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08460 (5.67a/IDA-1.5 for ); Sun, 12 Sep 1993 03:15:46 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00561); Sun, 12 Sep 93 03:08:57 -0700 Received: from marsh.cs.curtin.edu.au by hubbub.cisco.com with SMTP id AA08456 (5.67a/IDA-1.5 for ); Sun, 12 Sep 1993 03:11:26 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA22917 (5.67a/IDA-1.5); Sun, 12 Sep 1993 18:11:46 +0800 Received: by lillee.cs.curtin.edu.au id AA01243 (5.67a/IDA-1.4.4); Sun, 12 Sep 1993 18:11:44 +0800 From: Pat Mackinlay Message-Id: <199309121011.AA01243@lillee.cs.curtin.edu.au> Subject: Solution to IDE geometry problems... To: vandys@cisco.com, vsta@cisco.com Date: Sun, 12 Sep 1993 18:11:43 +0800 (WST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 742 Status: OR As per the subject, I think I might have worked out how to kick the WD server's geomtry hassles for good. What needs to happen is for an "Initialise drive parameters" command to be sent to the drive after the geometry is read with the "Read parameters" command. This will allow the WD server to use whatever geometry the drive returns without any problems (I hope). I'll be making a stab at this in a few minutes, and if it works on my disks, I'll send the patch along. Andy, I was wrong about how things work - we don't really need the BIOS's "fake" geometry unless we want to _create_ partitions, something the FDISK utility (when we have one) will be able to prompt the user for. -- Pat -- Alien lands on head, gives birth to mutant. From jont@hsa.com.au Wed Sep 15 01:26:44 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18671; Wed, 15 Sep 93 01:26:43 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20754; Wed, 15 Sep 93 01:32:19 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA28909(netkeeper.sj.nec.com ); Wed, 15 Sep 93 01:32:14 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11713(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 01:32:07 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03402 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 01:21:11 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00680); Wed, 15 Sep 93 01:16:03 -0700 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA03362 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 01:19:11 -0700 Received: by warrane.connect.com.au with UUCP id AA26809 (5.67a+/IDA-1.5 for vsta@cisco.com); Wed, 15 Sep 1993 18:19:04 +1000 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA28917 (5.65c/IDA-1.5 for ); Wed, 15 Sep 1993 18:16:05 +1000 From: Jonathon Tidswell Message-Id: <199309150816.AA28917@hsa.hsa.com.au> Subject: CAM To: vsta@cisco.com Date: Wed, 15 Sep 1993 18:12:41 +1000 (EST) In-Reply-To: <9309101634.AA18594@bronco.genrad.com> from "Michael A. Larson" at Sep 10, 93 12:34:18 pm Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 863 Status: OR Regarding CAM: I'm waiting for the ftp return of CAM stuff at present. Im a little apprehensive about having 4 processes between a disk read and the disk: client ==> disk-FS ==> PDRV ==> XPT ==> SIM ==> disk [ and back - though this MAY be shorter ] Noting that each one is a context switch even if the data is 'copied' using VM mappings, the registers and VM mapping must be saved and flushed etc I expect that the XPT can be mapped into either the PDRV or the SIM. Which is better depends on a more detailed analysis of CAM. This also leads me to wonder about about a secondary server-process interface, based on procedure calls instead of msg passing. Msg passing has advantages during debugging and potentially on MP systems, however on Uniprocessors where known inter-server dependencies exist a procedural interface MAY have an advantage. regards JonT From mackinla@cs.curtin.edu.au Wed Sep 15 02:18:59 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18686; Wed, 15 Sep 93 02:18:53 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20894; Wed, 15 Sep 93 02:24:24 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29247(netkeeper.sj.nec.com ); Wed, 15 Sep 93 02:24:19 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11743(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 02:24:11 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03728 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 02:16:42 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00767); Wed, 15 Sep 93 02:10:40 -0700 Received: from marsh.cs.curtin.edu.au by hubbub.cisco.com with SMTP id AA03716 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 02:13:50 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA21632 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 17:14:06 +0800 Received: by lillee.cs.curtin.edu.au id AA17135 (5.67a/IDA-1.4.4); Wed, 15 Sep 1993 17:14:02 +0800 From: Pat Mackinlay Message-Id: <199309150914.AA17135@lillee.cs.curtin.edu.au> Subject: Re: CAM To: jont@hsa.com.au Date: Wed, 15 Sep 1993 17:14:01 +0800 (WST) Cc: vsta@cisco.com In-Reply-To: <199309150816.AA28917@hsa.hsa.com.au> from "Jonathon Tidswell" at Sep 15, 93 06:12:41 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1090 Status: OR > I'm waiting for the ftp return of CAM stuff at present. Do you have the SCSI-II draft as well? It's available on ftp.cs.tulane.edu under /pub/scsi if you (or anyone else) is interested. It's pretty dry reading, but it is useful... > Im a little apprehensive about having 4 processes between a disk read and the > disk: > client ==> disk-FS ==> PDRV ==> XPT ==> SIM ==> disk Any idea what Plan9 or QNX do? Andy? I'm not sure, but I would have thought that a few context switches wasn't much compared to the speed of reading a reasonable amount of data from disk. Perhaps a good serve of blocking and buffering will reduce the impact? Mach doesn't use CAM - it has device "drivers" (really interfaces) built into the kernel, so it's much more like a traditional kernel in that respect. I mention it because Mach has _exceptional_ SCSI support... One other thought - could you go over the various components and what they're supposed to do again? Can any of them be combined into a single driver without losing configurability? -- Pat -- Alien lands on head, gives birth to mutant. From myl@genrad.com Wed Sep 15 08:04:25 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24427; Wed, 15 Sep 93 08:04:19 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21668; Wed, 15 Sep 93 08:09:53 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02197(netkeeper.sj.nec.com ); Wed, 15 Sep 93 08:09:48 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA12140(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 08:09:46 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08555 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 08:02:24 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00868); Wed, 15 Sep 93 07:56:44 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA08499 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 08:00:01 -0700 Received: by genrad.com (5.57) id AA08081; Wed, 15 Sep 93 10:59:48 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA05093; Wed, 15 Sep 93 10:59:46 EDT Date: Wed, 15 Sep 93 10:59:46 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309151459.AA05093@bronco.genrad.com> To: vsta@cisco.com Subject: Re: CAM Status: OR Jonathon Tidswell writes: > Im a little apprehensive about having 4 processes between a disk read and the > disk: > client ==> disk-FS ==> PDRV ==> XPT ==> SIM ==> disk > [ and back - though this MAY be shorter ] > Noting that each one is a context switch even if the data is 'copied' > using VM mappings, the registers and VM mapping must be saved and flushed etc and Pat Mackinlay writes: > One other thought - could you go over the various components and what they're > supposed to do again? Can any of them be combined into a single driver > without losing configurability? Well, Jonathon and Pat have hit on a key issue for implementing any SCSI driver: efficiency vs configurability. The SCSI (CAM) driver could be implemented by putting all modules (PDRV, XPT, and SIM) into a single monolithic process. (Most SCSI drivers that I know of are implemented this way - all modules share a single address space). These drivers are typically statically linked. So, for example, adding a new SIM module might require adding some entries to a table, a compile, a link, and a re-boot. In addition, you need a "generic" kernel or SCSI server that contains all SIM's so the operating system could be initially booted on any system that has one of the supported SCSI HBA's. Alternatively, the SIM's (with possibly some XPT functionality included), could run as separate server processes. In this scenario, the boot program would be told to run the PDRV's and the appropriate SIM(s). For the average user, this is much nicer to manage, IMHO, than the monolithic scenario above. Now, is there a middle-of-the-road approach? I suppose that SIM's could be dynamically loaded by a monolithic SCSI (CAM) driver. But there's a chicken-and-egg bootstrap problem here, and I don't really know enough about vsta to tell if this is feasible. Mike Larson From vandys@cisco.com Wed Sep 15 10:30:48 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24608; Wed, 15 Sep 93 10:30:45 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22063; Wed, 15 Sep 93 10:36:20 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25587(netkeeper.sj.nec.com ); Wed, 15 Sep 93 10:36:14 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA12528(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 10:36:12 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA12233 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 10:28:42 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00084); Wed, 15 Sep 93 10:22:35 -0700 Received: from localhost by glare.cisco.com with SMTP id AA28224 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 08:33:34 -0700 Message-Id: <199309151533.AA28224@glare.cisco.com> To: Pat Mackinlay Cc: jont@hsa.com.au, vsta@cisco.com Subject: Re: CAM In-Reply-To: Your message of "Wed, 15 Sep 1993 17:14:01 +0800." <199309150914.AA17135@lillee.cs.curtin.edu.au> Date: Wed, 15 Sep 1993 08:33:33 -0700 From: Andrew Valencia Status: OR [Pat Mackinlay writes:] >Any idea what Plan9 or QNX do? Andy? I'm not sure, but I would have thought >that a few context switches wasn't much compared to the speed of reading >a reasonable amount of data from disk. Perhaps a good serve of blocking >and buffering will reduce the impact? My filesystem will definitely be able to do contiguous 64K reads, so you're looking at amortizing 64K of I/O over one of these turnarounds. I think it would be nice to group things into two sections: one for, say, Adaptec 1542b, and one for disk on top of it. From Michael's previous message, this looks like PDRV and half of XPT in one process (up to the part where the routing decision is made), and the rest of XPT plus the CAM in the lower process. I don't know how QNX breaks up their SCSI support; Plan9 is a traditional monolithic kernel for purposes of I/O architecture. Booting is really not a problem. You can load in the necessary CAM and PDRV from the boot.lst. If you end up needing to boot elsewhere, you just edit your boot.lst and pick a different CAM. I can see no need for a "mother of all CAM" servers. I think I'm going to write a message on the boot process for VSTa, so we can all talk about it without requiring everybody to do a massive code read first. >One other thought - could you go over the various components and what they're >supposed to do again? Can any of them be combined into a single driver >without losing configurability? CAM - Adaptor-specific management XPT - "Transport" layer. Apparently routes between PDRV and a CAM PDRV - Disk/tape/etc. code for creating SCSI commands My hope is that XPT can be boiled down to choosing where to connect from PDRV to CAM, and thus doesn't need to be a distinct process. I don't understand its functionality well enough to comment on if this would work... Mike? Andy From vandys@cisco.com Wed Sep 15 10:31:23 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24617; Wed, 15 Sep 93 10:31:22 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22067; Wed, 15 Sep 93 10:36:58 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25595(netkeeper.sj.nec.com ); Wed, 15 Sep 93 10:36:51 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA12534(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 10:36:48 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA12160 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 10:26:00 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00080); Wed, 15 Sep 93 10:20:03 -0700 Received: from localhost by glare.cisco.com with SMTP id AA03699 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 10:00:15 -0700 Message-Id: <199309151700.AA03699@glare.cisco.com> To: vsta@cisco.com Subject: How VSTa boots Date: Wed, 15 Sep 1993 10:00:14 -0700 From: Andrew Valencia Status: OR This is an overview of the booting process for VSTa. It covers the booting process from boot.exe through the login: prompt. 1. Load kernel and server images VSTa is booted from DOS using a large-model DOS program called boot.exe. boot.exe takes a single argument which is the kernel image to load. It opens this file using the usual DOS calls, and reads the image into free memory just after the end of boot.exe's memory. It also zeroes out the BSS portion. boot.exe now opens boot.lst, and reads in a list of files, one per line. For each file, boot.exe opens the file and reads its a.out image into successive memory just after the end of the kernel memory image. After this process, low memory looks like this: | DOS | boot.exe | kernel | cons | keybd | wd | dos | ... +-------------------------------------------------------- 0 -> 2. Build bootstrap 386 32-bit protected mode data structures The i386 defines numerous arcane data structures which need to be present to switch from 16-bit real mode to 32-bit protected mode. These data structures must remain intact throughout the gyrations needed to get VSTa running, until VSTa is sufficiently "up" to take over with its own data structures. If these structures were tacked onto the end of low memory (from our picture, after "dos"), there would be a danger that they would be overwritten by VSTa data structures during bootup. Therefore, these structures are allocated at the top of low memory, from 640K coming down. ... | Copy() | GDT | TSS16 | TSS32 | Data-L2PTEs | Text-L2PTEs | L1PTEs | Stack - ------------------------------------------------------------------------------+ <- 640K "Stack" is a single page of memory used as a stack while switching modes. The top couple of words contain parameters which DOS passes to the VSTA kernel. These are the size of the kernel plus all boot servers, size of extended memory, size of base memory, and the address at which the kernel was loaded. L1PTEs is the root of the page tables (CR3), and Text and Data PTEs are the the second level PTEs. Text maps memory 1:1, and Data maps the a.out data virtual address (4 Mb) onto the data memory for the kernel image loaded in low memory. GDT, TSS16, and TSS32 are the data structures for describing the 32-bit text and data segments, as well as the 32-bit task (used to enter 32-bit mode). Copy() is some position-independent 16-bit code which is the last 16-bit code executed during bootup of VSTa. The VSTa kernel image was loaded above boot.exe's memory, but the VSTa kernel expects to run from a 0 base. Copy() disables interrupts, copies the VSTa kernel down to physical memory starting at 0, switches into protected mode, and jumps through the 32-bit TSS to becomes a 32-bit task running in the VSTa kernel's locore.s at _start. 3. Initial VSTa instructions VSTa first pops the four DOS parameters off its stack. It switches to its own stack, and calls main(). We are now running in C code. main() will call a number of init routines, discussed below. init_machdep() handles the grotty intial setup of memory. It uses the DOS-passed parameters, and sets up machine-independent descriptions of the memory available. It also scans the images of the boot servers which were concatentated onto the end of the kernel image, and builds a machine- independent description of them. This description will be used soon to create the initial processes which allow VSTa to boot. Finally, init_machdep() sets up its own level 1 and 2 page tables, and switches to them. At this point, VSTa is now able to manage its own virtual memory. It calls init_trap() to complete machine-dependent initialization with the initialization of the interrupt system. 4. Further initialization init_trap() creates a GDT (and null LDT, as only the GDT is used). It sets the PC interrupt controller to a mode compatible with protected mode, and puts together an IDT (interrupt descriptor table). By default, each interrupt slot is hooked to a routine which will push the trap ID, and call the common interrupt code. init_trap() then uses a table to override this default action with calls to more appropriate routines. For instance, the page fault vector is rewired to call the page fault handler. The system call vector is hooked to the system call handler. Next, init_page() and init_malloc() are called to set up the hardware-independent parts of the VM system. After these, the general- purpose memory routines can be used to allocate, free, and map memory. init_qio() and init_sched() set up the queued I/O facility and the scheduler. init_proc() now takes the list of boot servers found in init_machdep(), and creates a new process for each server, with its state set to RUN. After this routine, VSTa has a process for each boot server, with each server flagged as waiting to run. init_msg(), init_swap(), init_wire() all initialize various other machine-independent parts of the system. start_clock() enables the PC clock and also enables interrupts. From here, the clock will tick and system time will advance. main() finishes by calling swtch(), which will never return. 5. Running swtch() enters the scheduler. The current "process" (which isn't really, but it's close enough for the scheduler) releases the CPU, and swtch() hunts for a new process to run. It finds the first of the boot servers, switches to its context, and "returns" to user mode (which will be at the first instruction in the a.out). VSTa is now "up", and all further system activity will be handled by VSTa through the usual services of memory management, message passing, scheduling, and so forth. Regards, Andy From jont@hsa.com.au Wed Sep 15 19:26:05 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27118; Wed, 15 Sep 93 19:26:04 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23594; Wed, 15 Sep 93 19:31:45 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02761(netkeeper.sj.nec.com ); Wed, 15 Sep 93 19:31:39 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00636(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 19:31:35 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA24754 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 19:23:46 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00396); Wed, 15 Sep 93 19:18:27 -0700 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA24745 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 19:21:47 -0700 Received: by warrane.connect.com.au with UUCP id AA14492 (5.67a+/IDA-1.5 for vsta@cisco.com); Thu, 16 Sep 1993 12:21:43 +1000 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA01104 (5.65c/IDA-1.5 for ); Thu, 16 Sep 1993 11:01:50 +1000 From: Jonathon Tidswell Message-Id: <199309160101.AA01104@hsa.hsa.com.au> Subject: Re: CAM To: vsta@cisco.com Date: Thu, 16 Sep 1993 10:58:26 +1000 (EST) Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1668 Status: OR Andrew Valencia wrote: > > [Pat Mackinlay writes:] > > >Any idea what Plan9 or QNX do? Andy? I'm not sure, but I would have thought > >that a few context switches wasn't much compared to the speed of reading > >a reasonable amount of data from disk. Perhaps a good serve of blocking > >and buffering will reduce the impact? > > My filesystem will definitely be able to do contiguous 64K reads, so you're > looking at amortizing 64K of I/O over one of these turnarounds. I think > it would be nice to group things into two sections: one for, say, Adaptec > 1542b, and one for disk on top of it. From Michael's previous message, [ ... ] Page faults are 4K ? Making use of 64K reads will require a fine balance between VM management and disk buffer management as well as some clever read-ahead. > >One other thought - could you go over the various components and what they're > >supposed to do again? Can any of them be combined into a single driver > >without losing configurability? > > CAM - Adaptor-specific management SIM is the adaptor stuff, while CAM is the overall architecture. > XPT - "Transport" layer. Apparently routes between PDRV and a CAM > PDRV - Disk/tape/etc. code for creating SCSI commands > > My hope is that XPT can be boiled down to choosing where to connect > from PDRV to CAM, and thus doesn't need to be a distinct process. > I don't understand its functionality well enough to comment on if > this would work... Mike? I hope that most of XPT and SIM can be joined as most systems will have more PDRV than SIM. [ 1 HBA, and several types of SCSI devices. ] JonT PS Andrew thanks for the post on booting. From myl@genrad.com Wed Sep 15 19:42:10 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27124; Wed, 15 Sep 93 19:42:09 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23628; Wed, 15 Sep 93 19:47:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02900(netkeeper.sj.nec.com ); Wed, 15 Sep 93 19:47:44 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00662(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 19:47:41 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA24939 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 19:40:12 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00405); Wed, 15 Sep 93 19:35:09 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA24924 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 19:38:33 -0700 Received: by genrad.com (5.57) id AA21290; Wed, 15 Sep 93 22:38:24 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA06891; Wed, 15 Sep 93 22:38:22 EDT Date: Wed, 15 Sep 93 22:38:22 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309160238.AA06891@bronco.genrad.com> To: vsta@cisco.com Subject: Re: CAM Status: OR Andrew Valencia writes: > CAM - Adaptor-specific management ^^^ SIM > XPT - "Transport" layer. Apparently routes between PDRV and a CAM > PDRV - Disk/tape/etc. code for creating SCSI commands > > My hope is that XPT can be boiled down to choosing where to connect > from PDRV to CAM, and thus doesn't need to be a distinct process. ^^^ SIM > I don't understand its functionality well enough to comment on if > this would work... Mike? Please replace "CAM" with "SIM" in most places in your article. The SIM's (SCSI Interface Modules) are responsible for adaptor-specific management. I think that while the XPT should be a distinct process, it doesn't need to be in the path of most I/O transactions. The reason that the XPT should be a distinct process is that it owns several tables, including a table of SIM's currently running and a device table. Also, the XPT layer interfaces to both the PDRV's (eg, send a CCB to the appropriate SIM) and the SIM's (eg, tell the XPT I'm here). As for SCSI requests, each PDRV sends a CCB to the appropriate SIM via a function called xpt_action(). Now, xpt_action() could send the CCB to the XPT process, and let the XPT process send the CCB to the corresponding SIM. On the other hand, xpt_action() could contain a read only copy of the XPT processes tables and route the request directly, bypassing the XPT process. On the way back, the completion "callback" would normally bypass the XPT layer anyway. > My filesystem will definitely be able to do contiguous 64K reads, so you're > looking at amortizing 64K of I/O over one of these turnarounds. ... Is this data copied, or, as Jonathon (jont@hsa.com.au) suggested previously, is the associated buffer shared among the servers in the I/O path? Mike Larson From vandys@cisco.com Wed Sep 15 20:37:05 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27140; Wed, 15 Sep 93 20:37:04 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23751; Wed, 15 Sep 93 20:42:45 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03465(netkeeper.sj.nec.com ); Wed, 15 Sep 93 20:42:40 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00702(archimedes.inoc.sj.nec.com ); Wed, 15 Sep 93 20:42:37 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA25527 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 20:36:43 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00435); Wed, 15 Sep 93 20:31:59 -0700 Received: from localhost by glare.cisco.com with SMTP id AA10755 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 20:35:24 -0700 Message-Id: <199309160335.AA10755@glare.cisco.com> To: myl@genrad.com (Michael A. Larson) Cc: vsta@cisco.com Subject: Re: CAM In-Reply-To: Your message of "Wed, 15 Sep 1993 22:38:22 EDT." <9309160238.AA06891@bronco.genrad.com> Date: Wed, 15 Sep 1993 20:35:24 -0700 From: Andrew Valencia Status: OR [myl@genrad.com (Michael A. Larson) writes:] >I think that while the XPT should be a distinct process, it doesn't >need to be in the path of most I/O transactions. The reason that the >XPT should be a distinct process is that it owns several tables, >including a table of SIM's currently running and a device table. Also, >the XPT layer interfaces to both the PDRV's (eg, send a CCB to the >appropriate SIM) and the SIM's (eg, tell the XPT I'm here). Are you sure this functionality couldn't be subsumed by some conventions in the use of the /namer name space? >As for SCSI requests, each PDRV sends a CCB to the appropriate SIM via >a function called xpt_action(). Now, xpt_action() could send the CCB to >the XPT process, and let the XPT process send the CCB to the >corresponding SIM. On the other hand, xpt_action() could contain a read >only copy of the XPT processes tables and route the request directly, >bypassing the XPT process. On the way back, the completion "callback" >would normally bypass the XPT layer anyway. But the selection of SIM is a static answer for a particular instance of a PDRV, isn't it? So why couldn't have look it up once, via namer, open a port to the right SIM server process, and thus make it unnecessary to have a third process? >Is this data copied, or, as Jonathon (jont@hsa.com.au) suggested >previously, is the associated buffer shared among the servers in the >I/O path? Servers receive messages by having them mapped into the server address space (more accurately, a view is attached, but the actual pages are mapped on demand). If the server does not touch this data, but sends a message on to another server, then the memory is never referenced or mapped in the intermediate server. My filesystem uses variable-length buffers for its buffer cache. The buffer size is related to the size of the next extent in the file being accessed. Thus, when vstafs send a read request, the page view for the entire buffer would be passed through until it reaches the server who actually stuffs the bytes into the buffer. His writes go into the actual buffer memory of the filesystem; there are no intermediate copies. Programmed I/O, like the WD driver, behaves this way. True DMA devices require the extra step that each page must be wired and its physical address found. The floppy driver does this one page at a time; if you have a device with scatter/gather DMA, you might wire multiple pages. Gee, I'm feeling professorly today! :-) Andy From myl@genrad.com Thu Sep 16 08:27:39 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06605; Thu, 16 Sep 93 08:27:37 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA25373; Thu, 16 Sep 93 08:33:19 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10157(netkeeper.sj.nec.com ); Thu, 16 Sep 93 08:33:13 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01415(archimedes.inoc.sj.nec.com ); Thu, 16 Sep 93 08:33:12 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA05150 (5.67a/IDA-1.5 for ); Thu, 16 Sep 1993 08:27:09 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00948); Thu, 16 Sep 93 08:22:20 -0700 Received: from genrad.com (genrad.genrad.com) by hubbub.cisco.com with SMTP id AA05112 (5.67a/IDA-1.5 for ); Thu, 16 Sep 1993 08:25:47 -0700 Received: by genrad.com (5.57) id AA03346; Thu, 16 Sep 93 11:25:34 -0400 Received: by bronco.genrad.com (4.1/SMI-3.2) id AA08020; Thu, 16 Sep 93 11:25:31 EDT Date: Thu, 16 Sep 93 11:25:31 EDT From: myl@genrad.com (Michael A. Larson) Message-Id: <9309161525.AA08020@bronco.genrad.com> To: vsta@cisco.com Subject: Re: CAM Status: OR Andrew Valencia writes: > But the selection of SIM is a static answer for a particular instance > of a PDRV, isn't it? So why couldn't have look it up once, via namer, > open a port to the right SIM server process, and thus make it unnecessary > to have a third process? The data may not be static, and the XPT layer may be active during CAM operation. In addition to routing CCB's, the XPT layer has the following responsibilities: 1) register/deregister SIM's. Note that a SIM could be registered and deregisterd many times. For example, SIM driver writers would do this during development. 2) determine what devices are connected to each host adaptor. 3) do asynchronous callbacks to the PDRV's. Asynchronous callbacks can occur, for example, when SIM's are registered/deregistered, when an unsolicited reslection or bus reset occurs, etc. So, the XPT layer needs to be around in some form while CAM is operating. Now, we've been presented w/ two alternatives as to where to put XPT: Option 1: Jonathon Tidswell writes: > I hope that most of XPT and SIM can be joined as most systems will have more > PDRV than SIM. [ 1 HBA, and several types of SCSI devices. ] As long as there is just one SIM (ie, one host adaptor type), this should work. If, however, there is more than one SIM, then you would have to "chain" SIM's. That is, the XPT part of the first SIM process would have to determine if a particular CCB is one it should handle. If it isn't, the CCB would be passed to the next SIM (process) in the chain, and so on. Note that CAM-for-DOS is specified to work this way. Option 2: As I wrote previously, there would be a separate XPT process. However, the tables that the process maintains would be "exported" (possibly through /namer) so that the XPT process would not be in the path of SCSI I/O CCB's. Mike Larson From mackinla@cs.curtin.edu.au Thu Sep 16 12:17:42 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10447; Thu, 16 Sep 93 12:17:41 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26002; Thu, 16 Sep 93 12:23:25 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04983(netkeeper.sj.nec.com ); Thu, 16 Sep 93 12:23:19 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02135(archimedes.inoc.sj.nec.com ); Thu, 16 Sep 93 12:23:13 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA12327 (5.67a/IDA-1.5 for ); Thu, 16 Sep 1993 12:10:43 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA01053); Thu, 16 Sep 93 12:04:47 -0700 Received: from marsh.cs.curtin.edu.au by hubbub.cisco.com with SMTP id AA12248 (5.67a/IDA-1.5 for ); Thu, 16 Sep 1993 12:08:16 -0700 Received: from lillee.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA22036 (5.67a/IDA-1.5); Fri, 17 Sep 1993 03:08:54 +0800 Received: by lillee.cs.curtin.edu.au id AA19757 (5.67a/IDA-1.4.4); Fri, 17 Sep 1993 03:08:53 +0800 From: Pat Mackinlay Message-Id: <199309161908.AA19757@lillee.cs.curtin.edu.au> Subject: WD patch... To: vsta@cisco.com Date: Fri, 17 Sep 1993 03:08:51 +0800 (WST) Cc: vandys@cisco.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1835 Status: OR As promised, I've done a little work on the WD server, with quite useful results. Basically, the other "kludge" parameters should no longer be needed when running the server at startup. I hope that a simple: ../wd/wd d0:readp d1:readp will work for everyone's disks - it works for mine. The patch is pretty straightforward, enjoy. ---[begin included patch]--- --- c:\unix\tmp/T0AA.AAA Fri Sep 17 02:42:18 1993 +++ wd.c Fri Sep 17 02:39:04 1993 @@ -161,8 +161,9 @@ uint s = parm[unit].w_size * SECSZ; const uint m = 1024*1024; - printf("wd%d: %d.%dM\n", unit, - s / m, (s % m) / (m/10)); + printf("wd%d: %d.%dM - %d heads, %d cylinders, %d sectors\n", unit, + s / m, (s % m) / (m/10), + parm[unit].w_tracks, parm[unit].w_cyls, parm[unit].w_secpertrk); found_first = 1; if (unit < first_unit) { first_unit = unit; @@ -460,6 +461,17 @@ } repinsw(WD_PORT+WD_DATA, buf, sizeof(buf)/sizeof(ushort)); bcopy(buf, &xw, sizeof(xw)); + + /* + * Give the controller the geometry. I'm not really sure why my + * drive needs the little delay, but it did... (pat) + */ + __msleep(100); + outportb(WD_PORT+WD_SDH, WDSDH_EXT|WDSDH_512 | (unit << 4) | (xw.w_heads - 1)); + outportb(WD_PORT+WD_SCNT, xw.w_sectors); + if (wd_cmd(WDC_SPECIFY) < 0) { + return; + } /* * Fix big-endian lossage --- c:\unix\tmp/T0AA.AAA Fri Sep 17 02:42:24 1993 +++ wd.h Mon Sep 13 01:31:54 1993 @@ -60,6 +60,7 @@ #define WDC_WRITE 0x30 /* ...write */ #define WDC_READP 0xEC /* ...read parameters */ #define WDC_DIAG 0x90 /* Run controller diags */ +#define WDC_SPECIFY 0x91 /* Initialise controller parameters */ /* * Read parameters command (WDC_READP) returns this. I think this ---[end included patch]--- -- Pat -- Alien lands on head, gives birth to mutant. From vandys@cisco.com Fri Sep 17 07:49:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17479; Fri, 17 Sep 93 07:49:26 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29007; Fri, 17 Sep 93 07:55:16 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17893(netkeeper.sj.nec.com ); Fri, 17 Sep 93 07:55:10 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04161(archimedes.inoc.sj.nec.com ); Fri, 17 Sep 93 07:55:08 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02719 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 07:48:56 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00402); Fri, 17 Sep 93 07:43:17 -0700 Received: from localhost by glare.cisco.com with SMTP id AA23822 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 07:46:55 -0700 Message-Id: <199309171446.AA23822@glare.cisco.com> To: jyl@toss.Eng.Sun.COM Cc: vsta@cisco.com Subject: Re: CAM In-Reply-To: Your message of "Wed, 15 Sep 1993 09:16:50 PDT." <9309151616.AA18075@toss.Eng.Sun.COM> Date: Fri, 17 Sep 1993 07:46:55 -0700 From: Andrew Valencia Status: OR [jyl@toss.Eng.Sun.COM (Jacob Levy) writes:] >Has anyone looked into the Spring fastcall mechanism? I advertized some >publicly available Spring papers on this list a while back. One of them >describes a mechanism for doing extremely fast cross address space calls >which might address Jon's concerns. Yes, I sent a request, and have not heard back on E-mail nor received any papers. Andy From jyl@toss.Eng.Sun.COM Thu Sep 16 22:04:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11643; Thu, 16 Sep 93 22:04:15 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27664; Thu, 16 Sep 93 22:10:02 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12182(netkeeper.sj.nec.com ); Thu, 16 Sep 93 22:09:56 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03483(archimedes.inoc.sj.nec.com ); Thu, 16 Sep 93 22:09:55 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA25377 (5.67a/IDA-1.5 for ); Thu, 16 Sep 1993 22:01:56 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00140); Thu, 16 Sep 93 21:56:55 -0700 Received: from Sun.COM by hubbub.cisco.com with SMTP id AA10472 (5.67a/IDA-1.5 for ); Wed, 15 Sep 1993 09:17:05 -0700 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03374; Wed, 15 Sep 93 09:16:52 PDT Received: from toss.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29303; Wed, 15 Sep 93 09:16:53 PDT Received: from burgess.Eng.Sun.COM by toss.Eng.Sun.COM (4.1/SMI-4.1) id AA18075; Wed, 15 Sep 93 09:16:50 PDT Date: Wed, 15 Sep 93 09:16:50 PDT From: jyl@toss.Eng.Sun.COM (Jacob Levy) Message-Id: <9309151616.AA18075@toss.Eng.Sun.COM> Received: by burgess.Eng.Sun.COM (4.1/SMI-4.1) id AA04380; Wed, 15 Sep 93 09:18:49 PDT To: jont@hsa.com.au Cc: vsta@cisco.com In-Reply-To: <199309150816.AA28917@hsa.hsa.com.au> Subject: Re: CAM Reply-To: jyl@toss.Eng.Sun.COM Status: OR >Im a little apprehensive about having 4 processes between a disk read and the >disk: >client ==> disk-FS ==> PDRV ==> XPT ==> SIM ==> disk >[ and back - though this MAY be shorter ] >aNoting that each one is a context switch even if the data is 'copied' >using VM mappings, the registers and VM mapping must be saved and flushed etc Has anyone looked into the Spring fastcall mechanism? I advertized some publicly available Spring papers on this list a while back. One of them describes a mechanism for doing extremely fast cross address space calls which might address Jon's concerns. --JYL From jont@hsa.com.au Fri Sep 17 19:21:57 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27155; Fri, 17 Sep 93 19:21:57 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01031; Fri, 17 Sep 93 19:27:49 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17534(netkeeper.sj.nec.com ); Fri, 17 Sep 93 19:27:43 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05873(archimedes.inoc.sj.nec.com ); Fri, 17 Sep 93 19:27:40 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA21129 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 19:20:32 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00856); Fri, 17 Sep 93 19:15:40 -0700 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA21111 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 19:19:07 -0700 Received: by warrane.connect.com.au with UUCP id AA18679 (5.67a+/IDA-1.5 for vsta@cisco.com); Sat, 18 Sep 1993 12:18:46 +1000 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA08405 (5.65c/IDA-1.5 for ); Sat, 18 Sep 1993 12:14:36 +1000 From: Jonathon Tidswell Message-Id: <199309180214.AA08405@hsa.hsa.com.au> Subject: help with dos boot strapping environment ? To: vsta@cisco.com Date: Sat, 18 Sep 1993 12:11:12 +1000 (EST) Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 536 Status: OR A few pointers would be appreciated. I nearly had things running smoothly, until djgpp's patch corrupted half a dozen files (14) including the vsta rcs source and the djgcc files. When I attempted to recreate things from floppy I didnt manage to get the environment working properly :-( Also djtarx does not like untaring unix tar files with directories so I cant use patch under unix. Can someone point me to a reliable set of tools for $%-^!@ bootstrapping ? [ I dont really want to buy MKS just to bootstrap vsta. ] thanks JonT From vandys@cisco.com Fri Sep 17 19:29:21 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27169; Fri, 17 Sep 93 19:29:20 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01059; Fri, 17 Sep 93 19:35:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17578(netkeeper.sj.nec.com ); Fri, 17 Sep 93 19:35:06 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05892(archimedes.inoc.sj.nec.com ); Fri, 17 Sep 93 19:35:01 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA21217 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 19:28:41 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00860); Fri, 17 Sep 93 19:23:13 -0700 Received: from localhost by glare.cisco.com with SMTP id AA00660 (5.67a/IDA-1.5 for ); Fri, 17 Sep 1993 19:26:56 -0700 Message-Id: <199309180226.AA00660@glare.cisco.com> To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: help with dos boot strapping environment ? In-Reply-To: Your message of "Sat, 18 Sep 1993 12:11:12 +1000." <199309180214.AA08405@hsa.hsa.com.au> Date: Fri, 17 Sep 1993 19:26:55 -0700 From: Andrew Valencia Status: OR [Jonathon Tidswell writes:] >Can someone point me to a reliable set of tools for $%-^!@ bootstrapping ? Yes, I have to apologize for this. I recently was out in the Internet world and pulled stuff down to set up their 386 box. It was a lot harder than I expected, and I have new respect for you folks who have gotten VSTa running! I will be pulling together a tool set so that you can FTP everything needed from one place; version 1.1 should coincide with this. I've mostly been spending time on my filesystem, getting large files working. With that out of the way, I will incorporate the WD patches, reorganize the filesystem to better reflect the relationship between various parts of the source, pull in any ports you folks want to provide, and then offer v1.1. Regards, Andy From vandys@cisco.com Mon Sep 20 08:35:06 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14600; Mon, 20 Sep 93 08:35:05 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09029; Mon, 20 Sep 93 08:41:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27442(netkeeper.sj.nec.com ); Mon, 20 Sep 93 08:41:05 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08722(archimedes.inoc.sj.nec.com ); Mon, 20 Sep 93 08:41:02 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA13900 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 08:27:37 -0700 Received: from glare.cisco.com by amri.cisco.com (AA01168); Mon, 20 Sep 93 08:22:05 -0700 Received: from localhost by glare.cisco.com with SMTP id AA05495 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 08:26:09 -0700 Message-Id: <199309201526.AA05495@glare.cisco.com> To: Pat Mackinlay Cc: vsta@cisco.com Subject: Re: help with dos boot strapping environment ? In-Reply-To: Your message of "Mon, 20 Sep 1993 13:48:35 +0800." <199309200548.AA07958@vincent.cs.curtin.edu.au> Date: Mon, 20 Sep 1993 08:26:08 -0700 From: Andrew Valencia Status: OR [Pat Mackinlay writes:] >I can confirm the same behaviour. I don't know where the tarfiles came from >in the first place, but it won't create directories for me... What a pain! I have used a port of GNU tar for DOS quite successfully. Could you folks try this out? It's available: cs.ubc.ca:/mirror4/msdos/dskutl/aspibin.zip This is GNU tar with support for SCSI tape using the ASPI driver interface. But it also works fine as a generic tar. I will switch to recommending this if you folks have luck with it. Thanks, Andy From vandys@cisco.com Mon Sep 20 10:01:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15645; Mon, 20 Sep 93 10:01:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09267; Mon, 20 Sep 93 10:07:40 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA20326(netkeeper.sj.nec.com ); Mon, 20 Sep 93 10:07:32 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08960(archimedes.inoc.sj.nec.com ); Mon, 20 Sep 93 10:07:29 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA16349 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 09:56:58 -0700 Received: from glare.cisco.com by amri.cisco.com (AA01264); Mon, 20 Sep 93 09:51:14 -0700 Received: from localhost by glare.cisco.com with SMTP id AA27936 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 09:55:18 -0700 Message-Id: <199309201655.AA27936@glare.cisco.com> To: vsta@cisco.com Subject: tar.exe which works Date: Mon, 20 Sep 1993 09:55:17 -0700 From: Andrew Valencia Status: OR ftp.cs.ubc.ca:/mirror4/msdos/dskutl/aspibin.zip tar -xvf foo.t Works for all the tars I've been able to generate. Andy From nick@nsis.cl.nec.co.jp Mon Sep 20 16:08:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26085; Mon, 20 Sep 93 16:08:48 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10531; Mon, 20 Sep 93 16:14:57 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24873(netkeeper.sj.nec.com ); Mon, 20 Sep 93 16:14:49 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA10204(archimedes.inoc.sj.nec.com ); Mon, 20 Sep 93 16:14:44 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA27720 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 16:08:05 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA01429); Mon, 20 Sep 93 16:01:49 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA27679 (5.67a/IDA-1.5 for ); Mon, 20 Sep 1993 16:05:58 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA17650; Tue, 21 Sep 1993 08:05:55 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA15111; Tue, 21 Sep 1993 08:05:54 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930914.1) id AA01672; Tue, 21 Sep 1993 08:05:53 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA17586; Tue, 21 Sep 93 08:05:52 JST Date: Tue, 21 Sep 93 08:05:52 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309202305.AA17586@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: help with dos boot strapping environment ? Status: OR >I was using SVR4.2 (Unixware) on which I had a patched the source files, then >I tarred them up copied them to a dos partition from which I tried to untar >them using djtarx (under MS-DOS 6 not DOS-MERGE). Hmm. SYSV tar doesn't work well for some tar files (even if created under Unix). If you can, use gtar to create and unpack tar files that go to or from DOS. Note that I do not use djtarx. I use a tar called tar4dos (I think). It's OK, except that it hangs if it can't find the tar file specified (it tries to skip ahead on stdin...). I should also metion that the patch supplied with djgpp corrupted some of my files, so that is also something to be careful of. On simtel, there are a lot of unix tools for DOS of varying quality. If you sift through them, you should get what you need. I remember something called picnix that looked good... nick From nick@nsis.cl.nec.co.jp Mon Sep 27 18:08:24 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26042; Mon, 27 Sep 93 18:08:23 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05206; Mon, 27 Sep 93 18:15:15 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07703(netkeeper.sj.nec.com ); Mon, 27 Sep 93 18:15:03 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03164(archimedes.inoc.sj.nec.com ); Mon, 27 Sep 93 18:15:00 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03065 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 18:08:52 -0700 Received: from [198.92.30.32] by amri.cisco.com (AA00802); Mon, 27 Sep 93 18:03:10 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by hubbub.cisco.com with SMTP id AA02130 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 17:22:16 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA07819; Tue, 28 Sep 1993 09:22:12 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA14777; Tue, 28 Sep 1993 09:22:08 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA18683; Tue, 28 Sep 1993 09:22:07 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA15023; Tue, 28 Sep 93 09:22:06 JST Date: Tue, 28 Sep 93 09:22:06 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309280022.AA15023@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Project registry Status: OR Well, this list is quiet. I hope that doesn't mean that everyone has abandoned VSTa. I personally believe that VSTa has great potential to be a free 90's OS (Linux/BSD use much older technology). Anyway, I thought that maybe people don't know what needs to be done, so with that in mind (and if Andy doesn't disagree), I'd like to start a project registry. The basic goals of the project registry will be: 1) To compile a list of things that need to be done. 2) To maintain a list of who's doing what. Here is the current list as I see it. If you are working/want to work on something, or if you have some other ideas, send me some email. I plan to put out an updated list perhaps once a week. ------------------------- Project List -----+------------------------------ TASK | WHO --------------------------------------------+------------------------------ VSTa file system (Non-Unix) | vandys@cisco.com Window System (Non-X11) | nick@nsis.cl.nec.co.jp Update kbd so key mappings can be downloaded| (planned)nick@nsis.cl.nec.co.jp Update wd to handle various IDE drives | ???? Shared libraries | /proc server (for use with ps etc.) | Debugger (using /proc??) | Unix/Linux file systems | Math emulator (inside kernel? server?) | Update/expand libc (and include files) | SCSI disk server | Network server | RS232c server | Porting of applications (make, emacs, ...) | --------------------------------------------+------------------------------- ## The windowing system is coming along. The window system will be similar in spirit to 8.5. It will comprise of 2 servers: bitblt, which performs all graphics operations, and (vista??) which will be the windowing system proper. vista will basically act as a multiplexer for bitblt (it should be able to run within itself I hope). bitblt is nearing pre-alpha. I guess it will be finished around November. I still have to write the font handling sub-system... if anyone in interested in helping out with bitblt, let me know. (In particular, I need someone to port it to the VGA). From sjc@cs.purdue.edu Mon Sep 27 18:25:20 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26065; Mon, 27 Sep 93 18:25:19 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05249; Mon, 27 Sep 93 18:32:12 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07882(netkeeper.sj.nec.com ); Mon, 27 Sep 93 18:31:59 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03217(archimedes.inoc.sj.nec.com ); Mon, 27 Sep 93 18:31:56 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03319 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 18:27:05 -0700 Received: from [198.92.30.32] by amri.cisco.com (AA00815); Mon, 27 Sep 93 18:21:22 -0700 Received: from arthur.cs.purdue.edu by hubbub.cisco.com with SMTP id AA03315 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 18:26:57 -0700 Received: from bredbeddle.cs.purdue.edu by arthur.cs.purdue.edu (5.65c/PURDUE_CS-1.2) id ; Mon, 27 Sep 1993 20:26:55 -0500 Received: from localhost by bredbeddle.cs.purdue.edu (5.65c/PURDUE_CS-1.2) id ; Mon, 27 Sep 1993 20:26:55 -0500 Message-Id: <199309280126.AA08966@bredbeddle.cs.purdue.edu> From: sjc@mcs.kent.edu (Steve Chapin) To: vsta@cisco.com Zevon-Of-The-Day: I'll Sleep When I'm Dead Subject: Re: Project registry In-Reply-To: Your message of Tue, 28 Sep 1993 09:22:06 +0200. <9309280022.AA15023@silk1.nsis.cl.nec.co.jp> Date: Mon, 27 Sep 1993 20:26:54 -0500 Sender: sjc@cs.purdue.edu Status: OR I don't think we've all given up; I haven't really had a chance to begin yet. I'm buying a few x86 workstations to use in a research project based on VSTa, so I certainly don't think it's dead. Unfortunately, university bureaucracies being what they are, it'll probably be at least another month before I see any hardware... Which brings me to a question and a comment. Question: what hard drives are currently supported by VSTa? I noticed that Gavin listed: >> Update wd to handle various IDE drives in his project list, and I want to make sure that the hardware I'm getting will be compatible with VSTa (and Linux, and... :-) The comment: Andy, please update the mailing list so that my address is sjc@mcs.kent.edu. Thanks. sc -- From vandys@cisco.com Mon Sep 27 19:21:55 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26139; Mon, 27 Sep 93 19:21:53 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05381; Mon, 27 Sep 93 19:28:46 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08545(netkeeper.sj.nec.com ); Mon, 27 Sep 93 19:28:32 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03331(archimedes.inoc.sj.nec.com ); Mon, 27 Sep 93 19:28:28 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03990 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:23:13 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00844); Mon, 27 Sep 93 19:17:30 -0700 Received: from localhost by glare.cisco.com with SMTP id AA15191 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:23:06 -0700 Message-Id: <199309280223.AA15191@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Project registry In-Reply-To: Your message of "Tue, 28 Sep 1993 09:22:06 +0200." <9309280022.AA15023@silk1.nsis.cl.nec.co.jp> Date: Mon, 27 Sep 1993 19:23:05 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Well, this list is quiet. I hope that doesn't mean that everyone has >abandoned VSTa. Well, I'll be the last one out the door! :-) I have actually been making progress on my filesystem. Today, I got large files working. A file is structured as: | File header | Extents | Data... So the stuff UNIX would put in inode is actually just the first N bytes of a file. Each extent is merely tuples. The sizes are chosen carefully, so that a 100-byte file occupies a single 512-byte sector, including both file data as well as file ownership, protection, and allocation information. A directory is just a special file, so smaller directories will also occupy a single sector. As a file grows, its existing allocation is extended where possible. So if your file is currently {<3,1>} (i.e., sector three, one sector long), and you write enough data to push out beyond the initial sector, the filesystem will see how many blocks can be had starting at 4. Up to 64K is taken at once, in the hope that taking this much proactively will spare you having to "piecemeal" your file together as you write. Thus, your file could then be {<3,129>}. The file's length is marked to be the entire length of the whole allocation (129*512 = 66048). If you crash, the file thus correctly represents the storage it holds, without fsck being required before filesystem operation is resumed. As you write the file, the filesystem keeps track of the highest offset you have written. On last close, blocks beyond this point are freed, and the file is "shrunk" down to the actual size written. If you wrote a K or so, then closed the file, the example file would end up as {<3,3>}, and 6..129 would return to the free list. The free list uses a sorted linked list of free ranges, with coalescing. Each range is held in a single sector; each sector has a next pointer to another sector's worth of free list ranges. A sector can hold 0 or more entries; if it ever overflows, a global rebalance is done, resulting in each sector being exactly half full (except the last in the list which might hold less). This allows contiguous ranges of free blocks to be easily identified, and is very storage efficient, even with small allocation units (such as sectors). It is also easy to prove that your free list can always represent the total of free blocks, because a block on the free list can be consumed to provide another sector's worth of storage for the free list. Bitmaps are popular for free block management, but their size grows as a function of increasing filesystem size and decreasing allocation unit size. Most implementations either take a larger allocation size--say, 8K--and waste disk space for smaller files, or add tremendous complexity to special-case sub-allocation-size units (i.e., "frags" in the BSD filesystem). VSTa is primarily an experimental platform, so I decided to try something different. The most complex part of the filesystem is the block cache. This is a misnomer; each entry in the buffering system is variably-sized. For an extent of up to 64K, a buffer of the exact size is kept. For larger extents, the extent is buffered in 64K chunks. Between the contiguous block allocation and the variable-size buffer, I hope to provide very efficient filesystem services. Consider a file with allocation {<10,8>} (i.e., a file starting at sector 10 for 8 sectors--4K). When this file is opened and read, a 4K buffer is allocated. A single disk I/O fills the entire 4K. Thus, most small files will have their entire contents buffered in a single disk I/O. Larger files will have their contents buffered in chunks of 64K. Once the file contents are in the filesystem's buffer, it may be parcelled out to clients without further I/O activity. This scheme should work well for text files, objects, and some executables. It will not work well for, say, databases. They would do better to talk directly to a disk partition, or through a similar, but non-buffered version of this filesystem. My initial prototype will also not protect itself well against multiple, competing allocation requests. I hope to incrementally improve this as I learn more from actual use. Regards, Andy Valencia From nick@nsis.cl.nec.co.jp Mon Sep 27 19:36:59 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26194; Mon, 27 Sep 93 19:36:58 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05431; Mon, 27 Sep 93 19:43:51 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08755(netkeeper.sj.nec.com ); Mon, 27 Sep 93 19:43:38 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03377(archimedes.inoc.sj.nec.com ); Mon, 27 Sep 93 19:43:35 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA04160 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:37:09 -0700 Received: from [198.92.30.32] by amri.cisco.com (AA00859); Mon, 27 Sep 93 19:31:28 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA04152 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:36:56 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA17642; Tue, 28 Sep 1993 11:36:34 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA20809; Tue, 28 Sep 1993 11:36:32 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA25750; Tue, 28 Sep 1993 11:36:31 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA17917; Tue, 28 Sep 93 11:36:30 JST Date: Tue, 28 Sep 93 11:36:30 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309280236.AA17917@silk1.nsis.cl.nec.co.jp> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Mon, 27 Sep 1993 19:23:05 -0700 <199309280223.AA15191@glare.cisco.com> Subject: Project registry Status: OR >>Well, this list is quiet. I hope that doesn't mean that everyone has >>abandoned VSTa. > >Well, I'll be the last one out the door! :-) I wouldn't bet on it. I'll be here as long as I have net access, and working on VSTa even if I didn't have net access. [A lot of interesting stuff about the file system deleted] Well, it sounds really good. I'm looking forward to using it. One thing I'd like to see improved after this would be the stream io in libc. I think it presents something of a bottleneck for programs that use it. Has anyone though about adding something like sfio to VSTa? (sfio is a completely different (and better!) stream io library for unix. I also has the advantage of having a stdio compatibility library). nick From vandys@cisco.com Mon Sep 27 19:34:05 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26160; Mon, 27 Sep 93 19:34:04 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05421; Mon, 27 Sep 93 19:40:57 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08663(netkeeper.sj.nec.com ); Mon, 27 Sep 93 19:40:45 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03361(archimedes.inoc.sj.nec.com ); Mon, 27 Sep 93 19:40:41 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA04144 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:36:14 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00854); Mon, 27 Sep 93 19:30:32 -0700 Received: from localhost by glare.cisco.com with SMTP id AA15628 (5.67a/IDA-1.5 for ); Mon, 27 Sep 1993 19:36:07 -0700 Message-Id: <199309280236.AA15628@glare.cisco.com> To: sjc@mcs.kent.edu (Steve Chapin) Cc: vsta@cisco.com Subject: Re: Project registry In-Reply-To: Your message of "Mon, 27 Sep 1993 20:26:54 CDT." <199309280126.AA08966@bredbeddle.cs.purdue.edu> Date: Mon, 27 Sep 1993 19:36:07 -0700 From: Andrew Valencia Status: OR [sjc@mcs.kent.edu (Steve Chapin) writes:] >Which brings me to a question and a comment. Question: what hard >drives are currently supported by VSTa? I noticed that Gavin listed: >>> Update wd to handle various IDE drives Well, I think he means that I have a couple pending patches from contributors, and I need to figure out how best to handle IDE and ST-506 drives. In fact, I'm not aware of anybody who currently has a non-usable IDE drive. One of the patches is for a controller which could not auto-step heads, but otherwise the WD driver seems to do pretty well. The biggest problem is putting together a set of tools which will build the system. I intend to publish all the needed support tools with the next release--make seems to be the biggest stumbling block, followed by gzip and tar. I won't offer a copy of djgpp, due to size, but I will provide a pointer to a repository. Andy From nick@nsis.cl.nec.co.jp Wed Sep 29 02:32:41 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08211; Wed, 29 Sep 93 02:32:38 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02180; Wed, 29 Sep 93 02:39:27 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22624(netkeeper.sj.nec.com ); Wed, 29 Sep 93 02:39:26 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06638(archimedes.inoc.sj.nec.com ); Wed, 29 Sep 93 02:39:24 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA06596 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 02:30:07 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00314); Wed, 29 Sep 93 02:06:32 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA06438 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 02:12:17 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA07155; Wed, 29 Sep 1993 17:56:27 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA15106; Wed, 29 Sep 1993 17:56:23 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA06643; Wed, 29 Sep 1993 17:56:20 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA13989; Wed, 29 Sep 93 17:56:18 JST Date: Wed, 29 Sep 93 17:56:18 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309290856.AA13989@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: I need a *fast* integer sqrt() Status: OR Does anyone have one? If possible, it should be small an simple enough that I could include it into the body of a function. It should work with values of up to 0xffffffff if possible, though one which could handle values of up to 0xfffff would be nice. Negative numbers need not be considered. (I need this to do a fast tile fill of a circle, and I'm not happy with the performance of what I came up with... I do it by a divsion by 2, then a loop calculating, and subtracting a delta. I feel there should be some way of exploiting the bit patterns in integers, but I can't see *how*.) nick From vandys@cisco.com Wed Sep 29 09:35:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15022; Wed, 29 Sep 93 09:35:02 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03376; Wed, 29 Sep 93 09:41:50 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05489(netkeeper.sj.nec.com ); Wed, 29 Sep 93 09:41:49 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07470(archimedes.inoc.sj.nec.com ); Wed, 29 Sep 93 09:41:46 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA15784 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 09:31:33 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00198); Wed, 29 Sep 93 09:23:47 -0700 Received: from localhost by glare.cisco.com with SMTP id AA06522 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 09:29:43 -0700 Message-Id: <199309291629.AA06522@glare.cisco.com> To: vsta@cisco.com Subject: Other changes a'coming Date: Wed, 29 Sep 1993 09:29:42 -0700 From: Andrew Valencia Status: OR I have converted to the use of pdmake. Besides being public domain, it is small (20K .exe) with ~2K lines for the whole source. The only change required was to omit I/O redirection from any make commands. I will distribute pdmake along with the next source drop. I will also be porting it to VSTa. The source tree could use some restructuring. I'm something of a minimalist, so here are the minimal changes I see needed: Move mach/, kern/, and make/ into their own os/ subdirectory Move all machine-independent servers (dos, pipe, tmpfs, etc.) into a srv/ subdir. Move machine-dependent servers (wd, kbd, etc.) into srv/mach. Create a doc/ subdir. Move all non-legal text files here, and add some new ones (including, perhaps, copies of the various explanations I've posted). Leave include/, lib/, and libc/ where they are. These are all shared between kernel, servers, and binaries, so their position should be common to all three. People perhaps think mach/ should be named i386isa/ or something. I agree, but there's a method to my madness. I want everything to use mach/, with the assumption that it will be linked to the right thing for the given machine. Currently, DOS doesn't have symbolic or environment links. VSTa can do both (well, it doesn't NOW, but I know how to make it do them). When we cut to a native build environment, the files will "really" live in i386isa, and mach/ will probably be an environment link: ln -s /vsta/os/mach /vsta/os/@MACH@@ARCH@ where MACH and ARCH are "i386" and "isa", respectively, from the env server. Comments? Andy From nick@nsis.cl.nec.co.jp Wed Sep 29 16:26:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23349; Wed, 29 Sep 93 16:26:15 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01364; Wed, 29 Sep 93 16:33:03 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25327(netkeeper.sj.nec.com ); Wed, 29 Sep 93 16:32:59 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09065(archimedes.inoc.sj.nec.com ); Wed, 29 Sep 93 16:32:57 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA28294 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 16:24:52 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00557); Wed, 29 Sep 93 16:17:31 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by hubbub.cisco.com with SMTP id AA28260 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 16:23:27 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA12133; Thu, 30 Sep 1993 08:23:12 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA26449; Thu, 30 Sep 1993 08:23:10 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA25710; Thu, 30 Sep 1993 08:23:09 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA16437; Thu, 30 Sep 93 08:23:08 JST Date: Thu, 30 Sep 93 08:23:08 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9309292323.AA16437@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: I need a *fast* integer sqrt() Status: OR songdog!roman@eskimo.com writes: >I offer these even though I'm not sure why you need to do square roots to >fill a circle. Have you heard of Bresenham's algorithm? Algorithms, >actually - there are ways to draw straight lines and circles/ellipses with >no more powerful operations than addition and shifting, no multiplication, >division, or square roots. I'll try to come up with a citation of a good >book which describes the algorithms (I have a bad book, but I wouldn't >recommend it to anyone). Well, I use bresham for lines, and I use a variation of it to draw normal circles/ellipses. The reason why I need a square root for filled circles is that, given a y coordinate, I'd like to be able to calculate the x coordinate in one quadrant (doesn't matter which), and then draw a scan line from the left to right. The algorithms I use to draw circles now tend to work by drawing octants, and using symmetry to reflect the other points (for patterned-line circles, the algorthim I use draws pixel by pixel, but it doesn't always start in the right position, and I need that to calculate the tile to use). I thought I could use the formula (from high school geometry): n n (x/a) + (y/b) = 1 because I know a,b and y. So I can reorganise the formula to calculate x. I should note that I've never done much graphics programming before so it's quite possible I'm doing things wrong. I don't have any graphics programming books around here either... (this is one reason why it's taking so long to write bitblt). Anyway, the initial version of bitblt is bound to be sub-optimal. Hopefully it will improve with age. The name for the windowing system is probably going to be MADO. (Multiplexed Architecture Display Organiser). In Japanese, this has the meaning "Window(s)" :-) Andy, I like the proposed source tree structure! nick From vandys@cisco.com Thu Sep 30 20:33:54 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03102; Thu, 30 Sep 93 20:33:53 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05906; Thu, 30 Sep 93 20:40:52 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09194(netkeeper.sj.nec.com ); Thu, 30 Sep 93 20:40:51 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13631(archimedes.inoc.sj.nec.com ); Thu, 30 Sep 93 20:40:49 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA00162 (5.67a/IDA-1.5 for ); Thu, 30 Sep 1993 20:32:44 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00156); Thu, 30 Sep 93 20:25:34 -0700 Received: from localhost by glare.cisco.com with SMTP id AA02802 (5.67a/IDA-1.5 for ); Thu, 30 Sep 1993 20:31:46 -0700 Message-Id: <199310010331.AA02802@glare.cisco.com> To: vsta@cisco.com Subject: Latest stuff Date: Thu, 30 Sep 1993 20:31:46 -0700 From: Andrew Valencia Status: OR Hi, folks. I have pdmake ported to VSTa, and my complete lack of support for time in the DOS filesystem bit me immediately. I've added a time_set() interface to the microkernel, and written a user program to query the PC NV clock, map it to kernel format, and set the system time. I also added the basic "date" command, so I can see if it worked. I'll add time support to the DOS filesystem tomorrow, and then hopefully I'll have a workable "make" with which to drive all my native VSTa compiles. BTW, if somebody wants to do a an easy but "neato" modification for me, consider adding environment variable expansion to the path name lookup. That is, change path lookup so that: /@USER@/bin would map to /vandys/bin, if I were to run it (and $USER was vandys). This is easy to do because pathname lookups are done in the user context; see libc/open.c. Regards, Andy From nick@nsis.cl.nec.co.jp Thu Sep 30 21:12:54 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03136; Thu, 30 Sep 93 21:12:53 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05990; Thu, 30 Sep 93 21:19:51 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09541(netkeeper.sj.nec.com ); Thu, 30 Sep 93 21:19:50 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13677(archimedes.inoc.sj.nec.com ); Thu, 30 Sep 93 21:19:48 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA00581 (5.67a/IDA-1.5 for ); Thu, 30 Sep 1993 21:10:49 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00172); Thu, 30 Sep 93 21:01:36 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA00507 (5.67a/IDA-1.5 for ); Thu, 30 Sep 1993 21:07:45 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA29089; Fri, 1 Oct 1993 13:07:34 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA21505; Fri, 1 Oct 1993 13:07:33 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA03290; Fri, 1 Oct 1993 13:07:32 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA04244; Fri, 1 Oct 93 13:07:31 JST Date: Fri, 1 Oct 93 13:07:31 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310010407.AA04244@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Thu, 30 Sep 1993 20:31:46 -0700 <199310010331.AA02802@glare.cisco.com> Subject: Latest stuff Status: OR >I have pdmake ported to VSTa, and my complete lack of support for time in >the DOS filesystem bit me immediately. I've added a time_set() interface >to the microkernel, and written a user program to query the PC NV clock, >map it to kernel format, and set the system time. I also added the basic >"date" command, so I can see if it worked. That's interesting. Just last night I was thinking about time in VSTa. I thought a simple server that maintained the system time would be nice. I figured that if it was designed well, it wouldn't even need to handle interrupts. This way programs could just open /dev/time, and read/write. >I'll add time support to the DOS filesystem tomorrow, and then hopefully >I'll have a workable "make" with which to drive all my native VSTa >compiles. Great! If I remember correctly, pdmake is fairly limited in what it let's you do isn't it? Something like the mid 70's to early 80's unix make? >BTW, if somebody wants to do a an easy but "neato" modification for me, If this isn't urgent, I'll look into it a little later. (I think I'll probably be doing some hacking in that area when I start writing MADO). nick From jont@hsa.com.au Fri Oct 1 00:25:27 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04159; Fri, 1 Oct 93 00:25:24 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06403; Fri, 1 Oct 93 00:32:23 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11594(netkeeper.sj.nec.com ); Fri, 1 Oct 93 00:32:22 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14091(archimedes.inoc.sj.nec.com ); Fri, 1 Oct 93 00:32:19 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02008 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 00:22:38 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00236); Fri, 1 Oct 93 00:14:11 -0700 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA01983 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 00:19:51 -0700 Received: by warrane.connect.com.au with UUCP id AA25966 (5.67a+/IDA-1.5 for vsta@cisco.com); Fri, 1 Oct 1993 17:18:45 +1000 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA04637 (5.65c/IDA-1.5 for ); Fri, 1 Oct 1993 16:57:36 +1000 From: Jonathon Tidswell Message-Id: <199310010657.AA04637@hsa.hsa.com.au> Subject: /@USER@/bin ( was Re: Latest stuff ) To: vsta@cisco.com Date: Fri, 1 Oct 1993 16:54:15 +1000 (EST) In-Reply-To: <199310010331.AA02802@glare.cisco.com> from "Andrew Valencia" at Sep 30, 93 08:31:46 pm Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1055 Status: OR > From: Andrew Valencia [ ... ] > BTW, if somebody wants to do a an easy but "neato" modification for me, > consider adding environment variable expansion to the path name lookup. > That is, change path lookup so that: > > /@USER@/bin > > would map to /vandys/bin, if I were to run it (and $USER was vandys). > This is easy to do because pathname lookups are done in the user context; > see libc/open.c. Im a little confused. Would this not be better done by using namer to map /some/path/to/users/bin to some common spot, or the contents thereof to some common spot ? [ cf plan9's mount ] Regarding directory structures: Multi user systems rely on convention for finding things, I think perhaps some thought should be put into a longer term general diretory structure. As the later such thought happens the harder it will be to "start afresh". How much we should copy the unix structure with regard to partitions, et. al. is open to debate. [ There is some logic behind separate partitions: /, /var, /usr, /home, ... ] - JonT From cmaeda@cs.washington.edu Fri Oct 1 01:10:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04827; Fri, 1 Oct 93 01:10:34 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06503; Fri, 1 Oct 93 01:17:32 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12001(netkeeper.sj.nec.com ); Fri, 1 Oct 93 01:17:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14137(archimedes.inoc.sj.nec.com ); Fri, 1 Oct 93 01:17:28 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02395 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 01:09:28 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00254); Fri, 1 Oct 93 00:59:56 -0700 Received: from june.cs.washington.edu by hubbub.cisco.com with SMTP id AA02376 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 01:06:10 -0700 Received: from localhost by june.cs.washington.edu (5.65b/7.1ju) id AA16678; Fri, 1 Oct 93 01:05:35 -0700 To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: /@USER@/bin ( was Re: Latest stuff ) In-Reply-To: Your message of "Fri, 01 Oct 93 16:54:15 +0900." <199310010657.AA04637@hsa.hsa.com.au> Date: Fri, 01 Oct 93 01:05:35 -0700 Message-Id: <16676.749462735@june.cs.washington.edu> From: cmaeda@cs.washington.edu Status: OR Date: Fri, 01 Oct 93 16:54:15 +0900 To: vsta@cisco.com From: Jonathon Tidswell Subject: /@USER@/bin ( was Re: Latest stuff ) > From: Andrew Valencia [There is some logic behind separate partitions: /, /var, /usr, /home, ... ] What is the logic behind separate disk partitions? Would they be needed if unix had a better way to backup subsets of the file system and disk quotas that worked? Not attacking but trying to understand... Chris ps On fast IPC, the canonical paper is "Lightweight Remote Procedure Call" by Bershad, Anderson, Lazowska, Levy in ACM TOCS (transactions on computer systems) v8 n1 Feb 1990 p 37-55. The most significant implementation of LRPC is the "Quick LPC" technology in Windows NT. LRPC works by setting up a shared memory region at binding time before any calls are made. An actual call consists of copying args to the shared memory region and then calling a lightweight control transfer function (such as a semaphore) to context switch to the destination. The performance win is because of the shared memory region: the kernel doesn't have to copyin, validate, and copyout this data. As far as the IPC in Spring, I'm not sure why it's so fast. I have two possible explanations. They use sparc register windows to avoid saving and restoring cpu state. I imagine they save a lot of memory traffic and get much better cache locality this way. But it's not clear if you will get this kind of peformance in real life. Real applications also do a lot more than sit in a tight loop bouncing IPC messages off each other. (I'm looking at a copy of "The Spring Nucleus: A Microkernel for Objects" by Hamilton and Kougiouris, Sun Labs TR SMLI-TR-93-14. This might have appeared in the 1993 Summer Usenix as well.). This PS turned out to be longer than I thought... From nick@nsis.cl.nec.co.jp Fri Oct 1 02:34:21 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05510; Fri, 1 Oct 93 02:34:16 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06738; Fri, 1 Oct 93 02:41:13 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12692(netkeeper.sj.nec.com ); Fri, 1 Oct 93 02:41:12 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14203(archimedes.inoc.sj.nec.com ); Fri, 1 Oct 93 02:41:09 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02841 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 02:14:50 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00302); Fri, 1 Oct 93 02:00:13 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA02744 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 02:06:18 -0700 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA19277; Fri, 1 Oct 1993 18:06:04 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA04339; Fri, 1 Oct 1993 17:35:26 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-930927.1) id AA16032; Fri, 1 Oct 1993 17:35:25 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.45) id AA08982; Fri, 1 Oct 93 17:35:24 JST Date: Fri, 1 Oct 93 17:35:24 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310010835.AA08982@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: cmaeda@cs.washington.edu's message of Fri, 01 Oct 93 01:05:35 -0700 <16676.749462735@june.cs.washington.edu> Subject: /@USER@/bin ( was Re: Latest stuff ) Status: OR > [There is some logic behind separate partitions: /, /var, /usr, /home, ... ] > >What is the logic behind separate disk partitions? > >Would they be needed if unix had a better way to backup subsets of the >file system and disk quotas that worked? Well, despite the flawed logic (read kludge), used in traditional Unix systems to minimise damage when a partition is trashed, people become accustomed to the layout of the filesystem they use most. If VSTa is completely different from what the user expects, it will make VSTa just a little harder to get used to, so I tend to think we should lay things out in a semi-traditional way (if only in the naming). Besides all this, I'm not 100% sure that Andy meant that all binaries would live under /vandys/bin. Andy, would you like to clarify why you'd like this feature added? nick From vandys@cisco.com Fri Oct 1 08:41:49 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17400; Fri, 1 Oct 93 08:41:47 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07678; Fri, 1 Oct 93 08:48:48 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16751(netkeeper.sj.nec.com ); Fri, 1 Oct 93 08:48:47 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14665(archimedes.inoc.sj.nec.com ); Fri, 1 Oct 93 08:48:44 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08826 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 08:41:05 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00501); Fri, 1 Oct 93 08:33:06 -0700 Received: from localhost by glare.cisco.com with SMTP id AA18477 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 08:39:21 -0700 Message-Id: <199310011539.AA18477@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: /@USER@/bin ( was Re: Latest stuff ) In-Reply-To: Your message of "Fri, 01 Oct 1993 17:35:24 +0200." <9310010835.AA08982@silk1.nsis.cl.nec.co.jp> Date: Fri, 01 Oct 1993 08:39:21 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Besides all this, I'm not 100% sure that Andy meant that all binaries >would live under /vandys/bin. Andy, would you like to clarify why >you'd like this feature added? Wow, something really got lost in the translation. I was simply giving an example of how to expand environment variables in pathname lookup. My example had *nothing* to do with how I thought /bin and bin path lookup should be handled. Clearly, I used a bad example. Plan9 assumed that all sources of binaries would be merged (using union mounts) into /bin, so your shell's "path" would always simply be /bin. Currently, our shells still have UNIX-style command lookup, with a PATH variable. This does not make Plan9-style setups impossible; merely use a union mount and leave PATH as /bin. Remember, in VSTa mount points are merely an illusion of the C library. Neither servers nor the kernel know about mount points. Therefore, if we choose some "standard" directory layout, it is trivial for any user or any program to remap the name space to another format. This doesn't mean we shouldn't pick some intelligent defaults, but it adds some perspective. We have broken from UNIX (mount points are global), QNX (also global) and Plan9 (per-process, but kernel-implemented), and we don't seem to have lost much in the process. Andy From vandys@cisco.com Fri Oct 1 08:52:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17440; Fri, 1 Oct 93 08:52:31 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07712; Fri, 1 Oct 93 08:59:33 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16963(netkeeper.sj.nec.com ); Fri, 1 Oct 93 08:59:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14697(archimedes.inoc.sj.nec.com ); Fri, 1 Oct 93 08:59:29 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09184 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 08:52:49 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00507); Fri, 1 Oct 93 08:44:31 -0700 Received: from localhost by glare.cisco.com with SMTP id AA18936 (5.67a/IDA-1.5 for ); Fri, 1 Oct 1993 08:50:47 -0700 Message-Id: <199310011550.AA18936@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Latest stuff In-Reply-To: Your message of "Fri, 01 Oct 1993 13:07:31 +0200." <9310010407.AA04244@silk1.nsis.cl.nec.co.jp> Date: Fri, 01 Oct 1993 08:50:46 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >That's interesting. Just last night I was thinking about time in VSTa. >I thought a simple server that maintained the system time would be >nice. I figured that if it was designed well, it wouldn't even need to >handle interrupts. This way programs could just open /dev/time, and >read/write. The kernel has to know "time"; certain kernel mechanisms (like page stealing) need such a concept. I prototyped having a time server which all sleepers would use (i.e., open /dev/time and write "sleep 10"), but I found that the time server needs a kernel mechanism so close to what most sleepers could use anyway, that there was little benefit to having an extra server in the way. The kernel has thus always had "get time" and "sleep". I merely added "set time" last night. The code was smaller than the code to read the time out of the hardware, which was the alternative. >Great! If I remember correctly, pdmake is fairly limited in what it >let's you do isn't it? Something like the mid 70's to early 80's unix >make? Yes, that's about right. You'll notice that my makefiles tend to be pretty spartan... the habits of a V7 hacker. :-) >If this isn't urgent, I'll look into it a little later. (I think I'll >probably be doing some hacking in that area when I start writing >MADO). Not urgent, and actually I was hoping it would be a chance for one of our newer readers to do some coding. Andy From vandys@cisco.com Mon Oct 4 16:40:18 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08144; Mon, 4 Oct 93 16:40:17 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19640; Mon, 4 Oct 93 16:47:36 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25608(netkeeper.sj.nec.com ); Mon, 4 Oct 93 16:47:35 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00164(archimedes.inoc.sj.nec.com ); Mon, 4 Oct 93 16:47:29 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09106 (5.67a/IDA-1.5 for ); Mon, 4 Oct 1993 16:37:17 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00798); Mon, 4 Oct 93 16:29:21 -0700 Received: from localhost by glare.cisco.com with SMTP id AA07509 (5.67a/IDA-1.5 for ); Mon, 4 Oct 1993 16:36:03 -0700 Message-Id: <199310042336.AA07509@glare.cisco.com> To: vsta@cisco.com Subject: Status Date: Mon, 04 Oct 1993 16:36:02 -0700 From: Andrew Valencia Status: OR I now have pdmake doing my entire source build, and it works fine. I have also ported it to VSTa, added the needed time facilities to the DOS filesystem, as well as a setime and date command. I modified gcc's C preprocessor to handle both DOS \r\n and UNIX \n line conventions. I built my new filesystem natively under VSTa, and it compiles & runs! My filesystem has some performance "opportunities" left in it, but is mostly running well. I think I'll fix the most glaring performance problems, add an fsck, and make that available for Beta testing as a part of the 1.1 release. I'll add file versioning for 1.2. I sincerely hope that 1.1 will be much easier to install and build. I'm aware of the make, tar, and gzip problems. For 1.1 I will also provide a pointer to the FTP server & files needed to install the djgpp DOS C compiler. I've hopefully fixed all the compilation errors and warnings in the source. If you have had problems, and think I might not know about them (or forgot :-<), now would be a good time to drop me a note. Thanks, Andy From vandys@cisco.com Tue Oct 5 09:30:26 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14786; Tue, 5 Oct 93 09:30:23 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22249; Tue, 5 Oct 93 09:37:46 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11782(netkeeper.sj.nec.com ); Tue, 5 Oct 93 09:37:44 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01520(archimedes.inoc.sj.nec.com ); Tue, 5 Oct 93 09:37:40 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA26248 (5.67a/IDA-1.5 for ); Tue, 5 Oct 1993 09:31:29 -0700 Received: from glare.cisco.com by amri.cisco.com (AA01240); Tue, 5 Oct 93 09:22:23 -0700 Received: from localhost by glare.cisco.com with SMTP id AA01391 (5.67a/IDA-1.5 for ); Tue, 5 Oct 1993 09:29:12 -0700 Message-Id: <199310051629.AA01391@glare.cisco.com> To: Remy.Card@masi.ibp.fr (Remy CARD) Cc: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol), vsta@cisco.com Subject: Re: Status In-Reply-To: Your message of "Tue, 05 Oct 1993 14:39:48 -0000." <199310051439.AA14897@masi.ibp.fr> Date: Tue, 05 Oct 1993 09:29:11 -0700 From: Andrew Valencia Status: OR [Remy.Card@masi.ibp.fr (Remy CARD) writes:] >[ftp mirror]... > I can. Starting from today, VSTa is mirrored on ftp.ibp.fr (a station >dedicated to act as a ftp site in Paris, France) in /pub/vsta. ftp.ibp.fr >runs the wuarchive 2.1 ftp daemon. Thank you very much! I was thinking of offering it off my own UNIX box, but that would have been on the far side of a 56K link. This is a much better solution. USA-side folks should probably continue to pull from ftp.cisco.com, unless Cisco's FTP daemon causes you grief. Regards, Andy From nick@nsis.cl.nec.co.jp Wed Oct 6 23:35:43 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18985; Wed, 6 Oct 93 23:35:41 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01959; Wed, 6 Oct 93 23:43:12 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17485(netkeeper.sj.nec.com ); Wed, 6 Oct 93 23:43:11 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06364(archimedes.inoc.sj.nec.com ); Wed, 6 Oct 93 23:43:09 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA15832 (5.67a/IDA-1.5 for ); Wed, 6 Oct 1993 23:31:33 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00589); Wed, 6 Oct 93 23:21:18 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA15812 (5.67a/IDA-1.5 for ); Wed, 6 Oct 1993 23:28:34 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA03094; Thu, 7 Oct 1993 15:28:26 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA13954; Thu, 7 Oct 1993 15:28:24 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA23521; Thu, 7 Oct 1993 15:28:22 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA06008; Thu, 7 Oct 93 15:28:20 JST Date: Thu, 7 Oct 93 15:28:20 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310070628.AA06008@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Character encoding Status: OR Does anyone have any comments on character encoding in VSTa. I think it is easy to say that fixed width characters (like 16bit) are out because they'll cause everything to grow too much. That leaves us with a multibyte representation. Does anyone have any preferences, and code to convert from multibyte to unsigned or long? (I have a package that was posted on the *.sources group recently called runes, and I have the stuff from the sam.bundle). I plan to have bitblt work with runes/glyphs, so we need to incorporate such code into libc before too long. Personally, I am in favor of just using utf2, but the runes package can handle euc, and a few other besides. Shall we just put that package into libc? Also, is there any online documentation on the UTF mappings? One thing I'm wondering about is how to handle function keys, arrows etc. with UTF. I assume they just use the normal escape sequences? nick PS. I have plans (at some time or another) to include a FEP into the basic input system of bitblt. I don't know whether I'll put it into the keyboard server or not; though that has the benefit of allowing multilingual text to be input easily. From mackinlay@garion.it.com.au Thu Oct 7 00:24:53 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19008; Thu, 7 Oct 93 00:24:51 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02080; Thu, 7 Oct 93 00:32:22 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17841(netkeeper.sj.nec.com ); Thu, 7 Oct 93 00:32:20 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06431(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 00:32:18 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA16179 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 00:21:49 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00606); Thu, 7 Oct 93 00:11:31 -0700 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA16161 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 00:18:50 -0700 Received: from garion.it.com.au by joyce.cs.su.OZ.AU (for vsta@cisco.com) with MHSnet; Thu, 07 Oct 1993 17:18:50 +1000 Received: by garion.it.com.au (Smail3.1.28.1 #3) id m0okpd5-00014P5; Thu, 7 Oct 93 15:19 WST Message-Id: Subject: Re: Character encoding To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Date: Thu, 7 Oct 1993 15:19:11 +0800 (WST) From: Pat Mackinlay Cc: vsta@cisco.com In-Reply-To: <9310070628.AA06008@silk1.nsis.cl.nec.co.jp> from "Gavin Thomas Nicol" at Oct 7, 93 03:28:20 pm X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 623 Status: OR > Does anyone have any comments on character encoding in VSTa. I think > it is easy to say that fixed width characters (like 16bit) are out > because they'll cause everything to grow too much. That leaves us with Sorry, I'm no expert, but the idea of a multibyte representation really turns me off. Surely a uniform 16 bit character set is easier to deal with than a multibyte one (in terms of programming)? Ok, so it might be less efficient in terms of space, but I think you'd pay for that in terms of code complexity with the alternative... And if we did use a 16 bit character set, Unicode is the obvious choice... From nick@nsis.cl.nec.co.jp Thu Oct 7 01:02:35 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19022; Thu, 7 Oct 93 01:02:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02172; Thu, 7 Oct 93 01:10:05 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18166(netkeeper.sj.nec.com ); Thu, 7 Oct 93 01:10:04 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06481(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 01:10:01 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA16551 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 00:59:40 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00626); Thu, 7 Oct 93 00:49:03 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA16517 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 00:56:10 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA10297; Thu, 7 Oct 1993 16:55:54 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA17940; Thu, 7 Oct 1993 16:55:54 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA28377; Thu, 7 Oct 1993 16:55:53 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA07657; Thu, 7 Oct 93 16:55:50 JST Date: Thu, 7 Oct 93 16:55:50 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310070755.AA07657@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Pat Mackinlay's message of Thu, 7 Oct 1993 15:19:11 +0800 (WST) Subject: Character encoding Status: OR >> Does anyone have any comments on character encoding in VSTa. I think >> it is easy to say that fixed width characters (like 16bit) are out >> because they'll cause everything to grow too much. That leaves us with > >Sorry, I'm no expert, but the idea of a multibyte representation really >turns me off. Surely a uniform 16 bit character set is easier to deal with >than a multibyte one (in terms of programming)? Ok, so it might be less >efficient in terms of space, but I think you'd pay for that in terms of >code complexity with the alternative... No, a straight move to 16 bit characters means than everything that deals with characters (and that means almost everything), and *all* files (including executables), will grow *unless* you introduce attributes, which is a truly horrible idea (how does "cat" work in such a case?). Also, moving to straight 16bit will break a lot of programs, whereas many programs will work with multibyte with few changes because they are 8 bit clean (an example is microemacs. The version distributed with VSTa work with kanji on my Japanese version of VSTa). The way plan9 does it is to *store* and *send* data in multibyte format, but internally, use 16bit characters. This has the advantage of not breaking many programs, while at the same time allowing program that are modified to handle 16 bit codes, to take advantage of them. They have some library functions for converting a string between unes and multibyte, and str* like functions for manipulating 18 bit characters. >And if we did use a 16 bit character set, Unicode is the obvious choice... I agree it's the *obvious* choice, but is it the best? I don't know... From nick@nsis.cl.nec.co.jp Thu Oct 7 16:19:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02409; Thu, 7 Oct 93 16:19:35 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02078; Thu, 7 Oct 93 16:27:09 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21222(netkeeper.sj.nec.com ); Thu, 7 Oct 93 16:27:08 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08346(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 16:27:05 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA07958 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:17:37 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00346); Thu, 7 Oct 93 16:06:25 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA07832 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:13:50 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA20119; Fri, 8 Oct 1993 08:13:44 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA03980; Fri, 8 Oct 1993 08:13:43 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA20934; Fri, 8 Oct 1993 08:13:42 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA13464; Fri, 8 Oct 93 08:13:41 JST Date: Fri, 8 Oct 93 08:13:41 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310072313.AA13464@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Jonathon Tidswell's message of Thu, 7 Oct 1993 22:52:02 +1000 (EST) <199310071255.AA26588@hsa.hsa.com.au> Subject: Character encoding Status: OR >Was the *.sources posting from AT&T ? No, the *.source posting was froma fellow at cray. It is the rune system from BSD4.4. >I know of some libXg/UTF2/runes/toolkit work happening at Sydney Uni. >But I havent had a chance to chase up the guy doing it. >[ Includes a "9term" or libg style xterm. ] Yep, I have those. Actually, they are also available on research.att.com >I was going to mail you (since you are working on MADO) and ask if you had >or had seen: > - the sam bundle > - MGR > - other ... Yes, I have them all (except "other"?). >What is EUC ? >Does it handle codes not in Unicode ? >If not provide a separate utf2<-->other library (runes ?) and just work >in UTF2. I'm not sure what the acronym is, but EUC is a character encoding system in common use throughout Asia. It is a multibyte encoding system. Along with that are JIS, SJIS, and a couple of others (though >I have the Plan9 documnets and the postscript manual pages (broken into >sections) online. Me too. Actually, I meant Unicode mappings. Are the Unicode mapping available online anywhere? >> PS. I have plans (at some time or another) to include a FEP into the >What is FEP ? Front end processor. Things like Kanji cannot be entered from a normal keyboard (because there are too many of them), so it is common to use a FEP which allows you to enter romanised spellings of characters. The FEP then translates it into normal Kanji/Kana. This could also be useful for European languages. For example, by activating the FEP, then typing a% (or perhaps phonetics), we get a with 2 dots over it. From nick@nsis.cl.nec.co.jp Thu Oct 7 16:24:57 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02418; Thu, 7 Oct 93 16:24:56 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02093; Thu, 7 Oct 93 16:32:30 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21282(netkeeper.sj.nec.com ); Thu, 7 Oct 93 16:32:30 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08354(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 16:32:28 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08101 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:23:25 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00362); Thu, 7 Oct 93 16:12:59 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA08006 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:20:25 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA20605; Fri, 8 Oct 1993 08:20:23 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA04095; Fri, 8 Oct 1993 08:20:22 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA20965; Fri, 8 Oct 1993 08:20:21 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA13489; Fri, 8 Oct 93 08:20:20 JST Date: Fri, 8 Oct 93 08:20:20 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310072320.AA13489@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: libc performance Status: OR Well, I got the font loader working last night. The current font encoding scheme is simlar to X11 BDF (thoug it's easy to add other font encoding systems). The problem is that this is a *text* file, and as such, needs to be parsed. The parser is naive in that it uses straight fgetc()/ungetc() rather than some kind of buffered input system. Performance is, to say the least, dismal. Currently, libc stream I/O uses single character read/writes. This needs to change. If someone is interested in updating this, please do it ASAP. 10 second font loads aren't fun.... To anyone interested in doing this, I would strongly recommend looking at sfio, which is a very powerful stream I/O sub-system. If no-one is interested in doing this, I will divert some of my time to the project, but then MADO will be delayed. nick From vandys@cisco.com Thu Oct 7 16:36:12 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02433; Thu, 7 Oct 93 16:36:11 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02123; Thu, 7 Oct 93 16:43:44 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21410(netkeeper.sj.nec.com ); Thu, 7 Oct 93 16:43:45 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08369(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 16:43:43 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08417 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:34:29 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00371); Thu, 7 Oct 93 16:23:15 -0700 Received: from localhost by glare.cisco.com with SMTP id AA25554 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:30:43 -0700 Message-Id: <199310072330.AA25554@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: libc performance In-Reply-To: Your message of "Fri, 08 Oct 1993 08:20:20 +0200." <9310072320.AA13489@silk1.nsis.cl.nec.co.jp> Date: Thu, 07 Oct 1993 16:30:42 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Performance is, to say the least, dismal. Currently, libc stream I/O >uses single character read/writes. This needs to change. If someone is >interested in updating this, please do it ASAP. 10 second font loads >aren't fun.... When I wrote libc BSD 4.X free sources were deep in the middle of dark ugly legal contests, and the winner was by no means clear. I therefore reluctantly had to write a stdio package for myself, and quickly. The result is simple, easy to write, and funnels everything through the functions fgetc()/fputc(). BSD source access is looking more hopeful, but is by no means in the clear yet. For Nick's problem, I might throw together an in-line version of getc() and putc(). I *suspect* these are the bottlenecks. The other big bottleneck would be fread/fwrite, which could definitely short-circuit the individual putc/getc path. Nick, I would welcome any further clues you can provide as to bottlenecks. A new stream I/O package is a thought, but the current one has the benefit of being widely understood. Improving its throughput will benefit a wide range of applications. Anybody want to jump in? Andy From nick@nsis.cl.nec.co.jp Thu Oct 7 16:46:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02457; Thu, 7 Oct 93 16:46:35 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02149; Thu, 7 Oct 93 16:54:08 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21450(netkeeper.sj.nec.com ); Thu, 7 Oct 93 16:54:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08377(archimedes.inoc.sj.nec.com ); Thu, 7 Oct 93 16:54:03 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08580 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:42:02 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00380); Thu, 7 Oct 93 16:31:34 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA08491 (5.67a/IDA-1.5 for ); Thu, 7 Oct 1993 16:39:02 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA22137; Fri, 8 Oct 1993 08:38:59 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA04945; Fri, 8 Oct 1993 08:38:58 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA21356; Fri, 8 Oct 1993 08:38:57 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA13658; Fri, 8 Oct 93 08:38:56 JST Date: Fri, 8 Oct 93 08:38:56 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310072338.AA13658@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Thu, 07 Oct 1993 16:30:42 -0700 <199310072330.AA25554@glare.cisco.com> Subject: libc performance Status: OR >A new stream I/O package is a thought, but the current one has the >benefit of being widely understood. Improving its throughput will >benefit a wide range of applications. Anybody want to jump in? I should note that I was not suggesting using sfio itself, but rather, some of the ideas in it (like stackable translation functions, stream I/O on strings, etc). Also, sfio has a stdio compatibility library. From dave@mom.computone.com Tue Oct 12 19:30:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01891; Tue, 12 Oct 93 19:30:31 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06521; Tue, 12 Oct 93 19:38:34 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24635(netkeeper.sj.nec.com ); Tue, 12 Oct 93 19:38:33 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA19632(archimedes.inoc.sj.nec.com ); Tue, 12 Oct 93 19:38:30 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03120 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 19:30:31 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00232); Tue, 12 Oct 93 19:21:02 -0700 Received: from cton.computone.com by hubbub.cisco.com with SMTP id AA03105 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 19:29:31 -0700 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0omvsP-000FxeC; Tue, 12 Oct 93 22:23 EDT Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Tue, 12 Oct 93 22:24 EDT Message-Id: From: dave@computone.com (David Johnson) Subject: Dupping message data To: vsta@cisco.com Date: Tue, 12 Oct 1993 22:24:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 315 Status: OR Is there a simple way to duplicate message data to send the same information to multiple recipients? For example, say two processes have the Ethernet driver open and are registered to receive all packets (promiscuous mode). I need to take each incoming packet and duplicate it to each of these receivers. dave From nick@nsis.cl.nec.co.jp Tue Oct 12 19:48:31 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01922; Tue, 12 Oct 93 19:48:29 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06565; Tue, 12 Oct 93 19:56:32 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24947(netkeeper.sj.nec.com ); Tue, 12 Oct 93 19:56:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA19669(archimedes.inoc.sj.nec.com ); Tue, 12 Oct 93 19:56:29 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03397 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 19:49:26 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00242); Tue, 12 Oct 93 19:38:54 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA03377 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 19:47:19 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA15536; Wed, 13 Oct 1993 11:47:11 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA27226; Wed, 13 Oct 1993 11:47:09 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA06044; Wed, 13 Oct 1993 11:47:08 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA04056; Wed, 13 Oct 93 11:47:08 JST Date: Wed, 13 Oct 93 11:47:08 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310130247.AA04056@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Dupping message data Status: OR I might be wrong (quite possibly), but I think you can just go ahead and send the message to both, and they will both receive a local copy. nick From vandys@cisco.com Tue Oct 12 20:21:03 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01944; Tue, 12 Oct 93 20:21:02 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06642; Tue, 12 Oct 93 20:29:05 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25311(netkeeper.sj.nec.com ); Tue, 12 Oct 93 20:29:01 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA19730(archimedes.inoc.sj.nec.com ); Tue, 12 Oct 93 20:28:59 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03680 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 20:22:40 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00258); Tue, 12 Oct 93 20:11:54 -0700 Received: from localhost by glare.cisco.com with SMTP id AA04685 (5.67a/IDA-1.5 for ); Tue, 12 Oct 1993 20:20:26 -0700 Message-Id: <199310130320.AA04685@glare.cisco.com> To: dave@computone.com (David Johnson) Cc: vsta@cisco.com Subject: Re: Dupping message data In-Reply-To: Your message of "Tue, 12 Oct 1993 22:24:35 EDT." Date: Tue, 12 Oct 1993 20:20:25 -0700 From: Andrew Valencia Status: OR [dave@computone.com (David Johnson) writes:] >For example, say two processes have the Ethernet driver open and are >registered to receive all packets (promiscuous mode). I need to take >each incoming packet and duplicate it to each of these receivers. Nick is right, but perhaps I can flesh out some details. First, your ethernet driver will not be receiving messages; he will be arming DMA down onto the Lance (or whatever ether chip), and filling in wired pages in his address space. He will be receiving interrupt messages as packets are completely received. Now he has some private memory, with interesting contents, and he wants to send it to two folks. Or does he? Is he a server (and thus must wait to RECEIVE requests) or a client (he gets to initiate requests)? I'd guess he's a server, since he must receive messages concerning interrupts, anyway. So, he has a packet, and has previously had msg_receive() return him two requests, neither to which he has msg_reply()'ed yet. All he does is find the pending messages, fill in the scatter/gather list with the packet, and do a msg_reply() to each client. You can see logic for handling multiple outstanding I/O requests. See the kbd driver, for instance. I think the fd driver queues multiple requests as well. Andy From dave@mom.computone.com Wed Oct 13 05:42:25 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05052; Wed, 13 Oct 93 05:42:24 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08024; Wed, 13 Oct 93 05:50:28 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00661(netkeeper.sj.nec.com ); Wed, 13 Oct 93 05:50:26 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA20400(archimedes.inoc.sj.nec.com ); Wed, 13 Oct 93 05:50:24 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA10170 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 05:43:25 -0700 Received: from ns.cisco.com by amri.cisco.com (AA00519); Wed, 13 Oct 93 05:32:42 -0700 Received: from cton.computone.com by hubbub.cisco.com with SMTP id AA10158 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 05:41:11 -0700 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0on5Qe-000DI7C; Wed, 13 Oct 93 08:35 EDT Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 13 Oct 93 08:36 EDT Message-Id: From: dave@computone.com (David Johnson) Subject: Re: Dupping message data To: vsta@cisco.com Date: Wed, 13 Oct 1993 08:36:31 -0400 (EDT) In-Reply-To: <199310130320.AA04685@glare.cisco.com> from "Andrew Valencia" at Oct 12, 93 08:20:25 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1958 Status: OR > > [dave@computone.com (David Johnson) writes:] > > >For example, say two processes have the Ethernet driver open and are > >registered to receive all packets (promiscuous mode). I need to take > >each incoming packet and duplicate it to each of these receivers. > > Nick is right, but perhaps I can flesh out some details. > > First, your ethernet driver will not be receiving messages; he will be > arming DMA down onto the Lance (or whatever ether chip), and filling in > wired pages in his address space. He will be receiving interrupt messages > as packets are completely received. > > Now he has some private memory, with interesting contents, and he wants > to send it to two folks. Or does he? Is he a server (and thus must wait > to RECEIVE requests) or a client (he gets to initiate requests)? I'd > guess he's a server, since he must receive messages concerning interrupts, > anyway. > > So, he has a packet, and has previously had msg_receive() return him two > requests, neither to which he has msg_reply()'ed yet. All he does is find > the pending messages, fill in the scatter/gather list with the packet, > and do a msg_reply() to each client. > > You can see logic for handling multiple outstanding I/O requests. See > the kbd driver, for instance. I think the fd driver queues multiple > requests as well. > > Andy > No problem. I kinda figured it would be this simple. Now on to another problem which now surfaces. A typical TCP stream will look something like the following (maybe more servers): User program | | TCP server | | Ethernet server Normally packets are sent up in a STREAMS environment asynchronously to the modules above. They process them and send them to the STREAM head which holds them for the user. However, in the server model, how can the TCP module keep a pending receive in the Ethernet server and still service other write requests from above? dave From nick@nsis.cl.nec.co.jp Wed Oct 13 16:20:12 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10357; Wed, 13 Oct 93 16:20:08 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09832; Wed, 13 Oct 93 16:28:11 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01423(netkeeper.sj.nec.com ); Wed, 13 Oct 93 16:28:08 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA22196(archimedes.inoc.sj.nec.com ); Wed, 13 Oct 93 16:28:05 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09835 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 16:20:40 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00235); Wed, 13 Oct 93 16:09:55 -0700 Received: from TYO.gate.nec.co.jp ([192.135.93.2]) by hubbub.cisco.com with SMTP id AA09771 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 16:18:29 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA17534; Thu, 14 Oct 1993 08:18:18 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA23248; Thu, 14 Oct 1993 08:18:17 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA13814; Thu, 14 Oct 1993 08:18:16 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA13962; Thu, 14 Oct 93 08:18:16 JST Date: Thu, 14 Oct 93 08:18:16 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310132318.AA13962@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Project registry update Status: OR ------------------------- Project List -----+------------------------------ TASK | WHO --------------------------------------------+------------------------------ VSTa file system (Non-Unix) | vandys@cisco.com Window System (Non-X11) | nick@nsis.cl.nec.co.jp Update kbd so key mappings can be downloaded| (planned)nick@nsis.cl.nec.co.jp Update wd to handle various IDE drives | ???? Shared libraries | /proc server (for use with ps etc.) | Debugger (using /proc??) | Unix/Linux file systems | Math emulator (inside kernel? server?) | Update/expand libc (and include files) | SCSI disk server | Network server | dave@computone.com RS232c server | Porting of applications (make, emacs, ...) | --------------------------------------------+------------------------------- If anyone else is doing anything, let me know. From dave@mom.computone.com Wed Oct 13 14:36:31 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10251; Wed, 13 Oct 93 14:36:28 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09582; Wed, 13 Oct 93 14:44:33 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29818(netkeeper.sj.nec.com ); Wed, 13 Oct 93 14:44:32 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21983(archimedes.inoc.sj.nec.com ); Wed, 13 Oct 93 14:44:29 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA06466 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 14:37:14 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00183); Wed, 13 Oct 93 14:26:57 -0700 Received: from cton.computone.com by hubbub.cisco.com with SMTP id AA06390 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 14:35:26 -0700 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0onC9P-000EU1C; Wed, 13 Oct 93 15:46 EDT Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 13 Oct 93 15:47 EDT Message-Id: From: dave@computone.com (David Johnson) Subject: Ethernet server architecture (was dupping message data) To: vsta@cisco.com Date: Wed, 13 Oct 1993 15:47:11 -0400 (EDT) In-Reply-To: from "MAILER-DAEMON@computone.com" at Oct 13, 93 03:45:00 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2699 Status: OR > > [dave@computone.com (David Johnson) writes:] > > >Normally packets are sent up in a STREAMS environment asynchronously to the > >modules above. They process them and send them to the STREAM head which > >holds them for the user. However, in the server model, how can the TCP > >module keep a pending receive in the Ethernet server and still service other > >write requests from above? > > Well, the simplest way would be to launch another thread within the > TCP process (see tfork(), more comments below), have him forever post > reads, then requeue the responses to the TCP queue. Something like: > > User program Ethernet (read) > | | > |<----------+ | > V ^ V > +----+-----------+---+-+ > | thread1 thread2| > | TCP server | > +----+-----------------+ > | > V > Ethernet (write) > > So thread1 would do all the "real" work, with thread2 just gather > packets and mixing them onto the single queue of thread1. thread1 > reads requests and ether packets, and generates responses upwards > as well as transmitted packets downwards. > > If the ethernet driver tended to block transmit requests, you might > even use a third thread to do the writes to ethernet. This would allow > thread1 to continue running while writes were queued up and blocked. > > Now, some comments concerning threading. tfork() exists, and works. I > use it a little, but am considering adding a second parameter. The > existing parameter specifies where the thread should start running > at (there are good reasons to do this instead of UNIX sementics for > fork()); I think I should add a second parameter which is passed as > the single argument on the stack to the new thread. > > I also know that the microkernel will need to offer some sort of > semaphore facility to help threads coordinate, but haven't added it > yet. I have a pretty good idea of what a multi-threaded multiprocessor > kernel environment is like (I did UNIX kernel work at Sequent), but > such an environment is very difficult, and I've been holding off > implementing something until I felt I better understood a multi- > threaded server process environment. Discussions like this help! > > Andy > Thanks for the info. Since I am just doing the Ethernet (NE2000) driver presently, I think the above information gives me enough to get this level of code working properly. I hope to get packets moving by sometime next week considering my current status. I'll worry about multi-threading and coordination once I get this server going. If anyone has any other suggestions or comments on the architecture, please let me know. dave From vandys@cisco.com Wed Oct 13 08:30:57 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08106; Wed, 13 Oct 93 08:30:55 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08506; Wed, 13 Oct 93 08:39:01 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02734(netkeeper.sj.nec.com ); Wed, 13 Oct 93 08:39:00 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA20685(archimedes.inoc.sj.nec.com ); Wed, 13 Oct 93 08:38:56 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA13057 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 08:32:42 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00575); Wed, 13 Oct 93 08:22:45 -0700 Received: from localhost by glare.cisco.com with SMTP id AA19451 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 08:31:20 -0700 Message-Id: <199310131531.AA19451@glare.cisco.com> To: dave@computone.com (David Johnson) Cc: vsta@cisco.com Subject: Re: Dupping message data In-Reply-To: Your message of "Wed, 13 Oct 1993 08:36:31 EDT." Date: Wed, 13 Oct 1993 08:31:20 -0700 From: Andrew Valencia Status: OR [dave@computone.com (David Johnson) writes:] >Normally packets are sent up in a STREAMS environment asynchronously to the >modules above. They process them and send them to the STREAM head which >holds them for the user. However, in the server model, how can the TCP >module keep a pending receive in the Ethernet server and still service other >write requests from above? Well, the simplest way would be to launch another thread within the TCP process (see tfork(), more comments below), have him forever post reads, then requeue the responses to the TCP queue. Something like: User program Ethernet (read) | | |<----------+ | V ^ V +----+-----------+---+-+ | thread1 thread2| | TCP server | +----+-----------------+ | V Ethernet (write) So thread1 would do all the "real" work, with thread2 just gather packets and mixing them onto the single queue of thread1. thread1 reads requests and ether packets, and generates responses upwards as well as transmitted packets downwards. If the ethernet driver tended to block transmit requests, you might even use a third thread to do the writes to ethernet. This would allow thread1 to continue running while writes were queued up and blocked. Now, some comments concerning threading. tfork() exists, and works. I use it a little, but am considering adding a second parameter. The existing parameter specifies where the thread should start running at (there are good reasons to do this instead of UNIX sementics for fork()); I think I should add a second parameter which is passed as the single argument on the stack to the new thread. I also know that the microkernel will need to offer some sort of semaphore facility to help threads coordinate, but haven't added it yet. I have a pretty good idea of what a multi-threaded multiprocessor kernel environment is like (I did UNIX kernel work at Sequent), but such an environment is very difficult, and I've been holding off implementing something until I felt I better understood a multi- threaded server process environment. Discussions like this help! Andy From hjb@netcom.com Wed Oct 13 10:55:18 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09589; Wed, 13 Oct 93 10:55:14 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08998; Wed, 13 Oct 93 11:03:14 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26805(netkeeper.sj.nec.com ); Wed, 13 Oct 93 11:03:12 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21296(archimedes.inoc.sj.nec.com ); Wed, 13 Oct 93 11:03:10 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA18207 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 10:55:06 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00107); Wed, 13 Oct 93 10:44:48 -0700 Received: from netcom2.netcom.com by hubbub.cisco.com with SMTP id AA18126 (5.67a/IDA-1.5 for ); Wed, 13 Oct 1993 10:53:23 -0700 Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) id AA25131; Wed, 13 Oct 93 10:53:59 -0700 From: hjb@netcom.com (hwajin bae) Message-Id: <9310131753.AA25131@netcom2.netcom.com> To: Andrew Valencia Cc: dave@computone.com (David Johnson), vsta@cisco.com Reply-To: hjb@netcom.com Subject: Re: Dupping message data In-Reply-To: Andrew Valencia <199310131531.AA19451@glare.cisco.com> Date: Wed, 13 Oct 93 10:53:58 -0700 Status: OR i haven't been following this discussion.... so i may be talking gibberish here but... i've done ports of various versions of BSD tcp/ip code to realtime OS'es (e.g. VxWorks, my own little exec). the way i usually go about doing things is to have one thread that provide context for all network related things. it'll service a queue. when there are "networking" things to do i enqueue jobs to this queue. network thread just services each item as it gets chances to run. network interrupts are ack'ed pretty much immediately and bulk of the real work handling those interrupts (reading data, etc.) is done in the context of this thread. it's possible to have a thread for different things (e.g. fior each of the network devices, each protocol, etc.) but things usually work pretty well with just one thread. there are some places in the bsd code that are not thread-safe -- these have to be fixed up -- and/or kludged around via big mutex blocks... ;-) hwajin From vandys@cisco.com Sun Oct 17 17:01:23 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16225; Sun, 17 Oct 93 17:01:21 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24382; Sun, 17 Oct 93 17:01:30 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24272(netkeeper.sj.nec.com ); Sun, 17 Oct 93 17:01:29 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00289(archimedes.inoc.sj.nec.com ); Sun, 17 Oct 93 17:01:27 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA27854 (5.67a/IDA-1.5 for ); Sun, 17 Oct 1993 16:54:25 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00243); Sun, 17 Oct 93 16:44:18 -0700 Received: from localhost by glare.cisco.com with SMTP id AA14848 (5.67a/IDA-1.5 for ); Sun, 17 Oct 1993 16:53:40 -0700 Message-Id: <199310172353.AA14848@glare.cisco.com> To: vsta@cisco.com Subject: Status Date: Sun, 17 Oct 1993 16:53:39 -0700 From: Andrew Valencia Status: OR Hello, folks. Well, over the weekend I ported "tpr" (an old roff clone, except it's named "tpr", except I enhanced it for my wife when she was writing a book, and I named it back to "roff" :->). To benchmark it, I wanted to redirect output to /dev/null--which I didn't have! So I wrote a /dev/null server, and it worked fine. But this got me thinking--you don't *really* need a server to get /dev/null semantics. So I also added a file descriptor layer which detects that a file descriptor is open to the null device, and it stubs the operation right in the C library, without having to send a message to the /dev/null server. The result is that my wife book processes in 4 seconds--50 pages/second. :-) It was a little slower from a DOS filesystem, but under the vstafs, the file was a single contiguous extent, and was read in 4 disk I/O's (3 X 64K, plus the remainder in the 4th I/O). Fun! The filesystem is also coming along fine. My latest bug was traced to a latent bug in the libc malloc() when freeing large blocks of memory. Regards, Andy Valencia From nick@nsis.cl.nec.co.jp Sun Oct 17 17:24:50 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16230; Sun, 17 Oct 93 17:24:48 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24428; Sun, 17 Oct 93 17:24:57 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA24441(netkeeper.sj.nec.com ); Sun, 17 Oct 93 17:24:56 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00316(archimedes.inoc.sj.nec.com ); Sun, 17 Oct 93 17:24:53 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA27982 (5.67a/IDA-1.5 for ); Sun, 17 Oct 1993 17:17:26 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00256); Sun, 17 Oct 93 17:06:39 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA27974 (5.67a/IDA-1.5 for ); Sun, 17 Oct 1993 17:15:58 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA06252; Mon, 18 Oct 1993 09:15:55 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA27779; Mon, 18 Oct 1993 09:15:54 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931004.1) id AA22836; Mon, 18 Oct 1993 09:15:53 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA00169; Mon, 18 Oct 93 09:15:52 JST Date: Mon, 18 Oct 93 09:15:52 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310180015.AA00169@silk1.nsis.cl.nec.co.jp> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Sun, 17 Oct 1993 16:53:39 -0700 <199310172353.AA14848@glare.cisco.com> Subject: Status Status: OR Well, I guess I may as well send this out again: ------------------------- Project List -----+------------------------------ TASK | WHO --------------------------------------------+------------------------------ VSTa file system (Non-Unix) | vandys@cisco.com Window System (Non-X11) | nick@nsis.cl.nec.co.jp Update kbd so key mappings can be downloaded| (planned)nick@nsis.cl.nec.co.jp Update wd to handle various IDE drives | ???? Shared libraries | /proc server (for use with ps etc.) | Debugger (using /proc??) | Unix/Linux file systems | Math emulator (inside kernel? server?) | Update/expand libc (and include files) | SCSI disk server | myl@genrad.com Network server | dave@computone.com RS232c server | Porting of applications (make, emacs, ...) | --------------------------------------------+------------------------------- I spent the weekend rewriting large parts of the bitblt graphics primitives to use span filling. Does anyone have a good arc generation algorithm? The algorithm should generate each pixel in the order it appears on the line. I have one, but it skips pixels when the arc is drawn at steep angles (due to the limits of integer math I guess). Work on bitblt is moving along. No promises about completion dates though :-). Andy: What kind of book is your wife writing (out of curiosity)? From cmaeda@cs.washington.edu Mon Oct 18 00:13:13 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16357; Mon, 18 Oct 93 00:13:02 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA25337; Mon, 18 Oct 93 00:13:11 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA28069(netkeeper.sj.nec.com ); Mon, 18 Oct 93 00:13:09 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00685(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 00:13:07 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA00516 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 00:03:01 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00166); Sun, 17 Oct 93 23:51:15 -0700 Received: from june.cs.washington.edu by hubbub.cisco.com with SMTP id AA00505 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 00:00:52 -0700 Received: from localhost by june.cs.washington.edu (5.65b/7.1ju) id AA26713; Mon, 18 Oct 93 00:01:04 -0700 To: Andrew Valencia Cc: David Johnson , vsta@cisco.com Subject: Re: Dupping message data In-Reply-To: Your message of "Wed, 13 Oct 93 08:31:20 -0800." <199310131531.AA19451@glare.cisco.com> Date: Mon, 18 Oct 93 00:01:03 -0700 Message-Id: <26711.750927663@june.cs.washington.edu> From: cmaeda@cs.washington.edu Status: OR Date: Wed, 13 Oct 93 08:31:20 -0800 To: David Johnson cc: vsta@cisco.com From: Andrew Valencia Subject: Re: Dupping message data [dave@computone.com (David Johnson) writes:] >Normally packets are sent up in a STREAMS environment asynchronously to the >modules above. They process them and send them to the STREAM head which >holds them for the user. However, in the server model, how can the TCP >module keep a pending receive in the Ethernet server and still service other >write requests from above? Well, the simplest way would be to launch another thread within the TCP process (see tfork(), more comments below), have him forever post reads, then requeue the responses to the TCP queue. Something like: Threads are definitely the way to go. In the tcp implementation that I did, there was one thread waiting for incoming ethernet packets, one thread doing retransmit timers, and n threads serving read/write requests from applications. This code is based on the Berkeley implementation and is modified to work with CThreads under Mach. I can send it to anyone that wants to get it working under VSTa. An advantage to using the Berkeley code is that you get sockets compatibility for free. Chris From vandys@cisco.com Mon Oct 18 08:34:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16785; Mon, 18 Oct 93 08:34:27 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26732; Mon, 18 Oct 93 08:34:35 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03043(netkeeper.sj.nec.com ); Mon, 18 Oct 93 08:34:34 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01199(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 08:34:32 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA07955 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 08:27:02 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00075); Mon, 18 Oct 93 08:15:43 -0700 Received: from localhost by glare.cisco.com with SMTP id AA27810 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 08:25:13 -0700 Message-Id: <199310181525.AA27810@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Math emulator In-Reply-To: Your message of "Mon, 18 Oct 1993 15:36:55 +0200." <9310180636.AA26959@silk1.nsis.cl.nec.co.jp> Date: Mon, 18 Oct 1993 08:25:12 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] > does anyone have any plans to add a math emulator to the VSTa >kernel? I was wondering, because we could probably take the one from >Linux (it's under the GPL), and if we had it, it might make writing >some things a bit easier. Not only is their no thought on doing a math emulator, there's no thought on supporting a math coprocessor! I would think the best path would be to add 387 support (by that, I mean 387 as well as the 387 part of a i486), then leave hooks to do emulation when the 387 is absent. V7 UNIX did math emulation in the SIGFPE handler. I'd think this would be a good first step, since it leaves it out of the kernel. You'd definitely want to set up the C library so that the emulation code was only pulled in if floating point was used. I think GCC exports some symbols which could tip you off. Andy From hp@quasi.vmars.tuwien.ac.at Mon Oct 18 09:34:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16894; Mon, 18 Oct 93 09:34:02 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26896; Mon, 18 Oct 93 09:34:09 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA06583(netkeeper.sj.nec.com ); Mon, 18 Oct 93 09:34:08 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01365(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 09:34:04 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09811 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 09:27:44 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00115); Mon, 18 Oct 93 09:16:45 -0700 Received: from quasi.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA09760 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 09:26:11 -0700 Received: by quasi.vmars.tuwien.ac.at id AA15534 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 18 Oct 93 17:26:08 +0100 From: Peter Holzer Message-Id: <9310181626.AA15534@quasi.vmars.tuwien.ac.at> Subject: Re: Math emulator (fwd) To: vsta@cisco.com Date: Mon, 18 Oct 93 17:26:07 MET Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR [I seem to have difficulties hitting the right keys. Andy, can you configure your mailing-list server to include a Reply-To field? :-)] You (Andrew Valencia) wrote: > Not only is their no thought on doing a math emulator, there's no thought > on supporting a math coprocessor! I would think the best path would be > to add 387 support (by that, I mean 387 as well as the 387 part of a i486), > then leave hooks to do emulation when the 387 is absent. In any case the kernel needs to save the 387 status if a context switch between two processes using the 387 occurs. This shouldn't be too much work. > V7 UNIX did math emulation in the SIGFPE handler. I'd think this would > be a good first step, since it leaves it out of the kernel. How about using a soft-float library? If our shared-lib plans ever take off, this library could use 387 instructions on machines which have one, and 386 instructions on other machines. Sure this is not as fast as using inline code, but I think it is a fair compromise if you want to distribute binaries (If you really want speed, you probably want to recompile with -mi486 or something, anyway). Oh, and btw, if you are using soft-float, be sure to use no-fp-ret-in-387 too. Doesn't make too much sense to need an emulator just for function returns (like SysV). GCC 1.37 for Minix used the SIGFPE trampoline and it was really slow (of course signal delivery is somewhat complicated in Minix. Don't know about VSTa in this respect). Hmm, different idea: Can the 387-missing interrupt be redirected to the offending process without kernel interaction? This would make 387 emulation very easy and fast. Best of both worlds. Just rambling, hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | ...and it's finished! It only has to be written. __/ | -- Karl Lehenbauer -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | ...and it's finished! It only has to be written. __/ | -- Karl Lehenbauer From vandys@cisco.com Mon Oct 18 09:35:57 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16902; Mon, 18 Oct 93 09:35:55 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26912; Mon, 18 Oct 93 09:36:02 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07791(netkeeper.sj.nec.com ); Mon, 18 Oct 93 09:36:00 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01389(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 09:35:58 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA09851 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 09:29:12 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00117); Mon, 18 Oct 93 09:18:05 -0700 Received: from localhost by glare.cisco.com with SMTP id AA00936 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 09:27:34 -0700 Message-Id: <199310181627.AA00936@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Math emulator In-Reply-To: Your message of "Mon, 18 Oct 1993 17:21:34 +0700." <9310181621.AA15383@quasi.vmars.tuwien.ac.at> Date: Mon, 18 Oct 1993 09:27:34 -0700 From: Andrew Valencia Status: OR [Peter Holzer writes:] >How about using a soft-float library? If our shared-lib plans ever take >off, this library could use 387 instructions on machines which have one, >and 386 instructions on other machines. Sure this is not as fast as >using inline code, but I think it is a fair compromise if you want to >distribute binaries (If you really want speed, you probably want to >recompile with -mi486 or something, anyway). My reaction is that we may as well use the default in-line code, with the reasoning being that if you're running FP on a non-FP-equipped machine, you're really not getting performance anyway. >GCC 1.37 for Minix used the SIGFPE trampoline and it was really slow (of >course signal delivery is somewhat complicated in Minix. Don't know >about VSTa in this respect). My plan is to use the Plan9-style of signal handling. Because this specifies that signal handling completion happen with an explicit call (as opposed to UNIX, where you do a subroutine return), there is no need to do that trampoline hackery. >Hmm, different idea: Can the 387-missing interrupt be redirected to the >offending process without kernel interaction? This would make 387 >emulation very easy and fast. Best of both worlds. Since the FPU-not-present exception gets its own vector, it really shouldn't be too hard to point this back into the ring3 code somewhere. Adding this would be a nice part of the overall 387 support work. Andy From hp@quasi.vmars.tuwien.ac.at Mon Oct 18 10:08:32 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17584; Mon, 18 Oct 93 10:08:31 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26995; Mon, 18 Oct 93 10:08:39 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26532(netkeeper.sj.nec.com ); Mon, 18 Oct 93 10:08:38 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01454(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 10:08:35 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA11081 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 10:00:51 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00138); Mon, 18 Oct 93 09:49:21 -0700 Received: from quasi.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA10989 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 09:58:47 -0700 Received: by quasi.vmars.tuwien.ac.at id AA16380 (5.64+/IDA-1.3.4 for vsta@cisco.com); Mon, 18 Oct 93 17:58:46 +0100 From: Peter Holzer Message-Id: <9310181658.AA16380@quasi.vmars.tuwien.ac.at> Subject: Re: Math emulator To: vsta@cisco.com Date: Mon, 18 Oct 93 17:58:45 MET In-Reply-To: <199310181627.AA00936@glare.cisco.com>; from "Andrew Valencia" at Oct 18, 93 9:27 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Andrew Valencia) wrote: > > [Peter Holzer writes:] > > >How about using a soft-float library? If our shared-lib plans ever take > >off, this library could use 387 instructions on machines which have one, > >and 386 instructions on other machines. Sure this is not as fast as > >using inline code, but I think it is a fair compromise if you want to > >distribute binaries (If you really want speed, you probably want to > >recompile with -mi486 or something, anyway). > > My reaction is that we may as well use the default in-line code, with > the reasoning being that if you're running FP on a non-FP-equipped machine, > you're really not getting performance anyway. Yes, but for some applications it may be enough. I don't do raytracing or finite-element simulation, so FP performance is not really a concern for me. I was quite happy with Turbo-C, and very disappointed with both GCC on Minix and DJGCC, because they were at least one magnitude slower (DJGCC has become a lot better, it is now almost as fast as Turbo-C. Bruce Evans' soft-float library is a lot faster). > My plan is to use the Plan9-style of signal handling. Because this > specifies that signal handling completion happen with an explicit > call (as opposed to UNIX, where you do a subroutine return), there is > no need to do that trampoline hackery. I don't think it makes much difference, whether the signal handler itself calls sigreturn (or whatever it is called) or falls into it. The performance problem in Minix was that a hardware generated signal would trap into the kernel, which would send a message to the memory manager, which would send one to the system task, which would set up the stack for the process, make it runnable, and tell MM that all was ok. 5 task switches (between rings 0, 1, and 3) for every FP instruction. Actually the new signal code (which calls sigreturn at the end to restore the signal mask) would add another two task switches. > Since the FPU-not-present exception gets its own vector, it really > shouldn't be too hard to point this back into the ring3 code somewhere. > Adding this would be a nice part of the overall 387 support work. Good. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | ...and it's finished! It only has to be written. __/ | -- Karl Lehenbauer From vandys@cisco.com Mon Oct 18 10:28:01 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17617; Mon, 18 Oct 93 10:28:00 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA27057; Mon, 18 Oct 93 10:28:08 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27050(netkeeper.sj.nec.com ); Mon, 18 Oct 93 10:28:07 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01597(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 10:28:05 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA11707 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 10:17:07 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00145); Mon, 18 Oct 93 10:02:21 -0700 Received: from localhost by glare.cisco.com with SMTP id AA04124 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 10:11:51 -0700 Message-Id: <199310181711.AA04124@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Math emulator In-Reply-To: Your message of "Mon, 18 Oct 1993 17:58:45 +0700." <9310181658.AA16380@quasi.vmars.tuwien.ac.at> Date: Mon, 18 Oct 1993 10:11:50 -0700 From: Andrew Valencia Status: OR [Peter Holzer writes:] >> My plan is to use the Plan9-style of signal handling. Because this >> specifies that signal handling completion happen with an explicit >> call (as opposed to UNIX, where you do a subroutine return), there is >> no need to do that trampoline hackery. >I don't think it makes much difference, whether the signal handler >itself calls sigreturn (or whatever it is called) or falls into it. I hope you mean it doesn't make much difference for purposes of floating point emulation performance. It makes a BIG difference in the simplicity of the signal handling model. Without the user calling a known interface to complete signal handling, you have the problem of what return address to place on his stack. You can't just return to the interrupted code stream, because on most architectures you need to do an "iret", not just a "ret". Other actions may also be required. So where do you point to get the necessary code? There is no location in the user process which is known ahead of time. HP/UX has the C library register the location of said "trampoline" code. Exactly *where* in the C library was the source of a couple really subtle bugs. Alternatively, BSD has often placed the U area in the user's address space, put the trampoline code there, and pointed to that as the return address from the signal handler. I think Plan9's technique is far preferable, so we'll run with that as far as possible. Andy From nick@nsis.cl.nec.co.jp Mon Oct 18 21:06:04 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21715; Mon, 18 Oct 93 21:06:03 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28967; Mon, 18 Oct 93 21:06:14 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05867(netkeeper.sj.nec.com ); Mon, 18 Oct 93 21:06:13 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA03629(archimedes.inoc.sj.nec.com ); Mon, 18 Oct 93 21:06:11 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA28508 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 20:57:14 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00406); Mon, 18 Oct 93 20:44:19 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA28457 (5.67a/IDA-1.5 for ); Mon, 18 Oct 1993 20:53:58 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA00767; Tue, 19 Oct 1993 12:53:50 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA26605; Tue, 19 Oct 1993 12:53:48 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA02277; Tue, 19 Oct 1993 12:53:47 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA18707; Tue, 19 Oct 93 12:53:46 JST Date: Tue, 19 Oct 93 12:53:46 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310190353.AA18707@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Math emulator Status: OR Well, I seem to have generated some discussion :-) Anyway, I was wondering about FP support because for wide line support in bitblt, integer math is probably not going to suffice, because calculating the end cap is not trivial, and seems to require FP. (Actually, the first release of bitblt will not support wide lines because I figure they're a luxury item that can be added later, thought the hooks will be there.) I wonder: could some task be written to handle FP emulation via the 387 missing interrupt? The biggest problem I see is restoring the process that used FP. I don't know enough about the internals of VSTa to decide whether it's feasible or not, but if such a task could be written, the FP emulator of Linux could be used in it. Anyway, it seems that the kernel should at least save/restore the co-processor state on task switches. # Sorry for the late response: I've been tied up in meaningless # meetings all morning. From hp@petrus.vmars.tuwien.ac.at Tue Oct 19 03:40:10 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29712; Tue, 19 Oct 93 03:39:57 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00251; Tue, 19 Oct 93 03:40:02 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09795(netkeeper.sj.nec.com ); Tue, 19 Oct 93 03:40:01 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04106(archimedes.inoc.sj.nec.com ); Tue, 19 Oct 93 03:39:57 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA04090 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 03:33:27 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00621); Tue, 19 Oct 93 03:21:57 -0700 Received: from petrus.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA04077 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 03:31:41 -0700 Received: by petrus.vmars.tuwien.ac.at id AA03125 (5.64+/IDA-1.3.4 for vsta@cisco.com); Tue, 19 Oct 93 11:31:35 +0100 From: Peter Holzer Message-Id: <9310191031.AA03125@petrus.vmars.tuwien.ac.at> Subject: Re: Math emulator To: vsta@cisco.com Date: Tue, 19 Oct 93 11:31:34 MET In-Reply-To: <199310181711.AA04124@glare.cisco.com>; from "Andrew Valencia" at Oct 18, 93 10:11 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Andrew Valencia) wrote: > > [Peter Holzer writes:] > >I don't think it makes much difference, whether the signal handler > >itself calls sigreturn (or whatever it is called) or falls into it. > > I hope you mean it doesn't make much difference for purposes of floating > point emulation performance. It makes a BIG difference in the simplicity > of the signal handling model. Not really. The system call which is called by signal, sigaction, ... needs to pass two addresses to the kernel: The one of the signal handler and one of a function which does the cleaning up. The kernel can then build the stack so that the handler returns into the cleanup function (alternatively it can only pass the address of the cleanup function which then calls the signal handler). > You can't just return to the interrupted code > stream, because on most architectures you need to do an "iret", not > just a "ret". Other actions may also be required. You have to restore all the registers. If you want reliable signals you also have to restore the signal mask (which probably means a system call). > I think Plan9's technique is far preferable, so we'll run with that as > far as possible. If it is possible to simulate POSIX signal semantics I have no problem with that. From what you said I believe that this should be possible. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | ...and it's finished! It only has to be written. __/ | -- Karl Lehenbauer From vandys@cisco.com Tue Oct 19 08:36:48 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03931; Tue, 19 Oct 93 08:36:46 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00988; Tue, 19 Oct 93 08:36:54 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA13443(netkeeper.sj.nec.com ); Tue, 19 Oct 93 08:36:53 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04560(archimedes.inoc.sj.nec.com ); Tue, 19 Oct 93 08:36:51 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA07966 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 08:30:08 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00085); Tue, 19 Oct 93 08:18:38 -0700 Received: from localhost by glare.cisco.com with SMTP id AA20371 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 08:28:16 -0700 Message-Id: <199310191528.AA20371@glare.cisco.com> To: hp@vmars.vmars.tuwien.ac.at Cc: vsta@cisco.com Subject: Re: Math emulator In-Reply-To: Your message of "Tue, 19 Oct 1993 11:31:34 +0700." <9310191031.AA03125@petrus.vmars.tuwien.ac.at> Date: Tue, 19 Oct 1993 08:28:14 -0700 From: Andrew Valencia Status: OR [Peter Holzer writes:] >Not really. The system call which is called by signal, sigaction, ... >needs to pass two addresses to the kernel: The one of the signal handler >and one of a function which does the cleaning up. Your technique works, although it takes more storage per signal, and it moves a value for each signal interaction which is basically invariant for the life of a given process image. Optimizations of this data motion have caused problems at HP--consider vfork(), and how it can interact with process data structures which might flag optimization. I had to fix one of these while doing kernels at HP--details on request. However, I want to sensitize readers that Plan9 and VSTa signal handling is not done using such a monolithic kernel technique. The kernel does not keep per-signal state handling (in fact, in VSTa, "signals" are actually strings). A process has a single vector, and does signal handling, handler invocation, etcetera, within the process image itself. Thus, the issue of "trampoline" code becomes moot because this level of code has moved into the process image, where it can know whatever per- process symbol values it needs. I think I could emulate POSIX signals using this mechanism. The APE (ANSI Posix Environment) of Plan9 also seems to have done it starting from the same mechanism. Andy From mackinlay@garion.it.com.au Tue Oct 19 22:27:20 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05949; Tue, 19 Oct 93 22:27:16 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03395; Tue, 19 Oct 93 22:27:28 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17213(netkeeper.sj.nec.com ); Tue, 19 Oct 93 22:27:27 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07319(archimedes.inoc.sj.nec.com ); Tue, 19 Oct 93 22:27:24 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA00522 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 22:18:46 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00365); Tue, 19 Oct 93 22:07:02 -0700 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA00499 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 22:16:51 -0700 Received: from garion.it.com.au by joyce.cs.su.OZ.AU (mail from mackinlay for vsta@cisco.com) with MHSnet; Wed, 20 Oct 1993 15:16:52 +1000 Received: by garion.it.com.au (Smail3.1.28.1 #3) id m0opVvY-0000Xy5; Wed, 20 Oct 93 13:17 WST Message-Id: Subject: Re: ponderings To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Date: Wed, 20 Oct 1993 13:17:39 +0800 (WST) From: Pat Mackinlay Cc: vsta@cisco.com Reply-To: pat@it.com.au In-Reply-To: <9310192324.AA28973@silk1.nsis.cl.nec.co.jp> from "Gavin Thomas Nicol" at Oct 20, 93 08:24:38 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 628 Status: OR > I should note that even though I like the idea, I currently plan to do > the messaging in a different way. VSTa *is* an experimental system > though, so if I get positive feedback, I might just go ahead and do > it. I must say that I'm a fan of the concept. The only further point I'd like to add is that using Display Postscript (ala NeXT) would also buy you the ability to produce printer output with minimal effort. On the downside, implementing a PS rasterizer would not be simple. Perhaps the engine of ghostscript could be useful? Anyhow, I really do like this idea, so consider this a vote for it . -- Pat. From basile@soleil.serma.cea.fr Wed Oct 20 04:44:50 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09143; Wed, 20 Oct 93 04:44:44 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04404; Wed, 20 Oct 93 04:44:38 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA20470(netkeeper.sj.nec.com ); Wed, 20 Oct 93 04:44:44 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07698(archimedes.inoc.sj.nec.com ); Wed, 20 Oct 93 04:44:34 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA04658 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 04:36:29 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00566); Wed, 20 Oct 93 04:25:02 -0700 Received: from mhs-relay.cs.wisc.edu by hubbub.cisco.com with SMTP id AA04637 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 04:34:55 -0700 X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 20 Oct 1993 06:34:39 +0000 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Wed, 20 Oct 1993 06:33:56 +0000 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; Wed, 20 Oct 1993 06:33:48 +0000 Date: Wed, 20 Oct 1993 06:33:48 +0000 X400-Originator: basile@soleil.serma.cea.fr X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=cea/ADMD=atlas/C=FR/;751117253@oeillet.saclay.cea.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: programmable ... From: Basile STARYNKEVITCH Message-Id: <9310201133.AA07604@soleil.serma.cea.fr> To: nick@nsis.cl.nec.co.jp, vsta@cisco.com Subject: programmable window systems like NeWS; was Re: ponderings X-Sun-Charset: US-ASCII Status: OR ># From: Gavin Thomas Nicol ># To: vsta@cisco.com ># Subject: ponderings ># ># Can anyone point me to and FTP site with papers on Sun NEWS? ># ># Last night, I played with the idea of MADO messages being in some ># language (the choice of language would probably be one of lisp, ># postscript, forth, or a specially written one). Sun NEWS, and NeXT use ># a kind of postscript, and they seem to be very good. ># ># At first I thought that it must be really bad for performance, but ># later, I was thinking of all the things people do with a window ># system. Basically, I thought of 3 things: display text, draw graphics, ># and use UI's. I figure that if some of the larger, but frequently used ># UI operations (for example menu's), could be "downloaded", it would ># probably reduce the amount of client->window system traffic a lot (ie. ># instead of sending perhaps 20 draw messages, we just send one "call ># function" message. It would seem that, provided we have a fast ># language intepreter, performance would *increase*, especially network ># performance. Also, client programs using UI's might become ># smaller/simpler. This idea could be extended to bitblt as well. For ># example, if a user downloads a menu into MADO, it could download the ># drawing parts to bitblt. I kind of like the idea. Does anyone have any ># comments? ># ># I should note that even though I like the idea, I currently plan to do ># the messaging in a different way. VSTa *is* an experimental system ># though, so if I get positive feedback, I might just go ahead and do ># it. ># I don't have any FTP site adress for Sun NeWS. However, I did program several thousands of lines of NeWS, and can summarize my experience and critics. I also did some Xlib programming, thus knowing the essential of X11. I am *not* a VSTa expert (or even a VSTa user yet). I just read some Vandys' introductory papers on it (and also Mach3 papers). [[practical reasons for not yet using VSTa:: Actually my home 486DX2/66 PC (with 16Mb RAM and 240Mb IDE disk) is running Linux 0.99pl13; i have an ultrastor34f -an VLB scsi2 controller- with which i still have problems (possibly a hardware problem realted to a cheap ET-4000 VLB graphic card). As soon as my ultrastor34f will be running reliably, i would be able to use at last my second scsi (240Mb) disk and, most importantly, my QIC150 archiv viper tape streamer. Thus i would be able to backups. Once backups are possible, i will do some experience with VSTa (perhaps even, if time permit, write a VSTa file system server compatible with Linux Ext2 FS). ]] ======================================================================= A point of view on the NeWS window system. by Basile STARYNKEVITCH, october 1993, email= basile@soleil.serma.cea.fr (you are permitted to distribute verbatim this text) A. Introduction and overview. ----------------------------- NeWS was a great thing from Sun (it is a dead Sun product; in SunOS5.3, coming out FCS in december 1993, there is no more NeWS, just an X11R5 server with Display Postscript) . NeWS means Network extensible Window System (or Server). Actually, Sun's window server was a mixture of NeWS and X11R4, but these can be almost viewed as 2 different servers sharing common devices (mouse, keyboard, screen). More precisely, the X11 server was a special NeWS lightweight process (see below). NeWS and X11 had different ports and different protocols. I am talking of the latest NeWS server (in Openwin3). Integrating NeWS and X11 was a difficult problem to Sun, and they did not succeed perfectly on it. The NeWS3 reference manual has part number 800-6736-10 from SunSoft (september 1991). The NeWS Toolkit 3 reference manual has part number 800-6319-10. The key idea of NeWS (and you already know it) was that the window server was programmable. So a typical NeWS client: 1) initialized a connection to the NeWS server. 2) defined (or extended) his own protocol by defining specific NeWS procedures. 3) then, talked to and from the server only in this newly defined protocol. Actually, a client did not talk naked NeWS but used a big library (written in NeWS, more than 30000 lines of NeWS source code, and loaded into the server at server initialization time) called The News Toolkit (or TNT). TNT code handled connection initiation and termination, global selection processing, keyboard maps, and provided an object extension to NeWS. The initialization of the NeWS server took more than 10 seconds. TNT provided an OpenLook compliant widget toolkit (mostly running in the server). NeWS is a superset of PostScript. I assume you are familiar of most PostScript ideas (it is a stack language, and uses several almost independent stacks, including a call stack, an operator stack, a graphic state stack, a message sent stack -for object oriented programming support- and a dictionnary stack. A dictionnary hold variable bindings; it is a finite set of name (or key) to value bindings). I also assume you know some basics of window systems such as X11. B. NeWS objects --------------- NeWS data are atoms (numbers, booleans, strings, and names, quite like in lisp, where names are called symbols), arrays, dictionnaries, events, canvases, lightweight processes (or lwps) and others (fonts, etc). Composite objects (arrays, dictionnaries, etc) contain (reference to) any kind of objects (perhaps themselves). Executable arrays are NeWS program fragments. All variable bindings (ie values) are thru dictionnaries (in contrast to Scheme or Lisp), so a variable is just a name, and a name has no internal content (except its immutable string of characters designation), and the value of a variable is obtained by scanning the dictionnary stack until a dictionnary containing the variable as a key is found. NeWS is a reference counting garbage collected system. Window system specific objects such as canvases, events, lwps are magic dictionnaries. They are magic in the sense that changing some particular key value in such objects could have some important side effect. Also, magic dictionnaries should have some fixed names (or keys) and are created with them. All dictionnaries (magic or not) can have any additional keys added into. Magic keys have some specific predefined names. Canvases are very similar to X11 windows. There is a hierarchy (tree) of canvases, analog to the X11 window hierarchy. A canvas is a magic dictionnary. Hence mapping a canvas is done by changing the /Mapped key to true. Canvases are part of graphic contexts, so all graphic operators are executed in a given canvas (much as on a PostScript printer all graphics are executed on the paper). The top of the canvas hierarchy is a virtual root canvas, containing several physical screen canvases. Canvases, (like postscript printer devices) contains a coordinate transformation matrix and an enclosing (clipping) path. In effect, canvas can have arbitrary shapes (it is possible to have a round canvas to implement a round clock). Canvases have cursors. Each canvas has an interest list, which gives the event the canvas is interested in. X11 windows are special kind of canvases. Events are somelike analog to X11 events. The main difference is that an event is not a protocol message; it is generated (by NeWS code or by physical devices such as mouse and keyboard) and handled inside the NeWS server thru appropriate client loaded code. Events are also magic dictionnaries, containing /Name, /Action, /Canvas, /TimeStamp, /Coordinates and several other important keys. The system generate events. For instance, a mouse left button press generate an event whose /Name is /LeftMouseButton, whose /Action is /DownTransition, whose /Canvas is the canvas inside which the mouse cursor was, and whose /TimeStamp and /Coordinates indicate unique time&space measures. There is a global event queue (containing unhandled events) and events are distributed (ie copied) to each lwp expressing an interest into it. Interests are templates or patterns for events. Syntactically, an interest is an event with the /Interest key set to true. NeWS operators exist for event (or interest) creation, event sending (ie adding an event to the global event queue, where system initiated events are also automagically added), and interest expression. All events are put in the global event queue (by /TimeStamp order), either because they are automagically generated (eg a keypress) or because they are explicitly sent in NeWS code (thru the sendevent NeWS primitive). So, events are also used as interclient communication (such as selection processing). In practice, hardware generated events are handled by existing NeWS code (ie the TNT library, see below) which sometimes translate them into higher level events. Hence, event can be used for agent style programming. Global selection processing (eg cut&paste) was partly done in NeWS global code (inside TNT) using such program generated (and not device generated) events. Beside obvious hardware related events (mouse & keyboard press, release, motion, etc) the NeWS server generates 2 important kinds of events: /Damage & /Obsolete events. Damage events (whose /Name is /Damage) are similar to X11 expose events and are generated when a canvas (or part of it) is damaged (because it just became visible). Damage events gives a damagepath, which enclose the canvas region needed to be repainted. Obsolete events (whose /Name is /Obsolete) are generated by the garbage collector for finalization purposes. Each object reference in NeWS can be hard (the usual default case) or soft (an object reference may be made soft thru the soften NeWS primitive, and can be made hard by the harden NeWS primitive). When all references to an object are soft, an Obsolete event is generated (whose /Action jey is the obsoleted object). This permits some cleanup. In particular, every cycle of references (and these are very common in windowing systems) should contain at least one soft reference. A NeWS lightweight process (or lwp) is a virtual NeWS executing machine inside the NeWS server. So it is a NeWS interpreter. Each lwp is a magic dictionnary containing among others an /OperandStack, a /DictionnaryStack, an /ExecutionStack, a /SendStack, an /EventQueue (containing events distributed from the global event queue into this lwp but not yet processed), an /Interests array which give the template of events interesting for this lwp. Lwps are grouped in process groups. Of course, all lwps are internal to the NeWS server; as seen from the Unix kernel, there is only one Unix process which is the NeWS server itself! Most lwps are of course asleep, usually awaiting for input (on a socket from the client Unix process) or for an incoming event thru the awaitevent NeWS primitive. Synchronization primitives (in particular monitors) are provided for serialization between lwps. C. Using NeWS ------------- In practice, NeWS was used with TNT. TNT contained code for NeWS server initialization (including keyboard mapping) and for widget programming. TNT is mostly made of a (multiinheritance) class hierarchy. NeWS classes and instances are dictionnaries (magic or normal). The send (object oriented message primitive) operator is a NeWS primitive, but the class hierarchy was in TNT (and TNT was delivered as 32000 lines of source NeWS code). The NeWS server initialization was another 21000 lines of source NeWS code. In practice most NeWS object creation (eg creation of interests, lwps, canvases) was done by instantiation of (client specific subclasses of) TNT classes. OpenLook widgets such as text fields, menus, buttons, etc are provided by TNT classes (and subclasses of a ClassCanvas provided in TNT). Window managment (in the sense of X11 wms) could be done partly or completely within NeWS. The NeWS initialization code started several NeWS system lwps, including a NeWS listener (just for listen(2) and accept(2) socket calls), an X11 listener, a GlobalEventMgr and a GlobalSystemEventMgr (handling system wide NeWS events, including selection processing). When a new Unix process make a successful connection to the NeWS server, this connection (handled by the NeWS listener) made a new NeWS lwp specific to this Unix NeWS client. This lwp just read NeWS stuff from the wire (ie connection to Unix client) and interpreted it. Data exchanges between NeWS and client is either in plain (printable) ascii or in a more compressed (somehow binary encoded) format. Each NeWS input token was in ascii (if it started with a printable ascii character >=0x20 and <0x7f) or in binary encoded form (if starting with a byte >=0x80, specifing the format and length of following bytes). A NeWS object can be designed in ascii by its name or in binary by its number in a connection specific array. Conventionnally, a well behaved NeWS client has 2 NeWS lwps: the client NeWS interpreter, created by the NeWS system listener lwp (itself created at NeWS startup time), and a local event manager (created by appropriate class instantiation at client initialization). The local event manager expresses interests in all events pertinent for the client (it was attached to activated canvases). A typical client send specific definitions (class definition for new widgets or new widgets variants; instanciation of classes for new object creations). The loaded code either handled events locally (eg keystrokes into a text widget are interpreted by TNT textwidget code to fill or edit the text widget's value) and at some times send a message back to the client. Hence, the expected wire bandwith was low; for instance, a client recieved NeWS messages only when a text widget was filled (by pressing a return key) and not at each keypress. Similarily, most repainting (eg Damage events) is done inside TNT and does not require client intervention. Some simple applications (eg a calculator, or a window manager) could even be written entirely in NeWS. A very simple client program, called psh, was used as a NeWS shell. psh just opened a NeWS connection and copied all its stdin into this connection. A simple programming utility, called CPS, generated C code for sending fixed form NeWS messages in binary form. Essentially, it generated printf-like formats and statements. NeWS3 also contains a package system. D. Critics ---------- NeWS was in practice quite slow. Waiting half a minute before seeing the first window is very annoying. I think that NeWS lacked of easy extension capabilities (ie adding new NeWS primitives programmed in compiled C code, in a dynamically loaded shared library). Most of NeWS failure was marketing, not technology. I think (as several others) that Sun should have put NeWS in the public domain. In practice, i think that a fixed widget set could have been compiled into a programmable window server. In other words, big parts of the TNT widget code should have been rewritten in C and provided as NeWS primitives. Perhaps a NeWS to C compiler could have been nice. Ideally, an online, incremental, compiler would have been great: the client could upload some code which could be compiled on the fly, hence providing the best of 2 words: extensibility by code uploading and speed by compilation. Choosing PostScript as a programming langage was in my opinion a bad idea. Debugging NeWS scripts and codes was really difficult (first because of a lack of a good debugger, and mostly because stack oriented languages such as PostScript or Forth are not enough structured: passing an extra argument, or forgeting one, is a common error, which is very difficult to detect, since there is no argument list, but just an operator stack; the extra argument was kept on the stack and incorrectly used later). I suggest using a small Scheme-like dialect for programmable servers, because Scheme is a structured and powerful, but yet small, language (of course, bignums should be excluded since they are useless in window systems); and Scheme to C compilers seems to exist somehow. Having interpreters (lwps in NeWS) independent from client connections is too general (and de facto unused in NeWS). I suggest attaching one interpreter to each client connection. Also, I think that all messages should be syntaxically alike (in NeWS terminology, even input from the client connection should have been handled as an event). I think that the imaging model (a complete transformation matrix with a general clipping path) of PostScript (or NeWS) is too general (and too expensive) for ordinary window systems. Plain rectangular window with fixed pixel-based coordinates (ie the plain X11 imaging model) should be enough for windowing system (and high multimedia technology needs perhaps even more than PostScript like sophisticated coordinate systems). In my opinion, a programmable window server should already provide some fixed low level Graphical User Interface (eg elementary widgets like buttons, menus, multifont text fields and labels); having it wired into the server langage would make more consistent look&feel. Also, i strongly suggest writing (for prototyping and pedagogical purposes) an X11 client emulating most of the proposed window server programmable protocol. Perhaps looking into Tk would be a good idea, although i think that tcl is not really appropriate as a server language. Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 Linuxing at home only. PS. Forgive me my english; it is a foreign language to me 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@cisco.com Wed Oct 20 09:10:02 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00299; Wed, 20 Oct 93 09:10:00 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00616; Wed, 20 Oct 93 09:10:08 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23331(netkeeper.sj.nec.com ); Wed, 20 Oct 93 09:10:06 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08078(archimedes.inoc.sj.nec.com ); Wed, 20 Oct 93 09:10:03 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA10167 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 09:02:38 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00083); Wed, 20 Oct 93 08:51:35 -0700 Received: from localhost by glare.cisco.com with SMTP id AA17027 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 09:01:26 -0700 Message-Id: <199310201601.AA17027@glare.cisco.com> To: pat@it.com.au Cc: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol), vsta@cisco.com Subject: Re: ponderings In-Reply-To: Your message of "Wed, 20 Oct 1993 13:17:39 +0800." Date: Wed, 20 Oct 1993 09:01:26 -0700 From: Andrew Valencia Status: OR [Pat Mackinlay writes:] >I must say that I'm a fan of the concept. The only further point I'd like >to add is that using Display Postscript (ala NeXT) would also buy you the >ability to produce printer output with minimal effort. On the downside, >implementing a PS rasterizer would not be simple. Perhaps the engine of >ghostscript could be useful? Ouch. If the performance of ghostscript overall is any indicator of the performance of its postscript engine, then I can guarantee you that *I* will stick with the cons server! A generalized interpreter might be overkill. I definitely *do* like the idea of having a base set of "widgets" on the server, common to all applications. Frankly, if you give me windows, pull-down menus, mouse, keyboard, and perhaps a pop-up or two then I think I can do all the window programming needed. The continuity it would provide across applications seems to me a feature, not a bug. My intention has been to create a mailing list for MADO when discussion really starts rolling. Nick, I will leave it to you as to when you would like it created. Andy From nick@nsis.cl.nec.co.jp Tue Oct 19 16:34:38 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05403; Tue, 19 Oct 93 16:34:29 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02501; Tue, 19 Oct 93 16:34:33 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA13043(netkeeper.sj.nec.com ); Tue, 19 Oct 93 16:34:31 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06551(archimedes.inoc.sj.nec.com ); Tue, 19 Oct 93 16:34:30 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA24034 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 16:26:35 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00250); Tue, 19 Oct 93 16:15:05 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA23969 (5.67a/IDA-1.5 for ); Tue, 19 Oct 1993 16:24:47 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA12454; Wed, 20 Oct 1993 08:24:41 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA00884; Wed, 20 Oct 1993 08:24:40 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA09217; Wed, 20 Oct 1993 08:24:39 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA28973; Wed, 20 Oct 93 08:24:38 JST Date: Wed, 20 Oct 93 08:24:38 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310192324.AA28973@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: ponderings Status: OR Can anyone point me to and FTP site with papers on Sun NEWS? Last night, I played with the idea of MADO messages being in some language (the choice of language would probably be one of lisp, postscript, forth, or a specially written one). Sun NEWS, and NeXT use a kind of postscript, and they seem to be very good. At first I thought that it must be really bad for performance, but later, I was thinking of all the things people do with a window system. Basically, I thought of 3 things: display text, draw graphics, and use UI's. I figure that if some of the larger, but frequently used UI operations (for example menu's), could be "downloaded", it would probably reduce the amount of client->window system traffic a lot (ie. instead of sending perhaps 20 draw messages, we just send one "call function" message. It would seem that, provided we have a fast language intepreter, performance would *increase*, especially network performance. Also, client programs using UI's might become smaller/simpler. This idea could be extended to bitblt as well. For example, if a user downloads a menu into MADO, it could download the drawing parts to bitblt. I kind of like the idea. Does anyone have any comments? I should note that even though I like the idea, I currently plan to do the messaging in a different way. VSTa *is* an experimental system though, so if I get positive feedback, I might just go ahead and do it. BTW. It seems that GUI's were far from Rob Pike's mind when he wrote 8.5. I plan to eventually write a UI toolkit for VSTa and MADO (Actually, I plan to port a few UI toolkits I've written/am writing). However, for now, my main goal is to have most text-based programs run without changes, and to provide a small, flexible API. From nick@nsis.cl.nec.co.jp Wed Oct 20 16:48:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15167; Wed, 20 Oct 93 16:48:33 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01904; Wed, 20 Oct 93 16:48:41 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22217(netkeeper.sj.nec.com ); Wed, 20 Oct 93 16:48:40 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09675(archimedes.inoc.sj.nec.com ); Wed, 20 Oct 93 16:48:38 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA24866 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 16:41:18 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00297); Wed, 20 Oct 93 16:29:36 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA24806 (5.67a/IDA-1.5 for ); Wed, 20 Oct 1993 16:39:28 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA08805; Thu, 21 Oct 1993 08:39:22 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA12053; Thu, 21 Oct 1993 08:39:21 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA28972; Thu, 21 Oct 1993 08:39:20 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA14352; Thu, 21 Oct 93 08:39:18 JST Date: Thu, 21 Oct 93 08:39:18 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310202339.AA14352@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Status: OR jont@hsa.com.au writes: >My system was this: > > +------+<->+----------------+ +---------------+ > |window|<->|appl 1 front end|<---------->| application 1 | > |system|<->+----------------+ protocol 1 +---------------+ > | |<-> > +------+<->+----------------+ +---------------+ > MADO |appl n front end|<---------->| application n | > +----------------+ protocol n +---------------+ OK. Given the architecture I defined, this would be possible (and perhaps a good idea. You could provide menus etc. to text based programs). Basile STARYNKEVITCH : Thank you *very* much for the article. I should note that if I do add an interpreter to MADO et al. it will probably be scheme (in fact, I'd probably use a hacked version of siod in the beginning), because 1) I'd prefer a language I can understand/debug easily, and 2) >Ouch. If the performance of ghostscript overall is any indicator of the >performance of its postscript engine, then I can guarantee you that *I* >will stick with the cons server! Exactly. Ghostscript is painfully slow, and requires a lot of memory. >A generalized interpreter might be overkill. I definitely *do* like the >idea of having a base set of "widgets" on the server, common to all >applications. Frankly, if you give me windows, pull-down menus, >mouse, keyboard, and perhaps a pop-up or two then I think I can do >all the window programming needed. The continuity it would provide >across applications seems to me a feature, not a bug. I tend to agree, as far as GUI's are concerned. In fact, I would probably use Basile's idea, and write them in C, in the server. However, for graphics (which, I do little of, but...), I think it could be very advantageous to be able to download a function to generate a lot of the drawing, than to do the drawing directly. I'll ponder this some more. From the looks of it, most people seem to think that: 1) Basic rectangular windows will suffice (and I never planned it any other way). 2) A basic widget set built into the window server would be a win. 3) A programmable server seems desirable. BTW. The notion of using display postscript, and thereby gaining the ability to send stuff to the printer seems to be to be a nice feature, but not too important. People display stuff on a screen far more often than they do on a printer. Provided that either a) the application, or b) the window system can generate postscript on request, I don't see a problem. (Actually, I'd tend to offload this onto the application). From nick@nsis.cl.nec.co.jp Fri Oct 22 02:23:24 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28446; Fri, 22 Oct 93 02:23:08 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07515; Fri, 22 Oct 93 02:23:18 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11105(netkeeper.sj.nec.com ); Fri, 22 Oct 93 02:23:16 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13842(archimedes.inoc.sj.nec.com ); Fri, 22 Oct 93 02:23:13 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02205 (5.67a/IDA-1.5 for ); Fri, 22 Oct 1993 02:15:22 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00525); Fri, 22 Oct 93 02:03:20 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA02184 (5.67a/IDA-1.5 for ); Fri, 22 Oct 1993 02:13:21 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA21013; Fri, 22 Oct 1993 18:13:11 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA25026; Fri, 22 Oct 1993 18:13:10 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA20886; Fri, 22 Oct 1993 18:13:09 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA19951; Fri, 22 Oct 93 18:13:07 JST Date: Fri, 22 Oct 93 18:13:07 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310220913.AA19951@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Window system Status: OR After some thought, for better, or for worse, I have decided on the following points: 1) Messaging will be in scheme, or a lisp dialect. This means messages from the application to MADO, and message from MADO to bitblt. 2) MADO will have a built in widget set. They will be compiled into the server. 3) MADO must be able to run within itself (ie. it will provide a compatible superset of the language to applications). 4) The system should be able to generate user-defined events. 5) Is lisp proves expensive, I might use an assemblerish labguage I designed for my son (it's kind of a turtle graphics language), or I might remove the general programming language idea entirely. Currently, I plan to use a hacked version of siod, because it is small. Unfortunately, the code is a little on the ugly side. If someone on the list knows of another, small, clean, scheme, I'd be happy to hear about it (by small, I mean it will take up less than 75k of disc when compiled on a Sun, and < 30K on a VAX/CISC). To get a scheme working, and setup to run as a messaging server will take some time (a couple of weeks or so), which will delay the first pre-release of bitblt, though if someone want to start porting it, most of the core stuff is now done. Some things, like wide line support, and ppm support are lacking, but they can be added later. From basile@soleil.serma.cea.fr Fri Oct 22 03:27:01 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00654; Fri, 22 Oct 93 03:26:39 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07728; Fri, 22 Oct 93 03:26:48 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12016(netkeeper.sj.nec.com ); Fri, 22 Oct 93 03:26:47 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13884(archimedes.inoc.sj.nec.com ); Fri, 22 Oct 93 03:26:44 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA03856 (5.67a/IDA-1.5 for ); Fri, 22 Oct 1993 03:13:59 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00581); Fri, 22 Oct 93 02:55:08 -0700 Received: from mhs-relay.cs.wisc.edu by hubbub.cisco.com with SMTP id AA03800 (5.67a/IDA-1.5 for ); Fri, 22 Oct 1993 03:05:18 -0700 X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 22 Oct 1993 05:05:02 +0000 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Fri, 22 Oct 1993 05:04:30 +0000 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; Fri, 22 Oct 1993 05:04:25 +0000 Date: Fri, 22 Oct 1993 05:04:25 +0000 X400-Originator: basile@soleil.serma.cea.fr X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=cea/ADMD=atlas/C=FR/;751284689@oeillet.saclay.cea.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Window sy... From: Basile STARYNKEVITCH Message-Id: <9310221004.AA11313@soleil.serma.cea.fr> To: nick@nsis.cl.nec.co.jp, vsta@cisco.com Subject: Re: Window system X-Sun-Charset: US-ASCII Status: OR ># From nick@nsis.cl.nec.co.jp Fri Oct 22 10:17:36 1993 ># ># After some thought, for better, or for worse, I have decided on the ># following points: ># ># 1) Messaging will be in scheme, or a lisp dialect. This means messages ># from the application to MADO, and message from MADO to bitblt. ># ># 2) MADO will have a built in widget set. They will be compiled into ># the server. ># ># 3) MADO must be able to run within itself (ie. it will provide a ># compatible superset of the language to applications). **** I do not understand this point **** ># ># 4) The system should be able to generate user-defined events. ># ># 5) Is lisp proves expensive, I might use an assemblerish labguage I ># designed for my son (it's kind of a turtle graphics language), ># or I might remove the general programming language idea entirely. **** please keep the server programmable! **** I agree with all these choices. (i don't know yet about MADO or VSTa, but i'm the guy who posted a long NeWS description 2 days ago). Perhaps you could have a look into scheme48-0.22 (it is still a Beta version, but it works fine), by Richard Kelsey and Jonathan Rees (MIT). You can ftp it from altdorf.ai.mit.edu:/pub/jar (files scheme48-0.22.tar for the program, and lsc.ps for a draft of a paper in Lisp & Symbolic Computation which describes it). Email to Jonathan Rees at jar@altdorf.ai.mit.edu or jar@cs.cornell.edu for more details. He considers scheme48 in early beta stage, but i find it more usable, and much faster, that scm or siod. What is scheme48? It is an implementation of IEEE (or R4RS) scheme. It main features are: * a powerful module system, inspired from SML modules. * an efficient bytecode virtual machine interpreter. Its executes templates (bytecode fragment + array of scheme objects). * a scheme compiler, written in IEEE scheme, and producing bytecode templates executed by the virtual machine. So a scheme program is first compiled into bytecode and then executed. All of scheme48 is written in scheme dialects, including the bytecode virtual machine interpreter (hence also the runtime system, eg garbage collector). This interpreter is written in PreScheme which is compiled into C (once for all). The scheme48 virtual machine is rather small: Under my SunOS5.2 sparc machine (and compiled with gcc2.4.5. -O2) size -Ffn scheme48vm scheme48vm.unstripped scheme48vm: 17(.interp) + 1616(.hash) + 3056(.dynsym) + 1987(.dynstr) + 24(.rela.bss) + 564(.rela.plt) + 88(.init) + 30852(.text) + 12(.fini) + 1952(.rodata) + 8(.ctors) + 8(.dtors) + 6(.rodata1) + 616(.plt) + 8(.data) + 12(.got) + 160(.dynamic) + 1804(.bss) + 207(.shstrtab) + 818(.comment) = 43815 scheme48vm: 160(r-x) + 17(r--) + 40354(r-x) + 2604(rwx) + 160(rwx) = 43295 scheme48vm.unstripped: 17(.interp) + 1616(.hash) + 3056(.dynsym) + 1987(.dynstr) + 24(.rela.bss) + 564(.rela.plt) + 88(.init) + 30852(.text) + 12(.fini) + 1952(.rodata) + 8(.ctors) + 8(.dtors) + 6(.rodata1) + 616(.plt) + 8(.data) + 12(.got) + 160(.dynamic) + 1804(.bss) + 3968(.symtab) + 2537(.strtab) + 256(.stab.indexstr) + 36924(.stabstr) + 207(.shstrtab) + 144(.stab.index) + 818(.comment) + 83424(.stab) = 171068 scheme48vm.unstripped: 160(r-x) + 17(r--) + 40354(r-x) + 2604(rwx) + 160(rwx) = 43295 -rwxr-xr-x 1 basile group_ia 43076 Oct 22 10:23 scheme48vm -rwxr-xr-x 1 basile group_ia 170568 Oct 22 10:23 scheme48vm.unstripped wc *.[ch] 479 1546 12866 dynload.c 27 58 501 error.c 317 1056 8050 extension.c 146 471 3637 main.c 35 156 1024 prescheme.h 54 212 2003 scheme48.h 6747 22962 212430 scheme48vm.c <<<< this file is made of C generated by a PreScheme compiler 6 10 58 test.c 327 909 7516 unix.c 8138 27380 248085 total I think that the main advantage of a bytecompiled scheme implementation for a window system (MADO) is that: The programmer codes MADO server application-specific code in high level language such as scheme. He/she compiles it into scheme48 bytecode image. At run time, the application downloads the scheme48 bytecode image into the MADO window server. Since it is a simple bytecode, its interpretation is fast (probably as fast as a very simple stack language), and faster that simple interpretation of scheme code represented by lists (as SIOD or SCM are doing). So this approach, in contrast to NeWS programming I discussed in an earlier post, is easy to program (because Scheme is higher level than PostScript or Forth) is efficient to execute. In comparaison, scm4c0 is more that 4 times larger than scheme48 virtual machine. Of course, the full initial memory image of scheme48 (including compiler, command interpreter) is quite large (838kbytes) but a window server nevers needs such a full system (i don't want to compile to bytecode inside the window server!), and i suppose that a small application specific server library would be much smaller (30-300kbytes?). Ultimately, it would have been interesting to have a real compiler for bytecodes (ie to have a common, plateform independent, intermediate bytecode which would be compiled at load time in the server into target machine code), but i'm not sure that this technology is easily availabel today. the OSF ANDF proposal is something in that way, but i don't think it is running today. Also, i think that for efficiency and evolution reasons, dynamic loading of machine code extension (ie of a shared library prodced by a C compiler) is a must while prototyping MADO. You don't know exactly what common features should be programmable (in scheme or whatever language you choose) and what other features should be wired into the window server. Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. From nick@nsis.cl.nec.co.jp Sun Oct 24 16:42:57 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22211; Sun, 24 Oct 93 16:42:55 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17215; Sun, 24 Oct 93 16:43:10 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21191(netkeeper.sj.nec.com ); Sun, 24 Oct 93 16:43:10 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17951(archimedes.inoc.sj.nec.com ); Sun, 24 Oct 93 16:43:08 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA17610 (5.67a/IDA-1.5 for ); Sun, 24 Oct 1993 16:35:55 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00208); Sun, 24 Oct 93 16:23:03 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA17594 (5.67a/IDA-1.5 for ); Sun, 24 Oct 1993 16:33:40 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA06094; Mon, 25 Oct 1993 08:33:36 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA21367; Mon, 25 Oct 1993 08:33:35 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA29242; Mon, 25 Oct 1993 08:33:34 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA01565; Mon, 25 Oct 93 08:33:33 JST Date: Mon, 25 Oct 93 08:33:33 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310242333.AA01565@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Basile STARYNKEVITCH's message of 22 Oct 93 11:04:25+0100 <9310221004.AA11313@soleil.serma.cea.fr> Subject: Window system Status: OR >># 3) MADO must be able to run within itself (ie. it will provide a >># compatible superset of the language to applications). > **** I do not understand this point **** The point is that if bitblt, and MADO use the same messaging system, MADO will be able to run within a window. However, after playing around on the weekend, I'm not sure it's such a good idea. The mouse, and possibly keyboard driver would also need to use the same messaging system, which means interpretation at all levels. It would be amazingly flexible, but perhaps also, amazingly slow. I think I'll give up on that idea, and instead, rely on a common API at the C level, rather than a common API at the messaging level. I'll have a look into scheme48. After looking at it, I'll decide whether to use siod (initially, maybe later it could be replaced), or scheme48. I might also take your advice and do the initial version under X and Unix. Actually, you might be interested to know that I once wrote a distributed multimedia/UI toolkit based on Xlisp. It worked reasonably well, and having a programmable system made testing very, very easy. From nick@nsis.cl.nec.co.jp Mon Oct 25 01:49:52 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22455; Mon, 25 Oct 93 01:49:51 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18556; Mon, 25 Oct 93 01:50:03 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26318(netkeeper.sj.nec.com ); Mon, 25 Oct 93 01:50:01 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18446(archimedes.inoc.sj.nec.com ); Mon, 25 Oct 93 01:49:59 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA20980 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 01:41:33 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00385); Mon, 25 Oct 93 01:29:08 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA20961 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 01:39:43 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA19542; Mon, 25 Oct 1993 17:39:34 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA19448; Mon, 25 Oct 1993 17:39:34 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA27119; Mon, 25 Oct 1993 17:39:33 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA14674; Mon, 25 Oct 93 17:39:31 JST Date: Mon, 25 Oct 93 17:39:31 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310250839.AA14674@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Schemes Status: OR I looked at scheme48, and another scheme called SECDR. They both look fine for a window system *except* that they both boot up with 5MB of memory used. I know they are both tuneable, and eventually, I'll incorporate one of them into the system. However, for now, I'll run with siod (which boots with 250K used). Also, siod is (perhaps) easier to understand. From nick@nsis.cl.nec.co.jp Mon Oct 25 22:53:37 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23884; Mon, 25 Oct 93 22:53:36 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22212; Mon, 25 Oct 93 22:53:53 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03368(netkeeper.sj.nec.com ); Mon, 25 Oct 93 22:53:52 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21306(archimedes.inoc.sj.nec.com ); Mon, 25 Oct 93 22:53:49 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA21074 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 22:44:25 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00101); Mon, 25 Oct 93 22:32:50 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA21070 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 22:43:33 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA00379; Tue, 26 Oct 1993 14:43:22 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA22477; Tue, 26 Oct 1993 14:43:22 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA11107; Tue, 26 Oct 1993 14:43:21 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA29981; Tue, 26 Oct 93 14:43:20 JST Date: Tue, 26 Oct 93 14:43:20 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310260543.AA29981@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Font naming conventions Status: OR Does anyone have any comments on the font naming conventions to be used in bitblt/MADO? For the moment, I'm just giving arbitrary name, for example: courier_bold_oblique_12pt The current design allows me to change naming schemes easily, so if someone has information on the "right" way of doing it, please comment. X11 font naming seems to work well, but I think it's overly complex... nick From basile@soleil.serma.cea.fr Tue Oct 26 00:59:41 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24009; Tue, 26 Oct 93 00:59:32 PDT Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22597; Tue, 26 Oct 93 00:59:47 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04673(netkeeper.sj.nec.com ); Tue, 26 Oct 93 00:59:46 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21478(archimedes.inoc.sj.nec.com ); Tue, 26 Oct 93 00:59:40 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA22131 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 00:49:57 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00143); Tue, 26 Oct 93 00:36:48 -0700 Received: from mhs-relay.cs.wisc.edu by hubbub.cisco.com with SMTP id AA22112 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 00:47:42 -0700 X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Tue, 26 Oct 1993 02:47:27 +0000 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Tue, 26 Oct 1993 02:45:44 +0000 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; Tue, 26 Oct 1993 02:45:39 +0000 Date: Tue, 26 Oct 1993 02:45:39 +0000 X400-Originator: basile@soleil.serma.cea.fr X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=cea/ADMD=atlas/C=FR/;751621965@oeillet.saclay.cea.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Font nami... From: Basile STARYNKEVITCH Message-Id: <9310260745.AA03166@soleil.serma.cea.fr> To: nick@nsis.cl.nec.co.jp, vsta@cisco.com Subject: Re: Font naming conventions X-Sun-Charset: US-ASCII Status: OR ># From nick@nsis.cl.nec.co.jp Tue Oct 26 06:46:34 1993 ># Does anyone have any comments on the font naming conventions to be ># used in bitblt/MADO? For the moment, I'm just giving arbitrary name, ># for example: ># ># courier_bold_oblique_12pt ># ># The current design allows me to change naming schemes easily, so if ># someone has information on the "right" way of doing it, please ># comment. X11 font naming seems to work well, but I think it's overly ># complex... ># I don't know enough of MADO. Is there a README about it? I only followed the discussion, and gave some comments (mostly based on my previous NeWS and X11 experience). Does it have scalable fonts or only fixed height fonts? Hoping that it will have some day scalable fonts, i'll suggest that a font name should be more than a simple character string. For instance, it could be a tuple (or a sequence) of strings. Then, a naming scheme like X11 one would be easier, and would not rely upon naming conventions (like the use of - sign to separate naming components). Name matching would be also extended. I also think that dynamically adding font aliases is an important thing. This would incorporate some X11 resources usage into the font naming scheme. I mean that: at initialization time (when the window server starts up, or when the user starts using it) an alias would be added: normal_user_font -> courier_bold_oblique_12pt. And most applications would only use the normal_user_font name, not the full courier_bold_oblique_12pt. Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 Linuxing at home only, and not yet VSTa-ling. 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 nick@nsis.cl.nec.co.jp Tue Oct 26 16:41:01 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01726; Tue, 26 Oct 93 16:41:00 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26012; Tue, 26 Oct 93 16:41:16 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08535(netkeeper.sj.nec.com ); Tue, 26 Oct 93 16:41:15 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23685(archimedes.inoc.sj.nec.com ); Tue, 26 Oct 93 16:41:14 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA16513 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 16:28:40 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00277); Tue, 26 Oct 93 16:15:33 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA16477 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 16:26:36 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA25657; Wed, 27 Oct 1993 08:26:22 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA15518; Wed, 27 Oct 1993 08:26:20 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA11395; Wed, 27 Oct 1993 08:26:19 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA05899; Wed, 27 Oct 93 08:26:19 JST Date: Wed, 27 Oct 93 08:26:19 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310262326.AA05899@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Basile STARYNKEVITCH's message of 26 Oct 93 08:45:39+0100 <9310260745.AA03166@soleil.serma.cea.fr> Subject: Font naming conventions Status: OR >I don't know enough of MADO. Is there a README about it? I only Not yet. I'll have to document it all one day.... >Does it have scalable fonts or only fixed height fonts? Currently I'm using a font format similar to X11 BDF/PCF files. The hooks are there for scalable fonts, and eventually, I'd like to add something like TrueType, or Type1 support. That is low on my priority list at the moment though. >I also think that dynamically adding font aliases is an important >thing. This would be easy to add later too. What I was hoping for was input of the typograhically corrent way to name fonts. I've had input from various people before, and they all said different things. Perhaps there is no "right" way... Does anyone know the naming scheme used by Windows/OS/2? From vandys@cisco.com Wed Oct 27 16:42:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10862; Wed, 27 Oct 93 16:42:27 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01800; Wed, 27 Oct 93 16:42:42 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18255(netkeeper.sj.nec.com ); Wed, 27 Oct 93 16:42:40 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26638(archimedes.inoc.sj.nec.com ); Wed, 27 Oct 93 16:42:38 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA19101 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 16:29:27 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00416); Wed, 27 Oct 93 16:15:37 -0700 Received: from localhost by glare.cisco.com with SMTP id AA07580 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 16:26:52 -0700 Message-Id: <199310272326.AA07580@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Der mouse. In-Reply-To: Your message of "Thu, 28 Oct 1993 08:11:08 +0200." <9310272311.AA22386@silk1.nsis.cl.nec.co.jp> Date: Wed, 27 Oct 1993 16:26:52 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Actually, I noticed that with the interrupt driven system, it can >really bog down the system if you do a lot of work in the interrupt >handler. Do tasks handling interrupts get extra priority? No, they are setrun in exactly the same way as receiving a message. I suspect that you were just using a fair fraction of the 386sx's horsepower just switching into the interrupt task, doing some work, and returning, only to be called again after very little more time. If you *really* want to know how bad it gets, you get m_arg (I think it's m_arg, maybe m_arg1) set to the number of interrupts which have been registered before you received your M_ISR message. There *is* a fairness problem with CPU-heavy processes. I've seen my system bug down badly when I have a runaway server, for instance. I've just never hunted it down and exterminated it. There used to be a bug where it would *never* preempt; I fixed that, but obviously there's more to be done. You realize that typing ^Z enters the kernel debugger, right? Well, you ported your own keyboard driver, so obviously you do. Anyway, without preemption I could never drop into the kernel debugger to see who was running endlessly. :-( >I'll have a look into the MGR and Linux sources for ideas on how to >handle the IBM mouse. Like you said, the code looks simple enough. Yes, what I saw in MGR was just a handful of lines to interpret the whole mouse state. Andy From vandys@cisco.com Wed Oct 27 08:50:28 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08228; Wed, 27 Oct 93 08:49:44 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02567; Wed, 27 Oct 93 08:49:57 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18676(netkeeper.sj.nec.com ); Wed, 27 Oct 93 08:49:56 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA25084(archimedes.inoc.sj.nec.com ); Wed, 27 Oct 93 08:49:53 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA02640 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 08:35:06 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00103); Wed, 27 Oct 93 08:20:31 -0700 Received: from localhost by glare.cisco.com with SMTP id AA05201 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 08:31:41 -0700 Message-Id: <199310271531.AA05201@glare.cisco.com> To: John Burton Cc: vsta@cisco.com Subject: Re: VSTa In-Reply-To: Your message of "Wed, 27 Oct 1993 08:20:00 GMT." Date: Wed, 27 Oct 1993 08:31:41 -0700 From: Andrew Valencia Status: OR [John Burton writes:] > I've been given your name as the person to contact about a new operating >system called VSTa. I believe it is free along the lines of linux? I know it is >not really in a usable state yet, but would be interested in knowing what >you are working on? Welcome to the world of VSTa. I've added you to the mailing list; it's vsta@cisco.com. Changes and miscellany go to vsta-request@cisco.com. VSTa is freely available, but along the lines of GNU, not Linux. All the source is under the GNU Public License. At some point in the future I'll probably move the library portions to the version of the GPL which GNU uses for *their* libraries. VSTa is quite different than your typical free UNIX. First, it does not even try to be exactly a UNIX; areas which have proven to be problematic for extensibility or efficiency have been changed. For instance, signals are strings, as are error "numbers". Thus, VSTa is much more of a platform for experimentation with "beyond UNIX" ideas than simply another implementation of UNIX. The other major difference form "classic UNIX" is that VSTa is a microkernel. The microkernel provides messaging, processes, and virtual memory. All filesystems and device drivers run as user-level tasks. The kernel is 40K, and has remained at this size for quite a while, while the system as a whole has gained significant functionality. Where we stand today? We have servers for: pipes, environment variables (environment variables are hierarchical and can be shared among processes), a virtual memory based /tmp filesystem, /dev/null (a very small server), a DOS filesystem, IDE disks, floppy drive, MGA/CGA console, AT keyboard, swap management, name to port mapping, and a simple boot filesystem (no longer used, really). We have most of a C library, and many commands. I've written many commands from scratch, simply because I can't bear to bring over the gargantuan versions which are freely available. I am writing a contiguous-allocation filesystem, which is up and running--I'm now doing the fsck program for it. Gavin Thomas Nicol is writing a window system, called MADO. David Johnson is working on an ethernet driver, and Michael Larson is working on SCSI support. Version 1.1, now in the home stretch, adds my filesystem, puts in a bunch of bug fixes, and tidies up the source tree. It also fixes a number of makefile problems, and has been built from the freely-available pdmake program. If you really want to start playing with the system NOW, I can get you a copy of the current source. Otherwise hold on for a week or so and you can run with 1.1, which should be easier to bring up. Regards, Andy Valencia vandys@cisco.com From nick@nsis.cl.nec.co.jp Thu Oct 28 19:27:34 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23989; Thu, 28 Oct 93 19:27:33 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00939; Thu, 28 Oct 93 19:27:53 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01472(netkeeper.sj.nec.com ); Thu, 28 Oct 93 19:27:51 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00227(archimedes.inoc.sj.nec.com ); Thu, 28 Oct 93 19:27:49 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA24309 (5.67a/IDA-1.5 for ); Thu, 28 Oct 1993 19:21:03 -0700 Received: from hubbub.cisco.com by amri.cisco.com (AA00388); Thu, 28 Oct 93 19:08:50 -0700 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA24293 (5.67a/IDA-1.5 for ); Thu, 28 Oct 1993 19:20:13 -0700 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA25343; Fri, 29 Oct 1993 11:20:07 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA07948; Fri, 29 Oct 1993 11:20:06 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931019.1) id AA04573; Fri, 29 Oct 1993 11:20:04 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA11835; Fri, 29 Oct 93 11:20:03 JST Date: Fri, 29 Oct 93 11:20:03 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9310290220.AA11835@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: RPC & XDR Status: OR Yesterday I was thinking about a netwrok transparent protocol for bitblt, and portable data formats for font files, so I set off and wrote some routines for writing/retrieving data from a buffer in a portable format, and today, I started to write a compiler so that given a description of a structure, it would generate a function (or functions), for reading and writing such structures. Just, I remembered sun RPC. It includes XDR and rpcgen. I wonder if I should continue with what I'm doing, or whether I should just pull XDR and rpcgen out of sun RPC. Note that in general, I feel that program written using rpcgen are pretty ugly. From vandys@cisco.com Fri Oct 29 07:55:08 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00261; Fri, 29 Oct 93 07:55:07 PDT Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03049; Fri, 29 Oct 93 07:55:25 PDT Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09366(netkeeper.sj.nec.com ); Fri, 29 Oct 93 07:55:24 -0700 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01003(archimedes.inoc.sj.nec.com ); Fri, 29 Oct 93 07:55:22 -0700 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA04243 (5.67a/IDA-1.5 for ); Fri, 29 Oct 1993 07:47:25 -0700 Received: from glare.cisco.com by amri.cisco.com (AA00710); Fri, 29 Oct 93 07:34:21 -0700 Received: from localhost by glare.cisco.com with SMTP id AA04559 (5.67a/IDA-1.5 for ); Fri, 29 Oct 1993 07:45:52 -0700 Message-Id: <199310291445.AA04559@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: RPC & XDR In-Reply-To: Your message of "Fri, 29 Oct 1993 11:20:03 +0200." <9310290220.AA11835@silk1.nsis.cl.nec.co.jp> Date: Fri, 29 Oct 1993 07:45:51 -0700 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Just, I remembered sun RPC. It includes XDR and rpcgen. I wonder if I >should continue with what I'm doing, or whether I should just pull XDR >and rpcgen out of sun RPC. I would suggest that you stay with a straight binary format, and leave a hook so you can switch to a more portable, but less efficient means when necessary. If you really want to be elaborate, have the initial handshake be a one-byte message which indicates your endianness. If you agree, then you run with binary format, otherwise you drop back to a portable representation. >Note that in general, I feel that program written using rpcgen are >pretty ugly. I agree. Also, it would be a pity to spend a lot of time on this now when, realistically, it'll be all 386-type processors for a while to come. Andy From vandys@cisco.com Sun Oct 31 17:17:10 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15297; Sun, 31 Oct 93 17:17:08 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11951; Sun, 31 Oct 93 17:17:30 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16471(netkeeper.sj.nec.com ); Sun, 31 Oct 93 17:17:29 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05353(archimedes.inoc.sj.nec.com ); Sun, 31 Oct 93 17:17:26 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA14081 (5.67a/IDA-1.5 for ); Sun, 31 Oct 1993 17:10:51 -0800 Received: from glare.cisco.com by amri.cisco.com (AA00109); Sun, 31 Oct 93 16:57:11 -0800 Received: from localhost by glare.cisco.com with SMTP id AA13164 (5.67a/IDA-1.5 for ); Sun, 31 Oct 1993 17:09:11 -0800 Message-Id: <199311010109.AA13164@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Namer, mountab etc. In-Reply-To: Your message of "Mon, 01 Nov 1993 08:05:41 +0200." <9310312305.AA03833@silk1.nsis.cl.nec.co.jp> Date: Sun, 31 Oct 1993 17:09:10 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] > Do you think you could send out a description of the design of >mountab, namer etc., and the way the interact with open() etc? Thanks >very much in advance. Sure, thanks for prompting me to do this. The VSTa microkernel does not have any filesystem code. Not only does this mean that the kernel does not know about inodes, directory entries, and so forth. It also means that he does not understand what an "open file" is, nor "file position", nor "path name lookup". Filesystems are an illusion created by cooperation between servers and the C library. By agreeing to certain message types and arguments, they can talk about common file operations. The file include/sys/fs.h defines these messages; servers implement them from the main message handling loop, and clients generally request them through the C library. If you go into vsta/libc/open.c, you will see what is, in UNIX-ese, the "namei" loop--the loop which maps string pathnames into open files. It does this by finding the longest initial match between the filename you want to open, and a path in its mount table. For example: fd = open("/usr/local/lib/table.txt", O_READ); Mount table: Path Connection / (DOS server) /dev/wd (WD server) /env (Environment variable server) /usr/local (VstaFS server) /namer (Name server) The match would be against /usr/local, since this matches to more positions than any other entry. The matched part is stripped, and the path lookup now walks through each remaining part. So the filesystem server which happens to be mounted under /usr/local for the current process will see successive lookups for "lib", and then "table.txt". All well and good, but the question occurs: how do you get your mount table set up in the first place? Since you start with your mount table empty, you can't very well open a file! If you happen to know some desirable server is at port address 1234, you could: port = msg_connect(1234, ACC_READ); mountport("/path", port); A small set of port addresses--just enough to boot--are at "well known addresses". This includes the keyboard, screen, and namer server. It does NOT include disk drivers or root filesystems. In fact, there are more well-known addresses assigned than are needed. I should probably fix this. Anyway, the reason that all these vitally needed resources are not given fixed addresses is that such a mechanism is too inflexible. Instead, the "namer" server is started, and all future queries and updates concerning who is using what port number are handled through this single server. Like most servers, namer presents a filesystem-like view of the symbols it maps. The content of each file is an ASCII number, which is the port number registered for that string. Given the mount table above, where the namer server is under /namer (and assuming we have sufficient privileges--sys.sys is needed), we could "register" a number ourselves, simply by: cd /namer mkdir andy-devs cd andy-devs cat > dev1 12345 ^D In fact, this is how all servers register themselves, although a couple library routines encapsulate all this tedium. A server would do something like: port_name n; port_t p; struct msg m; /* Get port, let system choose ID */ p = msg_port(0, &n); /* Offer to the system as fs/root, the boot/default filesystem */ namer_register("fs/root", n); ... /* Start serving requests as this filesystem */ while (msg_receive(p, &m) > 0) { ... } And a client could do: port_name n; port_t p; char buf[128]; /* Look up fs/root, get its port address */ n = namer_find("fs/root"); /* Connect to server, with access for reading */ p = msg_connect(n, ACC_READ); /* Open foobar on this filesystem connection */ m.m_nseg = 1; m.m_buf = "foobar"; m.m_buflen = strlen(m.m_buf)+1; /* Include terminating '\0' in cnt */ m.m_arg = ACC_READ; m.m_arg1 = 0; m.m_op = FS_OPEN; x = msg_send(p, &m); if (x > 0) { ... } Although, frankly, it's much easier to put it in the mount table and start using it through a more typical POSIX interfaces: mountport("/d", p); fd = open("/d/foobar", O_READ); while (read(fd, buf, sizeof(buf)) > 0) { ... } There was a subtle difference between the last two examples. The former, where we sent FS_OPEN messages ourselves, would walk the actual connection down to the file which was to be opened. Thus, the initial connection would be to the root filesystem, and after a successful FS_OPEN, the connection would instead correspond to the file "foobar". In the latter, the mount table holds the open connection to the server's root, and open() requests do a clone() to get a distinct copy of this connection, and then walk *it* down to the requested file. This leaves the original connection at the root so further uses of the mount point will work. Setting up mount tables for yourself is tedious work. That's why bin/login will read /vsta/etc/fstab during your login, and put initial entries into your mount table. Hopefully, you can read this file, cd over to /namer, look around, and start to get a feel for the links and interactions which map names to ports, and organize a "filesystem" view on top of a collection of open connections to various servers. Andy From nick@nsis.cl.nec.co.jp Wed Nov 3 15:42:01 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12465; Wed, 3 Nov 93 15:42:00 PST Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06744; Wed, 3 Nov 93 15:42:25 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15241(netkeeper.sj.nec.com ); Wed, 3 Nov 93 15:42:24 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17504(archimedes.inoc.sj.nec.com ); Wed, 3 Nov 93 15:42:21 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA08022 (5.67a/IDA-1.5 for ); Wed, 3 Nov 1993 15:34:37 -0800 Received: from hubbub.cisco.com by amri.cisco.com (AA00087); Wed, 3 Nov 93 16:20:01 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA07939 (5.67a/IDA-1.5 for ); Wed, 3 Nov 1993 15:32:26 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA21126; Thu, 4 Nov 1993 08:32:19 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA23502; Thu, 4 Nov 1993 08:32:18 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931101.1) id AA03383; Thu, 4 Nov 1993 08:32:17 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA16482; Thu, 4 Nov 93 08:32:16 JST Date: Thu, 4 Nov 93 08:32:16 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311032332.AA16482@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: A couple of "features" Status: OR First of all, I'd like to thank Andy for posting the explanation of the namer/mountab/open interaction. Using that as a base, I have found the following: 1) In mount.c, function mount_init(), the parsing of the [fstab|mount.rc] is such that you need *exactly* one space between the mount source, and the mount target. ie: servers/mouse /dev/mouse will mount servers/mouse onto " /dev/mouse", which *will not be seen*. 2) When parsing the table, only the first letter is check to see if it's upper case. This would mean that: Foobar /dev/foobar will be mounted as a well-known port, and hence, fail. Also, I wonder if the mountab shouldn't actually be a mount tree? Currently we can have things like: /dev/mouse /dev/kbd /dev/xxxx in mountab. While this isn't bad, filesystems are inherently tree structured, so shouldn't this be reflected in the data structures used to manipulate them? Anyway, now I found the reason why I've been having so much trouble getting my servers "visible", I have managed to get a mouse driver up and running for my machine. I'll have an IBM version out by Monday. nick From vandys@cisco.com Thu Nov 4 19:29:38 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22756; Thu, 4 Nov 93 19:29:36 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11585; Thu, 4 Nov 93 19:29:57 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29026(netkeeper.sj.nec.com ); Thu, 4 Nov 93 19:29:55 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21802(archimedes.inoc.sj.nec.com ); Thu, 4 Nov 93 19:29:47 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA13135 (5.67a/IDA-1.5 for ); Thu, 4 Nov 1993 19:19:48 -0800 Received: from glare.cisco.com by amri.cisco.com (AA00074); Thu, 4 Nov 93 20:02:48 -0800 Received: from localhost by glare.cisco.com with SMTP id AA08543 (5.67a/IDA-1.5 for ); Thu, 4 Nov 1993 16:34:54 -0800 Message-Id: <199311050034.AA08543@glare.cisco.com> To: "Paul Southworth" Cc: vsta@cisco.com Subject: Re: kernel priorities In-Reply-To: Your message of "Thu, 04 Nov 1993 19:12:59 EST." <9311050013.AA02455@fir.cic.net> Date: Thu, 04 Nov 1993 16:34:54 -0800 From: Andrew Valencia Status: OR ["Paul Southworth" writes:] >I might join this list but first I would like a wee bit more information >about what this project is, what stage it is in with regard to a >complete OS being developed, which platforms it is targeted at, and >what the project goal/philosophy is. Hmmm, well. It's written with a fairly strong machine dependent/independent interface. The independent stuff is written using spinlocks and sleeping semaphores for a shared memory multiprocessor. The dependent part is for an i386 ISA PC, although it's also been ported to a Japanese i386 box as well. I watch the falling prices of multiprocessor PC's with great anticipation. It's to the stage where you can boot it, log in, get a shell, list files, compile a server, start it & mount it into your filesystem view, and use it as a filesystem. That is, it's a reasonable self-hosting environment. There are lots of common utilities which haven't been ported yet. But many I just re-write, because... We're not really interested in just doing UNIX all over again. In fact, we're probably more closely related to Plan9. Our "make" is a 20K program, as opposed to the 355K GNU make. Is GNU broken? No. But it's gratifying to experiment with simplicity. We follow POSIX.1 except when we have a specific reason to do otherwise. For instance, errors are strings, not integers. Same for "signals", which we call events. Still, for the most part it's a very familiar POSIX environment and it's relatively easy to write or import code. We even have a POSIX termios TTY interface, although much of the RS-232-oriented tedium is unsupported. There are various projects under way--an enhanced filesystem, a windowing system, SCSI support, networking. Let me know if there are further details which might be of interest. Regards, Andy Valencia From nick@nsis.cl.nec.co.jp Thu Nov 4 19:38:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22761; Thu, 4 Nov 93 19:38:15 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11608; Thu, 4 Nov 93 19:38:42 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29123(netkeeper.sj.nec.com ); Thu, 4 Nov 93 19:38:41 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21819(archimedes.inoc.sj.nec.com ); Thu, 4 Nov 93 19:38:38 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA13293 (5.67a/IDA-1.5 for ); Thu, 4 Nov 1993 19:28:07 -0800 Received: from hubbub.cisco.com by amri.cisco.com (AA00106); Thu, 4 Nov 93 20:11:14 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA15070 (5.67a/IDA-1.5 for ); Wed, 3 Nov 1993 22:16:19 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA22698; Thu, 4 Nov 1993 15:16:12 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA14173; Thu, 4 Nov 1993 15:16:11 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931101.1) id AA24756; Thu, 4 Nov 1993 15:16:09 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA23600; Thu, 4 Nov 93 15:16:08 JST Date: Thu, 4 Nov 93 15:16:08 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311040616.AA23600@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Serial mouse Status: OR Does anyone have any information on IBM/compatible serial mouse? In particular, data format etc. How is it handled under linux? Is it just connected via the normal serial interface? nick From pat%wesson@joyce.cs.su.OZ.AU Fri Nov 5 08:00:58 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29071; Fri, 5 Nov 93 08:00:57 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13740; Fri, 5 Nov 93 08:01:22 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07293(netkeeper.sj.nec.com ); Fri, 5 Nov 93 08:01:21 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA22884(archimedes.inoc.sj.nec.com ); Fri, 5 Nov 93 08:01:19 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA22702 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 07:49:10 -0800 Received: from hubbub.cisco.com by amri.cisco.com (AA00132); Fri, 5 Nov 93 08:30:36 -0800 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA19596 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 03:43:14 -0800 Received: from wesson by joyce.cs.su.OZ.AU (mail from pat for vsta@cisco.com) with MHSnet; Fri, 05 Nov 1993 22:43:13 +1100 Received: from wesson by garion.it.com.au with smtp (Smail3.1.28.1 #3) id m0ovPbq-0000Ya5; Fri, 5 Nov 93 19:45 WST Message-Id: From: pat%wesson@joyce.cs.su.OZ.AU (Pat Mackinlay) Subject: Re: Serial mouse To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Date: Fri, 5 Nov 1993 19:37:49 +0000 () Cc: vsta@cisco.com In-Reply-To: <9311040616.AA23600@silk1.nsis.cl.nec.co.jp> from "Gavin Thomas Nicol" at Nov 4, 93 03:16:08 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 903 Status: OR [...I've just brought up a mail feed to my home, so this is it's first "real" test. The date field (and possibly some others) may be a little damaged, but the important parts should be right...] > Does anyone have any information on IBM/compatible serial mouse? In > particular, data format etc. How is it handled under linux? Is it just > connected via the normal serial interface? The Linux kernel doesn't do anything particularly fancy with mice, the actual interpretation of the data stream is left up to the application (eg: X or selection). The best documentation I can come up with on the mouse protocol is actually the source to the abovementioned program "selection". This program basically allows cutting and pasting of characters on the Linux console (very handy), and is reasonably simple to follow. Seeing as it's so small, I'll mail you (Nick) the source in another message. -- Pat. From hp@quasi.vmars.tuwien.ac.at Fri Nov 5 08:17:41 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29098; Fri, 5 Nov 93 08:17:39 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13780; Fri, 5 Nov 93 08:18:03 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07456(netkeeper.sj.nec.com ); Fri, 5 Nov 93 08:18:02 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA22932(archimedes.inoc.sj.nec.com ); Fri, 5 Nov 93 08:17:59 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA23121 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 08:05:57 -0800 Received: from hubbub.cisco.com by amri.cisco.com (AA00140); Fri, 5 Nov 93 08:50:05 -0800 Received: from quasi.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA23039 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 08:02:50 -0800 Received: by quasi.vmars.tuwien.ac.at id AA11817 (5.64+/IDA-1.3.4 for vsta@cisco.com); Fri, 5 Nov 93 17:02:18 +0100 From: Peter Holzer Message-Id: <9311051602.AA11817@quasi.vmars.tuwien.ac.at> Subject: Re: Serial mouse To: vsta@cisco.com Date: Fri, 5 Nov 93 17:02:17 MET In-Reply-To: ; from "Pat Mackinlay" at Nov 5, 93 7:37 pm Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] Status: OR You (Pat Mackinlay) wrote: > > The best documentation I can come up with on the mouse protocol is actually > the source to the abovementioned program "selection". This program basically > allows cutting and pasting of characters on the Linux console (very handy), > and is reasonably simple to follow. Seeing as it's so small, I'll mail you > (Nick) the source in another message. But beware that there are two kinds of serial mice for PCs: two-button mice (Microsoft) and three-button mice (PC-Systems). I think selection only handles the former. If needed I can dig up the sources of Mini-X to find out about both formats. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | ...and it's finished! It only has to be written. __/ | -- Karl Lehenbauer