From jvh@cs.hut.fi Thu Jun 23 18:35:30 1994 (5.65c8/HUTCS-S 1.4 for lites@cs.hut.fi); Fri, 24 Jun 1994 03:31:53 +0300 Date: Fri, 24 Jun 1994 03:31:53 +0300 From: Johannes Helander To: lites@cs.hut.fi Subject: LITES 940624 snapshot available Organization: Helsinki University of Technology, CS Lab. There is a new LITES snapshot available for anon ftp in leia.cs.hut.fi:foggy/lites/LITES.940624.tar.gz Select now works much better, a tsleep bug has been fixed, the real console works, some dependencies have been fixed, and other bugfixes. Also there is supposedly no net2 or other suspectable code left. If you find any, let me know immediately. I still need to do a scan through all the files fixing the copyrights. I'll make a new snapshot when this is done. Any comments are welcome. I put some i386 binaries that you might find useful in the bin subdirectory of the abovemention directory. --------------------- work in practice. Probably related to this there is sometimes a rather long delay in the boot when starting /sbin/init from mach_init. Just be patient, it'll continue in a while. Or be impatient and fix it :-). The gdb in the binary distribution works with the server and emulator so you can run them as second server. The machid server and ms programs implement the machid protocol used by the lites server. I tried to get rid of netisrs but with that option (+ether_as_syscall) inetd doesn't wake up from select when establishing the first inbound connection. So I suspect there is still something fishy in select even after many many coding iterations. However, that problem does not show up in connection with netisrs. The server currently assumes that the emulator is loaded with a UX linker. An emulator binary format is determined from that a_info is ZMAGIC and a_entry is above 128 MB. This was convenient as then the debugger was still able to read the symbol table. If you wish to get your favorite linker to be able to link emulators, please tell me what binary format it is and how I should distinguish it from normal binaries. I think there was a flags field in a_info. Perhaps some flag could be used for that. The point is that "emulators" are assumed to be "native LITES binaries" and thus do not require any emulation. The emulator is a special case of this. In any case they must be distinguished from other binaries one way or another while still being able to load them properly (eg. ux linker and netbsd linker binaries are loaded differently: the text size is calculated differently). In case you are using FreeBSD you should know that I found out that freebsd-current shared libraries don't interact well with sbrk. It doesn't seem hard to fix but in the current snapshot it doesn't work. Johannes From jvh@cs.hut.fi Thu Jun 23 21:28:50 1994 (5.65c8/HUTCS-S 1.4 for lites@cs.hut.fi); Fri, 24 Jun 1994 06:23:40 +0300 Date: Fri, 24 Jun 1994 06:23:40 +0300 From: Johannes Helander To: lites@cs.hut.fi Subject: shared libs update In-Reply-To: <199406240031.AA17739@hutcs.cs.hut.fi> References: <199406240031.AA17739@hutcs.cs.hut.fi> Organization: Helsinki University of Technology, CS Lab. Well now the FreeBSD shared libs work. So I should have delayed the snapshot for one more hour but then again thinking that way I would never be able to make any snapshots... More next week. Johannes From jkh@ilo.dec.com Fri Jun 24 08:02:37 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Jun 1994 16:56:19 +0300 To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: shared libs update In-Reply-To: Your message of "Fri, 24 Jun 1994 06:23:40 +0300." <199406240323.AA18599@hutcs.cs.hut.fi> Date: Fri, 24 Jun 1994 14:47:42 +0100 From: Jordan Hubbard > Well now the FreeBSD shared libs work. So I should have delayed the > snapshot for one more hour but then again thinking that way I would > never be able to make any snapshots... More next week. Great! Just to let you know, I haven't forgotten you, I'm just up to my eyeballs trying to get this %$@#%$! FreeBSD 1.1.5 release out the door. Once that's done, it's focus on 2.0 (and related technologies) and nothing else.. Jordan From jvh@cs.hut.fi Tue Jun 28 15:55:51 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 29 Jun 1994 00:47:02 +0300 (5.65c8/HUTCS-C 1.3 for lites); Wed, 29 Jun 1994 00:47:01 +0300 Date: Wed, 29 Jun 1994 00:47:01 +0300 From: Johannes Helander To: lites@cs.hut.fi Subject: LITES installation. In-Reply-To: <9406281916.AA72340@acs5.acs.ucalgary.ca> References: <9406281916.AA72340@acs5.acs.ucalgary.ca> Organization: Helsinki University of Technology, CS Lab. > Sorry to ask a stupid question, but how do I go about testing LITES? > > I assume I need {Net,Free}BSD, but I don't know if it really is required. NetBSD 0.9 is what I think works best at the moment. However, FreeBSD current also works after I changed vm_allocate to vm_map in the emulator mmap MAP_ANON case (vm_map uses the address hint, vm_allocate discards it thus breaking sbrk). Supposedly you should also be able to use UX or 386bsd or some others but I haven't tried booting on them, just individual binaries such as emacs and tcsh. > Are the following steps correct? > > 1) Install FreeBSD. > 2) d/l and compile Mach on a second partition. You don't need a second partition. Of course you should take backups etc. as always first before experimenting. > 3) install LITES somehow (I haven't looked inside the current snapshot > archive, so I'm not sure of what to do yet). You need to make an /mach_servers directory. It should contain the server [startup], the emulator [emulator], a paging file (or a symlink to it) [paging_file], and an init program [mach_init]. The init program may be a symlink to /sbin/init or it could be mach_init. The paging_file symlink is a bit unusual. If you have a file PAGING_FILE (it should have no holes, use dd) on partition sd0e then you say ln -s /dev/sd0e/PAGING_FILE paging_file Then you need to put the Mach kernel (MK83) in the root [mach] (or [mach.boot] depending on your boot blocks). The boot blocks are incompatible with XBSD. If you want to be able to still boot BSD you could put the Mach boot blocks on a floppy (dd it to the beginning of the floppy). Then pick up some more binaries form leia:foggy/lites/bin these go into /sbin ------------------- fsck machid mount_kernfs mount_nfs route and these to /bin ----------------- ms ps top w uptime should be a symlink to w. You should save your original fsck also as the version above is not guaranteed to always work. It was compiled from 4.4Lite with NetBSD libraries with empty stubs replacing the missing symbols (locale etc). The bnr derived fsck programs have trouble with the new superblock format and work only manually. Currently the only X server known to work is XFree 1.3 Mach version. I haven't tried the newer ones as I don't have a binary and didn't succeed in supping one. Finally make some devices in /dev. Check that /dev/console is 0,0. mknod iopl c 22 0 mknod kbd c 23 0 mknod mouse c 24 8 mknod time c 25 0 mknod timezone c 26 0 It should now look like this crw------- 1 root tty 0, 0 Jun 28 22:00 console crw-r--r-- 1 root root 22, 0 Jan 16 00:15 iopl crw-r--r-- 1 root root 23, 0 Jan 16 00:15 kbd crw-r--r-- 1 root root 24, 8 Jan 16 00:15 mouse crw-r--r-- 1 root root 25, 0 Jun 5 1993 time crw-r--r-- 1 root root 26, 0 Jun 19 20:28 timezone The mouse's minor number depends on the mouse type. 8 is microsoft. Refer to XFree's README.Mach for mouse instructions. Refer to lites/server/i386/server/conf.c for other device numbers. BTW: If you think the device numbers I picket were bad choices let me know preferably soon. > 4) Make the Mach partition bootable, reboot, and run wild. If you did put the bootblock on a floppy then you need to type to the boot prompt (from memory) boot: sd(0)mach If you put it on the hard disk it should now work. > If this is the simplest way of installing the bsdss, I think I can manage. > If not, then please refer me to docs/man pages describing what I need > to do. Thanks. There is a README in the doc directory of LITES. Those instructions are even breefer than this. You could also refer to the Mach 3 installation instructions in mach.cs.cmu.edu:... but disregard the RFS/.LOCALROOT stuff there. > I'd especially appreciate it if there was a simpler way to install. True. If you have the time and have success perhaps you could write a few lines about your experiences so they can be added to the README file. In the future some scripts and ready made installation kits will be needed. In general the hardest part in installing Mach (or any other os for that matter) on a peecee is to get all those cards configured and working together. A good approach after the initial failure is to first remove all possible cards and get the system booting with them. Then add cards back and get them working. Refer to mk/kernel/i386at/autoconf.c for supported card configurations. good luck, Johannes PS. some path names above reflected the situation in the next snapshot. From jvh@cs.hut.fi Tue Jun 28 19:16:51 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 29 Jun 1994 04:08:34 +0300 (5.65c8/HUTCS-C 1.3 for lites); Wed, 29 Jun 1994 04:08:15 +0300 Date: Wed, 29 Jun 1994 04:08:15 +0300 From: Johannes Helander To: davidg@root.com Cc: lites@cs.hut.fi Subject: Re: LITES installation. In-Reply-To: <199406290045.RAA00365@corbin.Root.COM> References: <199406282147.AA19121@laphroaig.cs.hut.fi> <199406290045.RAA00365@corbin.Root.COM> Organization: Helsinki University of Technology, CS Lab. > >NetBSD 0.9 is what I think works best at the moment. However, FreeBSD > >current also works after I changed vm_allocate to vm_map in the > >emulator mmap MAP_ANON case (vm_map uses the address hint, vm_allocate > >discards it thus breaking sbrk). Supposedly you should also be able to > > > Hmmm....tell me more about this. Is this something that we've > broken in the FreeBSD kernel? No, I don't think you've broken anything. It is just the shared library implementation that has changed since I last tried FreeBSD binaries. For shared libraries mmap is called with the anywhere option (ie. !MAP_FIXED). It is however necessary to leave room for sbrk. So what I did was to give an address hint of 0x4000000 to vm_map to get the mapping out of the way. NetBSD never called mmap with MAP_ANON && !MAP_FIXED but FreeBSD current did. Since I was using vm_allocate and it happens to behave differently in this respect from vm_map with a null object it didn't work. Now I'm using vm_map also in this case so the problem is gone. I admit that it is a bit questionable to rely on the address hint keeping the heap growth area clear as it is not a documented part of the Mach kernel interface (if you don't count a one line comment inside an internal kernel function :-). The clean solutions would be to either get rid of sbrk (good idea!) or add some way of restricting the address space allocation in Mach (I think OSF did the latter), or both. Johannes From jvh@cs.hut.fi Fri Jul 1 04:55:47 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 1 Jul 1994 13:36:34 +0300 (5.65c8/HUTCS-C 1.3 for lites); Fri, 1 Jul 1994 13:36:34 +0300 Date: Fri, 1 Jul 1994 13:36:34 +0300 From: Johannes Helander To: lites@cs.hut.fi Subject: LITES.940701.tar.gz available Organization: Helsinki University of Technology, CS Lab. There is a new snapshot in the usual place. - It is now possible to boot with FreeBSD binaries (you still need to change some programs as mentioned earlier). - XFree 2.1.1 Mach version works. - Cleanup has been made and many copyrights added. doc/FILES is an attempt to summarize where each file comes from and what its status is. Any corrections or comments are welcome. - The isolation between server specific and generic BSD files is somewhat clearer. There are some i386 binaries in leia:foggy/lites/bin I'll be away for the weekend. Johannes From baford@schirf Fri Jul 15 16:20:53 1994 (5.65c8/HUTCS-S 1.4 for ); Sat, 16 Jul 1994 01:13:09 +0300 To: hurd-dev@gnu.ai.mit.edu, linuxss@info.polymtl.ca, lites@cs.hut.fi Subject: Mach with new build environment and LILO support available Cc: marcus@ee.pdx.edu, steve@icarus.icarus.com, mw@eunet.ch Date: Fri, 15 Jul 94 16:10:11 MDT From: Bryan Ford You can get my first (working) release of Mach, with a totally new, "GNUified" build environment and direct LILO (Linux Loader) support, by anonymous FTP from kahlua.cs.utah.edu:/pub. Get the packages called `mach4-UK01.tar.gz' and `mach4-i386-UK01.tar.gz'. The first contains a README that should explain everything needed to get going. This release successfully boots from LILO (at least on my machine) and uses Remy Card's modified server bootstrap program to load and run his test server from a Linux ext2fs partition. I haven't yet tried running any "real" servers on it yet, though I want to get both LITES and the Hurd running smoothly on it. I'll probably work on the Hurd first, because thanks to Louis-D. Dubeau it has ext2 file system support. This release has a number of Linux dependencies, and will probably not build/run from a BSDish system without some fixes. For one thing, the old non-LILO boot mechanism is temporarily broken. Also, some of the auxiliary programs used to build boot images probably need some Linux include files and such, because they were ripped straight out of Linux. If you make the fixes for BSD, please me the patches - I probably won't be able to fix it myself real soon because the NetBSD boot loader seems to be incompatible with my PC. (One thing I _can_ do, and plan to before the next release, is to integrate Johannes Helander's Mach patches for LITES.) At this point the system probably contains lots of little bugs and gotachas, and I'm sure I've broken a few things here and there. It'll probably be getting a lot more unstable in the near future, as well, as I integrate migrating threads into the i386 version of the kernel. Therefore, at this point I'm not interested in getting bug reports, although bug _fixes_ in the form of patches are always welcome. :-) I'm also interested in hearing discussion on how to further change Mach to better support the free servers, make it more powerful and robust, easier to install and use, etc. Thanks, and have fun! Bryan --- Bryan Ford baford@cs.utah.edu University of Utah, CSS `finger baford@schirf.cs.utah.edu' for PGP key and other info. From jvh@cs.hut.fi Fri Jul 22 22:48:25 1994 (5.65c8/HUTCS-S 1.4 for lites); Sat, 23 Jul 1994 07:39:47 +0300 Date: Sat, 23 Jul 1994 07:39:47 +0300 From: Johannes Helander To: lites@cs.hut.fi Subject: I'm on vacation Organization: Helsinki University of Technology, CS Lab. I'm on vacation the next three or four weeks. I'll read my mails monday morning before I totally disappear and then around the 12th while dropping by in Stockholm. Meanwhile the LITES source is still available for ftp in leia.cs.hut.fi in the directory foggy/lites. There are also some useful i386 binaries in bin/. The last snapshot is from July 1. Johannes From root@pc17.enci.ucalgary.ca Tue Jul 26 15:08:00 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 26 Jul 1994 23:40:02 +0300 Date: Tue, 26 Jul 1994 13:49:13 -0700 From: Charlie Root To: lites@cs.hut.fi Subject: Help! Hello, all lites testers out there! Has anybody succeeded in getting lites running on a non-SCSI (i.e. booting from hd0a, not sd0a) device? If you have, please mail me, because I keep getting stuck with kernel panics. --Gord gord@enci.ucalgary.ca From gord@enci.ucalgary.ca Tue Jul 26 16:41:56 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 27 Jul 1994 01:31:50 +0300 Date: Tue, 26 Jul 94 15:56:42 MDT From: gord@enci.ucalgary.ca (Gordon Matzigkeit) To: lites@cs.hut.fi Subject: Re: Help! Sorry for that silliness. My real name is Gordon Matzigkeit *NOT* Charlie Root. I mailed from my FreeBSD machine, which I don't use for anything except for lites. Please reply to me at this address, Thanks. --Gordon Matzigkeit gord@enci.ucalgary.ca From Christopher.Maeda@ERNST.MACH.CS.CMU.EDU Wed Aug 17 00:21:43 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 17 Aug 1994 09:13:37 +0300 From: Christopher Maeda Date: Wed, 17 Aug 94 01:58:38 EDT To: lites@cs.hut.fi Cc: cmaeda@ERNST.MACH.CS.CMU.EDU Subject: LITES under NetBSD 0.9 Reply-To: cmaeda@cs.cmu.edu I have a kernel and LITES server that build under NetBSD 0.9 using the native tools (no buildtools required). Currently, the kernel will build and boot off a NetBSD 0.9 partition. The server will build but will not boot. I'm making it available since I don't think I'll have very much time to debug this in the next few weeks. Anyone want to help? You can get them using anonymous ftp from mach.cs.cmu.edu in src/netbsd. mk83.netbsd.940816.tar.gz is the kernel. It has all known patches from RVB and JVH. It also comes with new bootblocks for NetBSD 0.9. lites.netbsd.940816.tar.gz is the server. Let me know if you pick it up so we can coordinate changes. Cheers, Chris From baford@schirf Tue Sep 6 16:33:03 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 7 Sep 1994 01:26:30 +0300 Date: Tue, 06 Sep 94 16:26:20 MDT From: Bryan Ford Subject: Another bugfix Apparently-To: ------- Blind-Carbon-Copy To: mach4-users Subject: Another bugfix Date: Tue, 06 Sep 94 16:26:20 MDT From: Bryan Ford Here's another bug fix to the mach4 distribution, this time (for once) to the actual content rather than the build environment. :-) I wasn't encountering this bug before because it only involves Unix system call emulation code and I had never before run "real" Unix servers up to that point. Anyway, with this bug fix I can announce that the 4.4 Lite server binary and assorted utilities from HUT (in leia.cs.hut.fi:/foggy/lites/bin) run successfully on mach4 (at least for me :-) ). I've also successfully run a Lites server I compiled under NetBSD, although that was much more difficult because of the CMU build environment. BTW, for anyone wanting to try Lites, note that NetBSD-current binaries _don't_ work with it; I was successful with NetBSD-0.9 binaries, and at least some Linux and FreeBSD binaries are supposed to work. If you missed Johannes Helander's explanation of how to set it up, I still have a copy and can forward it to you. Also, if you're _really_ in a hurry, I've put a copy of the Mach boot image I'm using in kahlua.cs.utah.edu:/pub/machboot. It's compatible with both LILO and the NetBSD boot loader. Have fun! Bryan =================================================================== RCS file: /n/schirf/u/baford/CVS/mach4-i386/kernel/i386/locore.S,v retrieving revision 1.4.2.4 diff -u -r1.4.2.4 locore.S - --- 1.4.2.4 1994/09/06 04:11:22 +++ locore.S 1994/09/06 19:56:18 @@ -1082,18 +1082,18 @@ * eax still contains syscall number. */ syscall_emul: + movl $USER_DS,%edi /* use user data segment for accesses */ + mov %di,%es + +/* XXX what about write-protected pages? */ movl R_UESP(%ebx),%edi /* get user stack pointer */ - - cmpl $(VM_MAX_ADDRESS),%edi /* in user space? */ - - ja syscall_addr /* address error if not */ subl $8,%edi /* push space for new arguments */ - - cmpl $(VM_MIN_ADDRESS),%edi /* still in user space? */ - - jb syscall_addr /* error if not */ movl R_EFLAGS(%ebx),%eax /* move flags */ RECOVER(syscall_addr) - - movl %eax,0(%edi) /* to user stack */ + movl %eax,%es:0(%edi) /* to user stack */ movl R_EIP(%ebx),%eax /* move eip */ RECOVER(syscall_addr) - - movl %eax,4(%edi) /* to user stack */ + movl %eax,%es:4(%edi) /* to user stack */ movl %edi,R_UESP(%ebx) /* set new user stack pointer */ movl %edx,R_EIP(%ebx) /* change return address to trap */ movl %ebx,%esp /* back to PCB stack */ @@ -1103,6 +1103,9 @@ * Address error - address is in %edi. */ syscall_addr: + mov %ss,%ax /* restore ES to kernel segment */ + mov %ax,%es + movl %edi,R_CR2(%ebx) /* set fault address */ movl $(T_PAGE_FAULT),R_TRAPNO(%ebx) /* set page-fault trap */ Bryan - --- Bryan Ford baford@cs.utah.edu University of Utah, CSS `finger baford@schirf.cs.utah.edu' for PGP key and other info. ------- End of Blind-Carbon-Copy From DALL@HFRD.DSTO.GOV.AU Sun Sep 11 18:50:50 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 03:44:19 +0300 10:14:04 +0930 From: Ian Dall Date: Mon, 12 Sep 1994 10:14:21 +0930 To: lites@cs.hut.fi Subject: pc532 lites port X-Hfrd: 1994091210120440 Well, I have made reasonable progress considering how little time I have spent on it. (I got diverted into porting a current gas and binutils to the 532 and then into getting the MK server to load in high virtual memory (above 0x20000000). So far it all compiles, but I have a few undefined globals. There was no i386/proc.h in the snapshot but machine/proc.h is included from proc.h. I made a proc.h which only has a dummy structure definition in it. Nothing complains, so I assume the structure is never used. The main remaining problems are two files which are not in machine dependent sub-directories, but contain machines dependent code. e_defs.h has prototypes with "struct i386_thread_state" in them. I changed to "thread_state_t". e_bnr_sysent.c has references to i386_e_{fork,vfork,sigvec}. I am not quite so sure what to do here. e_bnr_sysent.c could be moved to /e_bnr_sysent.c. Alternatively, some preprocessor magic could be used. In the server, setsoftnet is an undefined global and I have no idea where is should be defined. bcmp and memcmp are also undefined, but I should be able to handle those! The port has been fairly mechanical. Between using the i386 port as an example and borrowing from the ns532 ux port, I haven't had to write anything from scratch, which makes me optimistic that the whole thing will work with relatively little trouble. I notice it has code to detect 4.3 inodes in the file system, so I should be able to construct a file system and populate it using 4.3 tools. Is there some flag I can use to tell the server to mount the root file system read only? That would probably simplify initial testing. Ian From niklas@appli.se Mon Sep 12 01:32:49 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 10:25:48 +0300 id JAA23024; Mon, 12 Sep 1994 09:25:29 +0200 Date: Mon, 12 Sep 94 09:15:42 CDT From: niklas@appli.se (Niklas Hallqvist) To: dall@hfrd.dsto.gov.au Cc: lites@cs.hut.fi In-Reply-To: <9409120044.AA10374@hfrd.dsto.gov.au> (message from Ian Dall on Mon, 12 Sep 1994 10:14:21 +0930) Subject: Re: pc532 lites port >>>>> "Ian" == Ian Dall writes: Ian> Well, I have made reasonable progress considering how little time Ian> I have spent on it. I'd be *very* interested in the problems in the machine-independent parts you'll bump into. I'm just starting my master's thesis project, which consists of finishing the AmigaMach port as well as porting LITES to the m68k. Ian> The main remaining problems are two files which are not in Ian> machine dependent sub-directories, but contain machines dependent Ian> code. Ian> e_defs.h has prototypes with "struct i386_thread_state" in them. Ian> I changed to "thread_state_t". Ian> e_bnr_sysent.c has references to i386_e_{fork,vfork,sigvec}. I am Ian> not quite so sure what to do here. e_bnr_sysent.c could be moved Ian> to /e_bnr_sysent.c. Alternatively, some preprocessor Ian> magic could be used. No, not preprocessor-based solutions please. Machine dependent parts should be in / so it'll be easy for porters to find where they need to do work. #ifdefs scattered around the tree would only be confusing. Ian> The port has been fairly mechanical. Between using the i386 port Ian> as an example and borrowing from the ns532 ux port, I haven't had Ian> to write anything from scratch, which makes me optimistic that Ian> the whole thing will work with relatively little trouble. This is comforting news indeed, thanks for posting your experiences so far. I'd be pleased to hear some more in the future. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From jvh@cs.hut.fi Mon Sep 12 06:07:53 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 14:58:22 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 12 Sep 1994 14:57:33 +0300 Date: Mon, 12 Sep 1994 14:57:33 +0300 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: pc532 lites port In-Reply-To: <9409120044.AA10374@hfrd.dsto.gov.au> References: <9409120044.AA10374@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Sounds good! Keep us infomed about the problems you run into. This is the first port so there will inevitably be files or code in the wrong place. Sorting out these should make further ports much easier. machine/proc.h only defines the machine dependent part of struct proc. It is not needed for anything so I removed the file. Unfortunately I forgot to clean up sys/proc.h. setsoftnet is used in server/net/netisr.h. There is an #ifdef i386 which should rtaher be #if 1 (or similar). All the e_XXX_sysent.c files could be moved to machine dependent directories. System call numbers and calling conventions tend to vary from machine to machine enough to make it useless to try to share them. When picking up code from the UX port please be careful not to pick up any 4.3 BSD derived code. The port itself is ok. If you could add to the doc/FILES list the origin of each new file that'd be great. 4.3 BSD file systems work but seem a bit more unreliable than 4.4 file systems. Merging late FreeBSD andor NetBSD fixes would probably fix lots of bugs. However, a merge is not a trivial undertaking but at some point yes. The root file system is automatically mounted read only on boot. You need to explicitly remount it to get it writable (mount -u /). Johannes From mike@cs Mon Sep 12 12:05:53 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 20:59:11 +0300 Date: Mon, 12 Sep 94 11:59:00 -0600 From: mike@cs (Mike Hibler) To: dall@hfrd.dsto.gov.au, jvh@cs.hut.fi Subject: Re: pc532 lites port Cc: lites@cs.hut.fi > Date: Mon, 12 Sep 1994 14:57:33 +0300 > From: Johannes Helander > To: Ian Dall > Cc: lites@cs.hut.fi > Subject: Re: pc532 lites port > > Sounds good! Keep us infomed about the problems you run into. This is > the first port so there will inevitably be files or code in the wrong > place. Sorting out these should make further ports much easier. > I am working on getting LITES running on the PA-RISC and already know that there will be a number of changes necessary to the MI code (in particular, the exec code). > machine/proc.h only defines the machine dependent part of struct proc. > It is not needed for anything so I removed the file. Unfortunately I > forgot to clean up sys/proc.h. > I wouldn't start removing things just because they are not needed on the x86. > All the e_XXX_sysent.c files could be moved to machine dependent > directories. System call numbers and calling conventions tend to vary > from machine to machine enough to make it useless to try to share > them. > I would agree except perhaps for one (which currently doesn't exist) that corresponds to a "pure" 4.4bsd interface which could be used by hp300s, sparcs, decstations and whatever that run "real" 4.4. However, there will still be problems with register conventions (e.g. i386_e_wait) in such a file so maybe that isn't even worth it... From jvh@cs.hut.fi Mon Sep 12 12:50:27 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 21:45:18 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 12 Sep 1994 21:45:06 +0300 Date: Mon, 12 Sep 1994 21:45:06 +0300 From: Johannes Helander To: mike@cs (Mike Hibler) Cc: lites@cs.hut.fi Subject: Re: pc532 lites port In-Reply-To: <9409121759.AA00541@cs.utah.edu> References: <9409121759.AA00541@cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Mike Hibler writes: > I wouldn't start removing things just because they are not needed on > the x86. Is a machine dependent struct proc extension needed on the PA then? I've always tried to remove things that I can't see any use for. That makes the code easier to understand. I see it as "source garbage collection". > I would agree except perhaps for one (which currently doesn't exist) that > corresponds to a "pure" 4.4bsd interface which could be used by hp300s, > sparcs, decstations and whatever that run "real" 4.4. However, there will > still be problems with register conventions (e.g. i386_e_wait) in such a > file so maybe that isn't even worth it... wait is not needed for pure 4.4 binaries as wait4 replaces it. sigvec is also obsolete. fork and vfork don't need to pass the registers. They just return two values. The old emulator needed the regs so the register calling convention is a leftover from that and ought to be fixed. Thus a common pure 4.4 interface would be possible. Some new handler functions might be needed. Having an interface for pure binaries only requires that pure binaries can be distinguished from BNR binaries (since otherwise machine dependent compat interfaces must be included). I'm not sure they can always be easily distinguished. Johannes From mike@cs Mon Sep 12 13:35:38 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Sep 1994 22:29:15 +0300 Date: Mon, 12 Sep 94 13:29:11 -0600 From: mike@cs (Mike Hibler) To: jvh@cs.hut.fi, mike@cs Subject: Re: pc532 lites port Cc: lites@cs.hut.fi > Date: Mon, 12 Sep 1994 21:45:06 +0300 > Message-Id: <199409121845.AA23518@laphroaig.cs.hut.fi> > From: Johannes Helander > To: mike@cs (Mike Hibler) > Cc: lites@cs.hut.fi > Subject: Re: pc532 lites port > > Is a machine dependent struct proc extension needed on the PA then? > I've always tried to remove things that I can't see any use for. That > makes the code easier to understand. I see it as "source garbage > collection". > I haven't made it that far yet, but I suspect it won't be needed. My point is just that I think it is premature to clean up "unnecessary" machine dependent features when the number of supported architectures is one. > wait is not needed for pure 4.4 binaries as wait4 replaces it. sigvec > is also obsolete. fork and vfork don't need to pass the registers. > They just return two values. The old emulator needed the regs so the > register calling convention is a leftover from that and ought to be > fixed. Thus a common pure 4.4 interface would be possible. Some new > handler functions might be needed. > Actually, what you have for i386_e_{v}fork should actually be promoted to probably e_bsd_stubs.c since the behavior of returning zero in return value 1 for the parent and non-zero for the child is a BSDism not an x86 thing or even a BNR or 4.4 thing. > Having an interface for pure binaries only requires that pure binaries > can be distinguished from BNR binaries (since otherwise machine > dependent compat interfaces must be included). I'm not sure they can > always be easily distinguished. > This would be a problem for our "HPBSD" (4.3/4.4 hybrid running on hp300/400/700/800 machines) binary base. For now it would maybe be best to make all the e_*_sysent files machine dependent and sort it out later. From DALL@HFRD.DSTO.GOV.AU Mon Sep 12 17:58:41 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Sep 1994 02:53:34 +0300 09:23:05 +0930 From: Ian Dall Date: Tue, 13 Sep 1994 09:23:28 +0930 To: lites@cs.hut.fi Subject: Re: pc532 lites port In-Reply-To: <199409121157.AA20850@laphroaig.cs.hut.fi> References: <9409120044.AA10374@hfrd.dsto.gov.au> <199409121157.AA20850@laphroaig.cs.hut.fi> X-Hfrd: 1994091309211186 Johannes Helander writes: > All the e_XXX_sysent.c files could be moved to machine dependent > directories. System call numbers and calling conventions tend to > vary from machine to machine enough to make it useless to try to > share them. What I've done for now is keep the sysent file in the machine independent but change the i386_e_{fork,vfork,sigvec} to machine_e_{fork,vfork,sigvec}. But if the system call numbers vary I guess the sysent files should just move to the machine dependent directory. I did notice that there seems to be nothing machine dependent about i386_e_{fork,vfork}. > When picking up code from the UX port please be careful not to > pick up any 4.3 BSD derived code. The only things I've borrowed have been very machine dependent stuff written by the HUT people. Ian From baford@schirf Wed Sep 14 10:47:55 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 14 Sep 1994 19:37:13 +0300 To: csb@tomx.elte.hu (Csizmazia Balazs) Cc: lites@cs.hut.fi Subject: Re: LITES build infos In-Reply-To: Your message of "Wed, 14 Sep 94 08:00:01 +0200." <9409140600.AA13010@tomx.elte.hu> Date: Wed, 14 Sep 94 10:37:06 MDT From: Bryan Ford >Hi Bryan! > > You mentioned 1 weeks ago, that You can send (forward) Johannes Helander's >LITES build instructions via e-mail. Please send me one exemplar. I don't think he's explained yet how to _build_ Lites, only how to install the finished binaries. To build Lites, basically you just have to have a complete ODE build environment set up, and if you haven't done this before, you're in for some _big_ fun. :-) I don't have time to explain everything you need to do, but maybe I can get you started and you can figure it out from there. I'm cc'ing this message to the lites mailing list in case anyone else is trying to do the same thing. I've successfully built a working Lites server under NetBSD-current (should work under other i386 BSD variants too; haven't tried it under Linux). Get Johannes's LITES source tree snapshot, CMU's vanilla MK83 Mach kernel source tree from mach.cs.cmu.edu (you'll need it just to build Lites even if you'll be running a Utah kernel), and CMU's USER22 source tree from step.polymtl.ca:/pub/proj/linuxss/mach/user22.tar.gz. Install them in a directory called `mach/src' or something like that so that the directory `mach/src' contains subdirectories `mk', `lites', and `user', and `buildtools'. Apply Johannes Helander's patches (in `mach/src/lites/doc' I think) to the mk and user source trees. Then cd into `mach/src/buildtools/ode/setup' and type `sh -x setup.sh i386_mach'. That'll try to build all the ODE build tools, but it probably won't work the first time. Watch for errors, and go into header files and source files and tweak away until things work. You also might want to try `sh -x setup.sh i386_bnr' in addition, which will build the ODE build tools in a different export directory using different makefiles; that will probably give you a different subset of working executables. Hopefully by building the build tools both ways and with a little tweaking, you can get a full set. The executables will appear in `mach/export/i386_mach/bin' and `mach/export/i386_bnr/bin'; just copy any you need from i386_bnr to i386_mach and ignore i386_bnr thereafter. Once you think you have the build tools you need (you might very well have missed some and have to go back and tweak more later, but...) cd into `mach/src/buildtools/ode/setup' again and type `csh setvar.csh i386_mach'. That'll set a zillion environment variables and pop you into a subshell of some kind. You'll be sitting in the top-level mach/src directory at that point. >From that shell, go into buildtools, mk, lites, and user in turn and type `odemake' in each, repeating the process and making any necessary tweaks until you wind up with a working Lites server or you decide to give up. :-) (All these trees are quite cross-dependent, so a single pass will definitely not work.) It should be obvious that these instructions aren't at all complete; and I should warn you that much of this is from memory so what's there might not even be completely accurate. Good luck, you'll need it! :-) Bryan From DALL@HFRD.DSTO.GOV.AU Mon Sep 19 18:38:54 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Sep 1994 03:29:36 +0300 09:59:06 +0930 Date: Tue, 20 Sep 94 10:00:43 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: lites ns32k port: progress X-Hfrd: 1994092009565386 Last weekend was to be the time for testing lites on the pc532. First, I discovered the dp8490 driver wouldn't talk to the disk I planned to use for lite. (An old sun shoebox with an emulux adaptor and a Toshiba ESDI disk). After fixing the driver (actually a significant clean up), I unpacked a 4.4Lite distribution (minus the source code) and then unpacked the netbsd base.tar.gz on top of that. Then I did a MAKEDEV, checked the device numbers were the same as in ns532/conf.c, and made and populated a mach_servers directory. So finally last night (Monday) I got to actually test the lites server. First, debugging lite from gdb didn't work. I can attach to the process, but not examine registers, continue or anything useful. I get an invalid thread message. I guess I have to look at incorporating Johannes' gdb patches. (But I am using gdb 4.13, not whatever is in the mach distribution, so this could be a non-trivial exercise). Just in case it would work without debugging (slim chance!), I ran without the h flag. I eventually realized I needed to run the new machid server. After that I get: bash# ./vmunix.LITES1.STD+WS+DEBUG.unstripped -2 sd5a /dev/sd5a/mach_servers kernfs: no raw boot device Mach_3.0_Lite VERSION(LITES1): Mon Sep 19 08:38:42 GMT-9:30 1994; server/STD+WS+DEBUG (sibyl.chez-ian) Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. Copyright (c) 1992 Carnegie Mellon University. Copyright (c) 1994 Helsinki University of Technology. All rights reserved. bdev_ioctl(dev = 28, cmd = 80086468, arg = 7fff00, mode = 1)--------- Base is Mon Sep 19 13:40:41 1994 Current time is Mon Sep 19 13:42:8 1994 Time is set to Mon Sep 19 13:42:8 1994 timer: 4 timeouts adjusted by 0.600000 seconds panic: init died Debugger I am curious about the kernfs message and about the bdev_ioctl message. The kernfs message comes from kernfs_init which seems to be looking for a cdevsw entry with the same dopen routine as the root block device. Looking at conf.c, this is never the case, and the i386 conf.c seems the same. What is kernfs anyway? Maybe it isn't critical. The second curious thing is what is the bdev_ioctl doing? It just returns EIO anyway, but why the call? The device number (hex) looks correct for sd5a. As for the init died, there are 100 possible reasons for that. I replaced it with a hello-world (ux executeable). I needed to make sure it was linked with the old linker since the current linker (GNU 2.3) I am using under ux puts machine id info into the executeable which the new emulator doesn't recognize: emulator [1] emul_exec_open: Unknown a.out variant: /mach_servers/mach_init emulator [1] emul_exec_open failed for file "/mach_servers/mach_init" I fixed that for the ux emulator, but must have missed the code to fix in the new emulator. OK, so now I have a hello-world which will be recognized, and I just go back to: panic: init died However, I do get a console message: port_destroy(pid=20000001 pr=29680 comm="mach_init") Any clue what this would be? Something to do with the output to stdio? I am a bit confused about the console and how output to it is handled in the case of a second server. When I remove mach_init totally I get a slightly different message: panic: first program exec failed: (os/kern) protection failure (Isn't it supposed to find /sbin/init if mach_init doesn't exist?) This is all mildly encouraging. After all, there is evidence that it is finding the root device, understanding the file system, loading the emulator and recognizing a.out formats. You have to be an optimist in this business! Ian From jvh@cs.hut.fi Tue Sep 20 11:18:08 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Sep 1994 20:10:39 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 20 Sep 1994 20:10:15 +0300 Date: Tue, 20 Sep 1994 20:10:15 +0300 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: lites ns32k port: progress In-Reply-To: <9409200030.AA05490@hfrd.dsto.gov.au> References: <9409200030.AA05490@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian, let me try to answer your questions. Gdb needs to be the Mach version as ptrace is not working enough to run a unix gdb. For multithreaded programs that is the only option anyways. I also added a field to cproc_t in order to make gdb able to aid in deadlock debugging. This change in cthread_internals.h made the old gdb incompatible as it reads cprocs. I should clean up and complete the gdb code and try to get it integrated into the main stream. The problem is that the attitude towards our various thread debugging codes at Cygnus has been difficult (they did integrate neither our Solaris nor Mach threads code and instead wrote their own that doesn't work). Maybe next year ... 1/2-). The error message from kernfs_init is not serious. It also appears on the i386. It ought to be fixed but I've put it on very low priority. bdev_ioctl isn't important either. I sometimes decoded the ioctl and found out that it did not matter. I forgot what it actually did but I maybe should have added code to totally ignore ioctls known not to matter with comments why. init could really fail for a hundred different reasons. For example if the binary is loaded incorrectly it will get an exception and get killed. A breakpoint in ux_exception within the server often helps. Without gdb debugging of course is rather painful. If you make syscall_debug some large number instead of zero in the emulator you'll get some verbosity out of it. After you have a shell that can be enabled by saying setenv EMULATOR_DEBUG 5 For the first program it is easiest to change it in the source and recompile. The port_destroy(... message comes from machid. It was supposed to be a debugging printf that I've forgotten to remove from USER/bin/machid.c:port_destroy(). Ahem, sorry about that. Anyways, that shows you that the task port of mach_init died. It would be nice to have some more verbose diagnostics in the first program init when something goes wrong. However, I've used the exact same code as is used for loading latter programs and there verbosity would not be appropriate. If someone has suggestions of how to do good diagnostics let me know. The "(os/kern) protection failure" text is most probably not really that but instead ENOENT. They have the same error code (=2). I plan to change all the server internal errnos to mach error codes and convert mach errors to personality error codes (errnos) within the emulator. This would remove the ambiguity. However, currently there are both Mach errors and BSD errnos within the same error code name space thus causing confusion. As you can see in server/kern/init_main.c:system_setup() only one path name is tried for the first exec. This is by default /mach_servers/mach_init. Adding a loop that would try a few different alternatives would not be a bad idea. Before that, however, you need to make a symlink to /sbin/init to run it. I added code to mach_init to try a few different paths but the server currently tries just one. Anyways now that the emulator is started successfully you are rather close to getting things working (at least to some extent). BTW, debugging with the kernel debugger works better if you boot Lites as the first server. Then its symbol table will be loaded automatically. You also need to set debug_user_with_kdb to one. Johannes From DALL@HFRD.DSTO.GOV.AU Tue Sep 20 18:25:47 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 21 Sep 1994 03:19:23 +0300 09:48:41 +0930 Date: Wed, 21 Sep 94 09:50:14 +0930 From: Ian Dall To: lites@cs.hut.fi Cc: jvh@cs.hut.fi Subject: Re: lites ns32k port: progress In-Reply-To: <199409201710.AA05665@laphroaig.cs.hut.fi> References: <9409200030.AA05490@hfrd.dsto.gov.au> <199409201710.AA05665@laphroaig.cs.hut.fi> X-Hfrd: 1994092109462531 Johannes Helander writes: > Ian, let me try to answer your questions. > Gdb needs to be the Mach version as ptrace is not working enough > to run a unix gdb. gdb 4.13 has mach support, although the fetch state from an attached process doesn't seem to work. > For multithreaded programs that is the only > option anyways. Yes. gdb is supposed to have thread support now, but I don't think *mach* threads are supported by the new code. > I also added a field to cproc_t in order to make gdb able to aid > in deadlock debugging. This change in cthread_internals.h made the > old gdb incompatible as it reads cprocs. I should clean up and > complete the gdb code and try to get it integrated into the main > stream. The problem is that the attitude towards our various > thread debugging codes at Cygnus has been difficult (they did > integrate neither our Solaris nor Mach threads code and instead > wrote their own that doesn't work). Maybe next year ... 1/2-). I looked at trying to fit your patches into the current gdb and it doesn't look easy! Maybe I will just go back to the old mach gdb. I suspect the ns532 support will be out of date though. > As you can see in server/kern/init_main.c:system_setup() only one > path name is tried for the first exec. This is by default > /mach_servers/mach_init. Adding a loop that would try a few > different alternatives would not be a bad idea. I got confused. It is mach_init which tries the multiple places for init. I was using the old mach_init which didn't look in sbin. I fixed emulator to recognize the right machine bits in the aout header and it now recognizes binaries from the new ld. Then I put in the new mach_init, but I still get an "init died" message. MK prints out a message about an illegal instruction at 0xa0001f03 or somewhere clearly in the emulator addresss. > Anyways now that the emulator is started successfully you are > rather close to getting things working (at least to some extent). It occurs to me that the emulator may not necessarilly be loaded correctly. Since it is mostly pic code, it could execute someway correctly before it died, and I am getting a trap in the emulators address space. It looks like getting the gdb support right is the main step. Ian From jvh@cs.hut.fi Wed Sep 21 11:23:40 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 21 Sep 1994 20:15:42 +0300 (5.65c8/HUTCS-C 1.3 for lites); Wed, 21 Sep 1994 20:15:25 +0300 Date: Wed, 21 Sep 1994 20:15:25 +0300 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: lites ns32k port: progress In-Reply-To: <9409210020.AA13392@hfrd.dsto.gov.au> References: <9409200030.AA05490@hfrd.dsto.gov.au> <199409201710.AA05665@laphroaig.cs.hut.fi> <9409210020.AA13392@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall wrote: > I looked at trying to fit your patches into the current gdb and it > doesn't look easy! Maybe I will just go back to the old mach gdb. > I suspect the ns532 support will be out of date though. No. I know. That is a problem. The patches are not even very mature as I didn't clean them up and fixed bugs only when they started disturbing me enough. That happens when writing code only as a byproduct (that is, I was hacking on Lites and worked on gdb only to make my debugging easier). I think though that there is some pretty reasonable functionality so it would be worthwhile to do something more about it. One reason I didn't bother so much was that the earlier Mach code did not make it into the distribution (the previous code was better quality but less functionality). If there is going to be a chance to get the new code incorporated, or if there is other need for it, I might pick it up, merge it with a new gdb version, and clean it up. Currently it is in my *low* priority queue. The big difference to the older HUT/CMU version is the cproc structure layout which is duplicated within gdb (from cthread_internals.h). If you make it correspond in your gdb version you might have better success. You should though be able to attach to tasks and look at kernel threads without the ability to read cthreads (assuming the 32k port works at all). > MK prints out a message about an illegal instruction at 0xa0001f03 > or somewhere clearly in the emulator addresss. Try to figure out where the text segment is supposed to be (according to the linker) and compare that with where the server loads it (put some printf in server_exec_load() if you can't use gdb). The vminfo program that comes with machid is very useful for looking at address spaces. In order to examine the task you must take care that it is not terminated. This is easiest done by putting a breakpoint at ux_exception() in the Lites server (again requires gdb...). Another good place to put a breakpoint at is after_exec(). It is always called by the emulator almost immediately after it is started. Use one gdb to put the breakpoint in the server and continue it. Then run the application to be debugged under Lites. Start another gdb under your other unix server with the emulator symbols. Attach it to the application (use ms to find out its MID). Now continue Lites from the first debugger and you can single step or whatever the emulator from the second debugger. A large X screen is recommended. Johannes From DALL@HFRD.DSTO.GOV.AU Wed Sep 21 21:34:25 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 22 Sep 1994 06:27:25 +0300 12:56:46 +0930 Date: Thu, 22 Sep 94 12:58:28 +0930 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: lites ns32k port: progress In-Reply-To: <199409211715.AA02555@laphroaig.cs.hut.fi> References: <9409200030.AA05490@hfrd.dsto.gov.au> <199409201710.AA05665@laphroaig.cs.hut.fi> <9409210020.AA13392@hfrd.dsto.gov.au> <199409211715.AA02555@laphroaig.cs.hut.fi> X-Hfrd: 1994092212543220 Johannes Helander writes: > Ian Dall wrote: >> MK prints out a message about an illegal instruction at >> 0xa0001f03 or somewhere clearly in the emulator addresss. With the aid of a few print outs (syscall_debug = 5), and a bit of guess work I found out that the user stack pointer was being corrupted. emul_vector.s wasn't quite right. Now it gets *much* further. mach_init gets executed and seems to be working more or less correctly. Mach init forks and the parent times out (60 seconds) waiting for a signal from the child. The odd thing is that the kill (SIGTERM) never happens. However, the alarm clock stuff all works. This is quite encouraging, since clearly system calls are being made and handled (fork, sigvec, sigblock, pause, getpid at least), signals (4.3 style) are being delivered to the process and handled. This must exercise the majority of the machine dependent code I would think. I don't understand why mach_init's child never sends the kill though. It must hang doing some of its mach type stuff. It there any mach type reason for that? Perhaps something to do with being a second server? The second problem comes (after the timeout) when sbin/init is executed, there is an error vmallocating the bss. It turns out that mach_init has bss size of 0, which is why it works rather than some weird problem execing a second process. Probably the vmallocate is getting ridiculous parameters, but I haven't had the chance to investigate further so far. Ian From jvh@cs.hut.fi Thu Sep 22 12:15:48 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 22 Sep 1994 21:06:07 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 22 Sep 1994 21:05:28 +0300 Date: Thu, 22 Sep 1994 21:05:28 +0300 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: lites ns32k port: progress In-Reply-To: <9409220328.AA22511@hfrd.dsto.gov.au> References: <9409200030.AA05490@hfrd.dsto.gov.au> <199409201710.AA05665@laphroaig.cs.hut.fi> <9409210020.AA13392@hfrd.dsto.gov.au> <199409211715.AA02555@laphroaig.cs.hut.fi> <9409220328.AA22511@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > out (60 seconds) waiting for a signal from the child. The odd thing is > that the kill (SIGTERM) never happens. However, the alarm clock stuff > all works. The same thing (usually) happens on the i386 with mach_init. The signal actually arrives but sigsuspend is for some reason retried. This was difficult to debug and I haven't yet figured it out. > The second problem comes (after the timeout) when sbin/init is > executed, there is an error vmallocating the bss. It turns out that Sounds like the exec header is still not interpreted right. There are several header and linker dependent calculations in emulator/emul_exec.c:emul_exec_load() A conditional printf printing all the different variables would be good. It could depend on the syscall_debug variable as other diagnostic printfs. bss_fragment is the part of BSS that is on a page that also contains part of the DATA segment. bss_residue is the remaining BSS (the clean part) rounded up to full pages. The first is bzeroed and the second vm_allocated. Johannes From DALL@HFRD.DSTO.GOV.AU Thu Sep 22 19:10:40 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 23 Sep 1994 04:04:47 +0300 10:34:04 +0930 Date: Fri, 23 Sep 94 10:35:50 +0930 From: Ian Dall To: jvh@cs.hut.fi Cc: dall@hfrd.dsto.gov.au, lites@cs.hut.fi Subject: Re: lites ns32k port: progress X-Hfrd: 1994092310315179 Johannes Helander writes: > Ian Dall writes: >> The second problem comes (after the timeout) when sbin/init is >> executed, there is an error vmallocating the bss. It turns out >> that > Sounds like the exec header is still not interpreted right. There > are several header and linker dependent calculations in > emulator/emul_exec.c:emul_exec_load() Actually, what seems to happen it this: For some reason, all of memory from 0 to 16MB is already allocated. The text and date sections work because bsd_vm_map de-allocates the region first. For bss, a straight vm_allocate is performed and fails because the address range is already allocated. The odd thing is that I can't find any constant anywhere that is 16MB (0x1000000) I can tell this by running vminfo while waiting for the mach_init timeout. I could probably make the bss allocation do a de-allocate first, but I notice that other things (like obreak) also assume the space isn't allocated. It seems the bug is that the space is allocated in the first place, and I can't figure out where yet. I found a one line fix to my gdb problems. Normal inferior process debugging worked fine, but attached process debugging didn't. Since these are actually highly similar for mach, the problem couldn't be that significant. I found that the current_thread was zero and that their needed to be a select_thread call (which uses task_info etc to find the first available thread). Quite likely there is some functionality still missing, but it seems to work OK for basic stuff. Now I should be able to insert breakpoints until I find where the problem is. Ian From idall@eleceng.adelaide.edu.au Sat Sep 24 22:57:58 1994 (5.65c8/HUTCS-S 1.4 for ); Sun, 25 Sep 1994 06:44:24 +0200 Date: Sun, 25 Sep 1994 14:14:20 +0930 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi Subject: Got a shell prompt! OK, I have mode lots of progress. I get as far as a single user shell prompt, and I can even run commands so long as they are shell builtins. If I try and execute something, I run into an unimplimented system call 188. It turn out that this is supposed to be stat, from looking at the netbsd syscall file. I wonder why there is a compatability stat at syscall 38 and a new one at syscall 188. Someones attempt to rationalize? It seems to just use up more of the syscall space. OK so I can fix that easilly probably. If I try and use a ux linked bash as the shell, the MK crashes with an attempt to remove a wired page! This port has gone fairly easilly all things considered. I had few bugs in the machine dependent code although one of them took a bit of finding. Now for the machine independent code. The one real problem I ran into I don't have a correct fix for. I can't see how this could not show up for the i386 so maybe the snapshot I am working from is a not quite working one. Symtom: That the emulator exec code fails when it tries to allocate bss space. Cause: The first 16MB is already vm_allocated. The bsd_vm_map used for text and data segments deallocte first so they don't notice. Analysis: The 16MB is allocated by cthread_init, caled from e_crt0.o. Basically, stack_init probes the current stack region to figure out how big it is. This turns out to be 16MB (possibly an over estimate if the emulator stack is adjacent to another RW region). It then steps up from address 0 in chunks of stack_size (16MB) until a vmallocate succeeds. Normally this is the 1st 16MB. The ux server allocates all the processes space before executing the emulator, so the problem doesn't arise so much. Also, maybe the ux emulator doesn't call cthread_init at all. Work around: vm_allocate the 1st page with no access permission (to trap null pointer dereferencing). vmunix does this for its self, but not for its child processes. The cthread stack now is mapped to the second 16MB. This is hardly the correct solution, but I figure that it must have been solved for the 386 port so I'll ask instead of working on it further. There are a couple of other minor fixes. I'll clean up and feedthem back soon. Ian From jvh@cs.hut.fi Sun Sep 25 16:32:04 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 26 Sep 1994 00:20:17 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 26 Sep 1994 00:19:11 +0200 Date: Mon, 26 Sep 1994 00:19:11 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Re: Got a shell prompt! In-Reply-To: <9409250444.AA17063@augean.eleceng.adelaide.edu.au> References: <9409250444.AA17063@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > If I try and execute something, I run into an unimplimented system > call 188. It turn out that this is supposed to be stat, from looking > at the netbsd syscall file. I wonder why there is a compatability stat > at syscall 38 and a new one at syscall 188. Someones attempt to > rationalize? It seems to just use up more of the syscall space. This is because emulator/e_bnr_sysent.c only contains BNR2 system calls. However you have a 4.4 binary. You should be using a 4.4 sysent switch (e_lite_sysent.c or whatever). I did not include one as at the time I didn't have any real 4.4 binaries. I don't know how to distinguish bnr binaries from lite binaries. If you can't, then it is a reasonable assumption that all binaries are lite binaries with compat needed. e_stat.c already contains support for lite stat structures (in addition to bnr, sysv, and linux ones). e_bsd_stubs.c also defines a function e_lite_stat() that you can add in the system call switch at slot 188. So the functionality is all there (albeit untested) but the function is not being called. > OK so I can fix that easilly probably. If I try and use a ux linked > bash as the shell, the MK crashes with an attempt to remove a wired > page! This is really a bug in the i386 pmap code which I carried over to the pc532 by copying the code originally. I did not know how to solve it correctly though so I did not attempt to fix the i386 kernel. If you just continue in the debugger it's all fine so basically it could be said that the bug is the bogus sanity check that causes th panic. The issue here is that the mapped time device is mapped to the user program. As the mapping is a device it is wired. After the program forks the mapping is inherited (VM_INHERIT_SHARE) and when (well, I can't now remember exactly) either the child or the parent or both (?) exits, task_terminate terminates the address space deallocating memory, including the wired page. The sanity check figures out that some unexpected deallocation happened and calls panic. Because of this problem I didn't enable the mapped gettimeofday() version for most programs. However I tried it on UX programs and left it there. A quick fix is to change e_mapped_gettimeofday() to e_gettimeofday() in e_cmu_43ux_sysent.c. The long term solution is to fix pmap.c in the kernel. > The 16MB is allocated by cthread_init, caled from e_crt0.o. Basically, Calling cthread_init in the emulator indeed seems like bogus. The only cthread feature the emulator is supposed to be using is spin locks which don't need calling cthread_init. I didn't realize it was called on the i386. I cleaned up the crt0.c a lot but forgot to clean it up even more. Now I can't be sure things will work if you remove the call but if you try that let me know if it worked. > stack_init probes the current stack region to figure out how big it > is. This turns out to be 16MB (possibly an over estimate if the As an unrelated issue I should say that I strongly dislike this behavior in the server as well as it makes the cthread stack sizes depend on whether or not the server is started as first or second server. This makes stack size nondeterministic and debugging harder. The stack sizes should be defined at compile time instead. > vm_allocate the 1st page with no access permission (to trap null > pointer dereferencing). vmunix does this for its self, but not for its This would be a good idea in any case as it catches application program bugs. Johannes From DALL@HFRD.DSTO.GOV.AU Mon Sep 26 19:12:18 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 27 Sep 1994 03:05:01 +0200 09:53:59 +0930 Date: Tue, 27 Sep 94 09:55:43 +0930 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: Got a shell prompt! In-Reply-To: <199409252219.AA04837@laphroaig.cs.hut.fi> References: <9409250444.AA17063@augean.eleceng.adelaide.edu.au> <199409252219.AA04837@laphroaig.cs.hut.fi> X-Hfrd: 1994092709513631 Johannes Helander writes: > Ian Dall writes: > This is because emulator/e_bnr_sysent.c only contains BNR2 system > calls. However you have a 4.4 binary. You should be using a 4.4 > sysent switch (e_lite_sysent.c or whatever). I did not include one > as at the time I didn't have any real 4.4 binaries. I don't know > how to distinguish bnr binaries from lite binaries. If you can't, > then it is a reasonable assumption that all binaries are lite > binaries with compat needed. I don't have any bnr2 binaries and the netbsd binaries seem 4.4ish. I do have 4.3 binaries I would like to run at least for a transition period. > e_stat.c already contains support for lite stat structures (in > addition to bnr, sysv, and linux ones). e_bsd_stubs.c also defines > a function e_lite_stat() that you can add in the system call > switch at slot 188. So the functionality is all there (albeit > untested) but the function is not being called. OK, I've added it, but not sure it works though. >> [Wired pages] > left it there. A quick fix is to change e_mapped_gettimeofday() to > e_gettimeofday() in e_cmu_43ux_sysent.c. The long term solution is > to fix pmap.c in the kernel. I did the former, and with that, a 4.3 bash runs OK. >> The 16MB is allocated by cthread_init, caled from >> e_crt0.o. Basically, > Calling cthread_init in the emulator indeed seems like bogus. The > only cthread feature the emulator is supposed to be using is spin > locks which don't need calling cthread_init. I didn't realize it > was called on the i386. I cleaned up the crt0.c a lot but forgot > to clean it up even more. Now I can't be sure things will work if > you remove the call but if you try that let me know if it worked. I tried it and it doesn't work. The problem seems to be that emul_init expects new_stack and old_stack to be different. I am not sure what all this is about. It looks like old_stack is just used as a scratch area for the after_exec rpc to use for transferring the argument space. In fact the problem doesn't occur until a bit latter when it tries to execute some location with an invalid instruction in it, so I am just guessing that it is somehow related to the stack business. > As an unrelated issue I should say that I strongly dislike this > behavior in the server as well as it makes the cthread stack sizes > depend on whether or not the server is started as first or second > server. Me too. I reckon cthread_init should take an argument for the size of stack to create and probably an address which it must be located above (to allow room for a heap). I have actually taken a step backwards in so far as the netbsd init seems to have stopped working. If I revert to a really simple init substitute I knocked up: bash# ./vmunix -2s sd5a /dev/sd5a/mach_servers kernfs: no raw boot device Mach_3.0_Lite VERSION(LITES1): Sun Sep 25 12:36:49 GMT-9:30 1994; server/STD+WS+DEBUG (sibyl.chez-ian) Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. Copyright (c) 1992 Carnegie Mellon University. Copyright (c) 1994 Helsinki University of Technology. All rights reserved. bdev_ioctl(dev = 28, cmd = 80086468, arg = 9fff00, mode = 1)--------- Base is Mon Sep 26 14:6:26 1994 Current time is Mon Sep 26 14:6:41 1994 Time is set to Mon Sep 26 14:6:41 1994 timer: 4 timeouts adjusted by 0.700000 seconds sh: can't access tty; job control turned off erase ^H, kill ^U, intr ^C status ^T Don't login as root, use the su command. # ls ls Segmentation fault - core dumped # bash bash bash$ ls ls ^C # # # # sleep 2 sleep 2 # type sleep type sleep type: not found # /bin/sleep 2 /bin/sleep 2 Notice netbsd executables which do no output appear to work. Now try bin echo # EMULATOR_DEBUG=5 /bin/echo foo EMULATOR_DEBUG=5 /bin/echo foo emulator [9] emul_exec_open success: "/bin/echo" p=900 fd=-1 BT=3 emulator [9] emul_setup: type 3 emulator [9] emul_exec_start: entry = 0x1020 emulator [9] emul_exec_start: starting at x1020 k=xbfffdfdc (x2 xbfffe000 xbfffe00a x0) emulator [9] emul_syscall[189] e_lite_fstat(x1, xbfffdce4, x0, x0, x72a8) emulator [9] return[189] e_lite_fstat = (x0 x2d) emulator [9] emul_syscall[17] e_obreak(x7c54, x0, x800, x72a8, xbfffdd68) emulator [9] return[17] e_obreak = (x0 xca) emulator [9] emul_syscall[17] e_obreak(xfffffffc, x0, x800, x72a8, xbfffdd68) emulator [9] return[17] e_obreak = (x0 xffffffff) Segmentation fault - core dumped # Well it is not surprising it failed to allocate that many bytes. The question is why did it attempt to allocate them in the first place? My working hypothesis is that fstat is returning a bad quantity (size say) and the program tries to allocate space for that many bytes. This could be in the stdio, since just about all of the executables fail the same way. (But why you would do that anyway I don't know). I haven't had time to track down further, and unfortunately, I don't have sources for the netbsd executeables/libraries etc (yet at least). Ian From idall@eleceng.adelaide.edu.au Tue Sep 27 10:46:18 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 27 Sep 1994 18:24:04 +0200 Date: Wed, 28 Sep 1994 01:53:21 +0930 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: jvh@cs.hut.fi Cc: lites@cs.hut.fi, mach-ns32k@cs.hut.fi Subject: The 532 lite server works! With lots of machine code level debugging of /bin/echo (because it had been stripped) it finally dawned on me what was happening. getpagesize was returning 0 which was breaking malloc. In 4.4, getpagesize is a subroutine which calls sysctl. sysctl is no 202 which was one bigger than the emul_highest or whatever it is called. Anyway, mk wasn't passing thatparticular call on to the emulator! I have tried a number of executables from sun-lamp netbsd and they seem to work OK as far as I have tried them. Mount doesn't want to know about the 4.3 file system so I'll have to sanitise it. Also I haven't tried anything tricky like tape IO. Still, that shouldn't be too bad (adding the tape support for the ns32k ux port was fairly easily). I am still not very happy with the way the virtual memory gets allocated by cthread_init in the emulator startup, but now we are talking about refinements. Congratulations, Johannes, on a good bit of work! Ian From mike@cs Sat Oct 1 16:11:59 1994 (5.65c8/HUTCS-S 1.4 for ); Sun, 2 Oct 1994 00:03:36 +0200 Date: Sat, 1 Oct 94 16:03:07 -0600 From: mike@cs (Mike Hibler) To: lites@cs.hut.fi Subject: LITES PA-RISC 1.1 (hp700) port running single-user Cc: machoids@jensen As of Friday, I achieved the first shell prompt and executed some simple binaries (e.g. date, ls). The environment is currently a little odd and pretty much useless to anyone but us: I am running it as a second server in an OSF-based kernel/server environment (not freely available). The world that LITES sees (i.e. the binaries it executes) is our hybrid 4.3/4.4 BSD system (also not freely available). The porting experience to date has been similar to Ian's, with a few additional PA-specific problems (stack direction, argument order, lock polarity) thrown in. Nothing we haven't already dealt with before however and no major LITES changes were required. I also congratulate and thank Johannes for his efforts! Next up is getting to multi-user and dealing with the inevitable signal handling problems. Then I'll move it onto a migrating-threads MK83 kernel still using our BSD environment. Other potential future enhancements (in no particular order): - stability and speed :-) - implement missing LITES features (debugging, profiling, ktrace, sigstacks, etc.) - limited HP-UX compatibility via the emulator - full HP-UX compatibility (allowing it to run on top of an HP-UX filesystem). - evolve the binary base toward 4.4 or netbsd - take advantage of migrating threads and other "Mach 4" features - support for older PA 1.0, aka "hp800" (though this is largely an MK issue) From DALL@HFRD.DSTO.GOV.AU Tue Oct 4 07:49:52 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Oct 1994 15:38:02 +0200 10:14:22 +0930 Date: Tue, 4 Oct 94 10:16:25 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: LITES PA-RISC 1.1 (hp700) port running single-user In-Reply-To: <9410012203.AA21264@cs.utah.edu> References: <9410012203.AA21264@cs.utah.edu> X-Hfrd: 1994100410120228 mike@cs.utah.edu (Mike Hibler) writes: > As of Friday, I achieved the first shell prompt and executed some > simple binaries (e.g. date, ls). The environment is currently a > little odd and pretty much useless to anyone but us: I am running > it as a second server in an OSF-based kernel/server environment > (not freely available). The world that LITES sees (i.e. the > binaries it executes) is our hybrid 4.3/4.4 BSD system (also not > freely available). > The porting experience to date has been similar to Ian's, with a > few additional PA-specific problems (stack direction, argument > order, lock polarity) thrown in. One significant thing I discovered recently you might want to look at. ecrt0.o shouldn't call cthread_init() but when I first removed the call lites stopped working altogether. cthread_init returns a new stack and deallocates most of the old stack. It is an error to continue using the old stack and it is the callers responsibility to do the switch. If you try and execute anything which uses significant stack it will die. It turns out the problem is in emul_init.c where it has something like if (old_sp == new_sp) old_sp = 0; This is completeley bogus. If you take it out, and also remove the cthread_init (and most of the rest of ecrt0.c) everything works much more cleanly. Ian From andrea@inf.ufrgs.br Wed Oct 5 17:18:02 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 6 Oct 1994 01:10:36 +0200 Wed, 5 Oct 1994 20:08 BSC (-0300 C) 5 Oct 94 20:12:44 EST Wed, 5 Oct 94 20:08:45 EST Date: Wed, 5 Oct 94 20:08:45 EST From: andrea@inf.ufrgs.br (Andrea Schwertner Charao) Subject: networking under Lites To: lites@cs.hut.fi Cc: jvh@cs.hut.fi X-Envelope-To: jvh@cs.hut.fi, lites@cs.hut.fi Hi! I am running Lites since two weeks ago, and **almost** every NetBSD binary seems to work fine. My problem is about the network initialization: the mkernel recognizes my Etherlink II, but some programs needed for network configuration do not work properly (domainname and route, speaking more clearly). I have ftp'ed a *route* binary from leia.cs.hut.fi, but it also did not help me. Does anybody can help me with some hints? Thanks in advance, Andrea From DALL@HFRD.DSTO.GOV.AU Sun Oct 9 19:54:59 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 10 Oct 1994 03:47:58 +0200 11:17:01 +0930 Date: Mon, 10 Oct 94 11:19:01 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: Loose ends and performance X-Hfrd: 1994101011142488 I have implimented what I beleive to be a "correct" tape_io.c (analog of disk_io.c). Unfortunately it also requires an MK patch to work properly. It addresses a long standing complaint I have had with ux/mach and the handling of filemarks on tapes (and end of tape similarly). In fact you will notice a "kludge to support tapes" comment in disk_read. That code can now go since there is a seperate tape_read function. This is actually the third attempt I've made at solving this problem (formerly in ux/mach but now in lites/mach) but this is the first time I am reasonably convinced it is the "right" approach. I got the profiling code working. It took a bit of puzzling to figure out what one has to do with the sequence numbers. The bsd_mon_switch doesn't need to do anything special with the port_object, but it does need to observe the serializing on sequence number protocol. Probably there should be a simpler support routine which does the lock, does the condition_waits, increments the sequence number und does the unlock all in one call. A little documentation would do wonders here if anyone gets around to it. The most outstanding functional deficiency now it that code to sync the disks on halt doesn't work and is #ifdef'd out. Instead it prints a nice "WARNING: No Update (Ha, ha your super block is trashed)" message ;-(. Oh well, fsck -b 32 works. And you can manually sync, wait a while and then halt. With profiling working I set about running my pet performance benchmark. I have a little program called pipe-test, which simply forks and transfers data through a pipe between parent and child. The size of the reads and writes can be specified (although the semantics of a unix pipe are that you might get less than you asked for on a read). Anyway, I have run this program on a variety of machines. It didn't run very well under ux. Here are some earlier results I got. The Ultrix and mk/ux results are for essentially identical hardware. The SunOs results are on a Sparcstation II which is around the same specmarks as the DECstation. Block size mk/ux Ultrix SunOs -------------------------------- 1k .4 3.8 2.2 4k 1.1 7 3.6 8k .9 5.4 4.6 Now unfortunately lites isn't running on the Decstation, so an apples/with apples comparison isn't possible. On my pc532, however, I get around 750kB/s with mk/ux (not bad cf the Decstation) and only about 350kB/s under lites. So roughly, one might say that lites is less than half as fast as ux which is less than 1/5 as fast as Ultrix. A factor of 10 in performance it worth worrying about! You notice it with something like "tar -cz ...". Some of this may be due to the BSD implimentation of pipes on top of sockets (does 4.4 still do this? I notice that Ultrix documentation says that pipes are no longer socket based). Anyway it is a worry that lites is slower than ux which was already pretty slow! So, what does profiling reveal? Unfortunately, no glaringly obvious bottle necks. Profiling slows it down quite noticably as it spends a lot of time in mcount and mcountaux. Disregarding that, a lot of time is spent in spl_n, spin_try_lock and spin_unlock. I have inlined the latter two and am in the process of recompiling everything. That leaves spl_n. It is called a very large number of times ~60k in not very long (6 cpu seconds, quite a lot longer elapsed time by the time I turned profiling off). Unfortunately, the call graph doesn't reveal anything very interesting about where spl_n gets called from. Ian From jvh@cs.hut.fi Tue Oct 11 21:52:07 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 12 Oct 1994 05:42:24 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 12 Oct 1994 05:41:47 +0200 Date: Wed, 12 Oct 1994 05:41:47 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: LITES PA-RISC 1.1 (hp700) port running single-user In-Reply-To: <9410040046.AA29283@hfrd.dsto.gov.au> References: <9410012203.AA21264@cs.utah.edu> <9410040046.AA29283@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian, Thanks for figuring that out. The bogus you cleaned up was a left over from the early stages of writing the emulator that I forgot to remove. It definitely should go without any doubt. Johannes Ian Dall writes: > It turns out the problem is in emul_init.c where it has something like > > if (old_sp == new_sp) > old_sp = 0; > > This is completeley bogus. If you take it out, and also remove the > cthread_init (and most of the rest of ecrt0.c) everything works much > more cleanly. From jvh@cs.hut.fi Tue Oct 11 23:45:43 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 12 Oct 1994 07:40:18 +0200 (5.65c8/HUTCS-C 1.3 for lites); Wed, 12 Oct 1994 07:40:09 +0200 Date: Wed, 12 Oct 1994 07:40:09 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Loose ends and performance In-Reply-To: <9410100149.AA00277@hfrd.dsto.gov.au> References: <9410100149.AA00277@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. I think that not only is the socket code slow but it also is unreliable. One reason could be an old problem that Sandro mentioned: in sockbufs (I think it was that one). There is just one bit protecting (socketvar.h defines SB_LOCK) the queue. This bit supposedly is protected by spls or whatever but maybe isn't. What about replacing it with a regular mutex? This would require adding a mutex_lock and unlock in the relevant places. I don't know at all if this has anything to do with the problem but the slowness would well be explained by some strange race condition. The time must be wasted somewhere! Just copying data around and other usual foolishness doesn't cost enough I'd say. Besides that all splnets could be replaced by a single lock. This is much harder than it sounds though as so many intricate side-effects will occur (namely with sleep race avoidance). Decoupling networking from the rest of the system is in any case an important step towards parallelization. I tried earlier to make one step in decoupling networking from the SPL mechanism by running the protocol stack directly from the receiving thread instead of delegating it to someone else (usually the timer thread or the receiver itself) through the netisr mechanism and splx. Removing the unnecessary delegation should also make the network latency slightly smaller which might help (marginally?) in network performance. If you compile with the +ether_as_syscall option the direct protocol running code is enabled. I got it to almost work but... Unfortunately the first select in inetd never wakes up. After selbroadcast (sp?) is called for some reason everything works fine. This is another indicator that there is a race condition in the socket code. Johannes From jvh@cs.hut.fi Wed Oct 12 00:00:41 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 12 Oct 1994 07:55:45 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 12 Oct 1994 07:55:33 +0200 Date: Wed, 12 Oct 1994 07:55:33 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Loose ends and performance In-Reply-To: <9410100149.AA00277@hfrd.dsto.gov.au> References: <9410100149.AA00277@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. spin_try_lock and spin_unlock are called by mutex_lock and unlock. Mutexes are used in spl_n (among other places). If spl_n is called tens of thousands of times in a few seconds it really sounds like someone is busy looping. Or perhaps two parties are looping. If this is related to sockets it is no wonder that little data gets actually moved. Maybe you could find a couple of intermixed call graphs spending the time? Thanks for fixing the profiler. I'm looking forward to get to use it. Johannes Ian Dall writes: > So, what does profiling reveal? Unfortunately, no glaringly obvious > bottle necks. Profiling slows it down quite noticably as it spends a > lot of time in mcount and mcountaux. Disregarding that, a lot of time > is spent in spl_n, spin_try_lock and spin_unlock. I have inlined the > latter two and am in the process of recompiling everything. That > leaves spl_n. It is called a very large number of times ~60k in not > very long (6 cpu seconds, quite a lot longer elapsed time by the time > I turned profiling off). Unfortunately, the call graph doesn't reveal > anything very interesting about where spl_n gets called from. From mike@cs Mon Oct 17 23:17:17 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Oct 1994 07:08:48 +0200 Date: Mon, 17 Oct 94 23:08:45 -0600 From: mike@cs (Mike Hibler) To: lites@cs.hut.fi Subject: why mach_init hangs for 60 seconds >From an early message from Ian: > Now it gets *much* further. mach_init gets executed and seems to be > working more or less correctly. Mach init forks and the parent times > out (60 seconds) waiting for a signal from the child. The odd thing is > that the kill (SIGTERM) never happens. Here is what causes it on the PA anyway. pause() is implemented as: sigpause(sigblock(0L)); which is "reasonably atomic" on a uniprocessor, monolithic BSD system. However, what was happening on the PA is that sigblock would trap to the emulator and then send a message to the server. At this point it context- switched and the child ran sending the SIGTERM. Then the parent is resumed and, when falling back out of the emulator, notices that a signal is pending and takes it before returning. Now sigpause is called anyway even though the signal has happened. The race exists in BSD but the window is much smaller (the signal could not occur while in sigblock because the code path doesn't voluntarily block, the process would have to be involuntarily context-switched between the return of sigblock and the call to sigpause, a couple of instructions). My "fix" was to change the emulator to not call take_signals_and_do_sigreturn when returning from e_sigblock(). Finally, note that this is really a bug in mach_init in the fast and loose way it handles the signal. From DALL@HFRD.DSTO.GOV.AU Tue Oct 18 00:31:42 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Oct 1994 08:22:57 +0200 15:52:14 +0930 Date: Tue, 18 Oct 94 15:53:54 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: More on socket performance X-Hfrd: 1994101815493681 Inlining spl_try_lock has given an improvement in performance on my pipe-test program of maybe 10%. Unfortunately, the remaining places where time is "wasted" is in spl_n and wakeup, neither of which can I see an easy way to speed up. It looks like exerything is doing what it is supposed to. ie, no races (not to say a race is impossible, just that it doesn't seem to happen regularly). I've tried a number of different block sizes, but for the following discussion I been transfered 4 MB in 64k read/writes. This results in 64 write's and 64 sosend's date is transferred from user space in 1k chunks so I get 4k uiomove's the mbufs are transferred to the receive buffer as they are received 4k uipc_usrreq's the data is transferred to the recaiving process space in 1k chunks for another 4k uiomove's the reading process is woken up when the receive buffer reaches hiwat (4k) so there are 1k soreceive's and 1k reads The time spent in vmunix only about half the elapsed time, so I am not sure where the rest is spent (I wisk I could profile mk!). The actual time spent in bcopy (the real work) is only .8 seconds for 4MB which would give an upper limit of 5MB/s transfer. I currently get an overall transfer rate of no more than 400kB/s. There are nearly 40k spl_n's in the above example, but it doesn't seem so surprising. It adds up to nearly 10 per 1k chunk transferred which doesn't seem out of the question looking at the number of them scattered around sosend and soreceive. So, as I say, there are no obvious bottle necks, it just seems that all those spl_n's and wakeups add up to a fair bit. Interestingly, if I cut the read/write chunk size right down to 32 bytes or so, the performance of ux and lites converge and is limited at around 400 read and 400 writes per second. With more normal 4kByte chunk size, there are only about 100 read and 100 writes per second, so it seems that the performance doesn't seem to be limited by context switch time. Further more, with large block sizes, the number of uiomoves and uipc_usrreq's is about 400 per second which would be strange if it were a coincidence! The most obvious thing to do is to increase MCLBYTES to say 4k, although this may not help much in practice if the stdio BUFSIZ size is 1k. I am not sure what other ramifications an increase like that would have. I guess PIPESIZ or whatever it is called should be increased too. Ian From root@corbin.Root.COM Tue Oct 18 00:48:00 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Oct 1994 08:40:52 +0200 X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: lites@cs.hut.fi Subject: Re: More on socket performance From: David Greenman Reply-To: davidg@root.com Date: Mon, 17 Oct 1994 23:40:45 -0700 Sender: root@corbin.Root.COM >Inlining spl_try_lock has given an improvement in performance on my >pipe-test program of maybe 10%. > >Unfortunately, the remaining places where time is "wasted" is in >spl_n and wakeup, neither of which can I see an easy way to speed up. I'm not sure if this is useful to you, but when I looked at socket performance in BSD, I found that the algorithm for deciding when to use an mbuf cluster was far too conservative and resulted in long chains of regular mbufs most of the time. The attached patch improves socket performance by about 50% in FreeBSD. -DG David Greenman The FreeBSD Group Index: uipc_socket.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.2 retrieving revision 1.3 diff -c -r1.2 -r1.3 *** 1.2 1994/05/25 09:05:40 --- 1.3 1994/05/29 07:48:17 *************** *** 407,431 **** MGET(m, M_WAIT, MT_DATA); mlen = MLEN; } ! if (resid >= MINCLSIZE && space >= MCLBYTES) { MCLGET(m, M_WAIT); if ((m->m_flags & M_EXT) == 0) goto nopages; mlen = MCLBYTES; ! #ifdef MAPPED_MBUFS ! len = min(MCLBYTES, resid); ! #else ! if (atomic && top == 0) { ! len = min(MCLBYTES - max_hdr, resid); ! m->m_data += max_hdr; ! } else ! len = min(MCLBYTES, resid); ! #endif ! space -= MCLBYTES; } else { nopages: len = min(min(mlen, resid), space); - space -= len; /* * For datagram protocols, leave room * for protocol headers in first mbuf. --- 407,421 ---- MGET(m, M_WAIT, MT_DATA); mlen = MLEN; } ! if (resid >= MINCLSIZE) { MCLGET(m, M_WAIT); if ((m->m_flags & M_EXT) == 0) goto nopages; mlen = MCLBYTES; ! len = min(min(mlen, resid), space); } else { nopages: len = min(min(mlen, resid), space); /* * For datagram protocols, leave room * for protocol headers in first mbuf. *************** *** 433,438 **** --- 423,429 ---- if (atomic && top == 0 && len < mlen) MH_ALIGN(m, len); } + space -= len; error = uiomove(mtod(m, caddr_t), (int)len, uio); resid = uio->uio_resid; m->m_len = len; From cmaeda@cs.washington.edu Tue Oct 18 03:42:34 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Oct 1994 11:34:21 +0200 To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: More on socket performance In-Reply-To: Your message of "Tue, 18 Oct 1994 15:53:54 +0930." <9410180623.AA04270@hfrd.dsto.gov.au> Date: Tue, 18 Oct 1994 02:33:49 PDT From: Chris Maeda I spent about two years of my life hacking on sockets performance on Mach 3.0 unix servers. The conclusion I reached in the context of the CMU UX server, is that you'll never win. I've measured an identical piece of code running in a unix application process and in the unix server, and seen the same code run 50-100% slower in the unix server. I was never able to adequately account for the slowdown. My best guess is that it's a lot of little things: simulated spl's, lock contention on critical mutexes, the MIG stub and IPC overhead, bad cache locality due to code bloat. Brad Chen presented some detailed measurements in SOSP 93: the Unix server runs more instructions and each instruction takes about an extra half cycle to complete. What I did instead, was to move a copy of the TCP/IP stack into each address space, and add enough support to the server to enable them all to coexist. Applications can then send and receive network packets without going through the Unix server. This will give you performance as good as an in-kernel implementation. Some unix server networking performance meaurements are in my WWOS 92 paper. The user-level networking work was presented at SOSP 93. These and other papers are accessible from my web page: http://www.cs.washington.edu/homes/cmaeda/index.html. The user-level networking is currently distributed as part of the CMU Unix server. If anyone wants to work on adding it to lites, I can pull it out and send it to you. Chris Maeda From rwd@osf.org Tue Oct 18 06:27:41 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Oct 1994 14:20:03 +0200 id IAA00226; Tue, 18 Oct 1994 08:19:33 -0400 To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: More on socket performance In-Reply-To: Your message of "Tue, 18 Oct 1994 15:53:54 +0930." <9410180623.AA04270@hfrd.dsto.gov.au> Date: Tue, 18 Oct 1994 08:19:32 -0400 From: "Randall W. Dean" I don't have a copy of LITES in front of me to look at what version of the pseudo SPL code is being used, but I will try to optimize it blind :-) The first version we had at CMU had a mutex lock for each spl level and required locking and unlocking multiple locks for each spl acquisition and release. This was successfully optimized by having the entire set of spls protected by a single mutex. If you have the first spl implementation, I would move to the second. It should make a big difference. There is one further optimization possible that was successful on both the CMU UX server and the OSF/1 SS that I tried it on, but was never released with either. Change the spl code to be a single mutex. Period. You either have a spl level > 0 and hold the lock or your level is < 0 and you do not hold the lock. This seams odd, but think about the pseudo implementation being used now. You can have 50 threads all running at spl0 even though a thread is running at spl7. The spl code only blocks out lower NONZERO spl threads from running. It turns out there is node code dependant on spls for locking where it takes an spl higher then it needs. ie foo is protected by spl5 and noone takes spl7 and says they have the "lock" for foo. -rwd From DALL@HFRD.DSTO.GOV.AU Sun Oct 23 17:49:28 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 24 Oct 1994 01:41:05 +0200 09:10:52 +0930 Date: Mon, 24 Oct 94 09:12:29 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: Recent changes X-Hfrd: 1994102409112985 I have made some changes since the last snap-shot I put on augean. The most important are to do with the arguments for the 4.4 versions of some system calls (lseek, mmap). When there is an eight byte argument it is aligned to an 8 byte boundary (from the start of the argument list which is also presumably on an eight byte boundary). This sometimes requires a padding argument. Without these changes, some netbsd executables wouldn't work (cp which uses mmap, fsck which uses seek etc etc). The other biggish change is only used if SIMPLE_SPL is defined. I followed up on an idea from Randall Dean which he suggests that most of the spl_n functionality isn't needed in practice. I couldn't get this to work however. Ian *** ../lites-1/server/conf/MASTER.local Wed Sep 28 23:57:02 1994 --- server/conf/MASTER.local Sun Oct 23 01:06:41 1994 *************** *** 53,56 **** --- 53,57 ---- # ####################################################################### + # options SIMPLE_SPL # <> makeoptions LOCAL_DEFINES="-DTIMEZONE=570 -DDST=DST_AUST" *** ../lites-1/server/serv/tape_io.c Sat Oct 15 15:25:11 1994 --- server/serv/tape_io.c Mon Oct 17 08:46:34 1994 *************** *** 231,239 **** return (0); } else - #else - return (dev_error_to_errno(rc)); #endif } (void) moveout(data, iov->iov_base, count); --- 231,238 ---- return (0); } else #endif + return (dev_error_to_errno(rc)); } (void) moveout(data, iov->iov_base, count); *** ../lites-1/server/serv/misc.c Thu Oct 6 18:29:54 1994 --- server/serv/misc.c Tue Oct 18 00:34:56 1994 *************** *** 18,24 **** * Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU * School of Computer Science * Carnegie Mellon University ! f * Pittsburgh PA 15213-3890 * * any improvements or extensions that they make and grant Carnegie Mellon * the rights to redistribute these changes. --- 18,24 ---- * Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU * School of Computer Science * Carnegie Mellon University ! * Pittsburgh PA 15213-3890 * * any improvements or extensions that they make and grant Carnegie Mellon * the rights to redistribute these changes. *************** *** 25,30 **** --- 25,34 ---- */ /* * HISTORY + * 18-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Remove test on bfreelist from boot() and use get_proc() to find + * the first argument for sync. + * * 06-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) * Boot sync code not working properly yet. Disable again. * *************** *** 74,79 **** --- 78,84 ---- #include #include #include + #include #include #include *************** *** 193,211 **** boolean_t paniced, int flags) { ! #if 0 register struct buf *bp; int iter, nbusy, obusy; if (((flags & RB_NOSYNC) == 0) && (waittime < 0) ! && (bfreelist[0].b_forw != 0)) { waittime = 0; (void) splnet(); printf("syncing disks... "); ! sync(0,0,0); obusy = 0; for (iter = 0; iter < 20; iter++) { --- 198,219 ---- boolean_t paniced, int flags) { ! #if 1 register struct buf *bp; int iter, nbusy, obusy; if (((flags & RB_NOSYNC) == 0) && (waittime < 0) ! #if 0 /* There is no bfreelist with the current bio code */ ! && (bfreelist[0].b_forw != 0) ! #endif ! ) { waittime = 0; (void) splnet(); printf("syncing disks... "); ! sync(get_proc(),0,0); obusy = 0; for (iter = 0; iter < 20; iter++) { *** ../../../hut/src/lites/server/serv/serv_synch.c Thu Jun 23 11:13:45 1994 --- server/serv/serv_synch.c Sun Oct 23 01:01:47 1994 *************** *** 28,33 **** --- 28,36 ---- */ /* * HISTORY + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added SIMPLE_SPL code. + * * $Log: $ */ /* *************** *** 483,488 **** --- 486,558 ---- mutex_unlock(&sleep_lock); } + + #if SIMPLE_SPL + /* This is not a complete emulation of spl, but it should + * be sufficient. Missing is the code to simulate the + * software interrupts + */ + void + spl_init() + { + } + + struct mutex spl_lock = MUTEX_NAMED_INITIALIZER("spl_lock"); + int spl_n(int new_level) + { + int old_level; + cthread_t t = cthread_self(); + proc_invocation_t pk = get_proc_invocation(); + struct proc *p = pk->k_p; + + if (pk->k_ipl < 0) { + panic("current ipl < 0", pk->k_ipl); + pk->k_ipl = 0; + } + + if (new_level < 0) { + panic("new_level < 0"); + new_level = 0; + } + + old_level = pk->k_ipl; + + if (new_level > 0) { + if (old_level == 0) + mutex_lock(&spl_lock); + } + else { + if (old_level > 0) + mutex_unlock(&spl_lock); + } + pk->k_ipl = new_level; + + /* + * Simulate software interrupts for network. + */ + { + extern int netisr; + extern void dosoftnet(); + + if (new_level < SPLNET && netisr) { + register int s = splnet(); + dosoftnet(); + splx(s); + } + } + return old_level; + } + + void interrupt_enter(int level) + { + spl_n(level); + } + + void interrupt_exit(int level) + { + spl_n(level); + } + #else /* * Stack of spl locks - one for each priority level. */ *************** *** 652,657 **** --- 722,728 ---- pk->k_ipl = -1; } + #endif /* From Lite kern_synch.c. Does nothing useful now. */ /* *** ../lites-1/emulator/ns532/e_trampoline.c Wed Sep 28 22:25:49 1994 --- emulator/ns532/e_trampoline.c Mon Oct 24 09:30:51 1994 *************** *** 27,32 **** --- 27,38 ---- */ /* * HISTORY + * 24-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added support for 8 argument system calls. + * + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Detect 4.4 indirect syscall. + * * 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Increased emul_high_entry to 210 to cope with 4.4 system calls. * *************** *** 253,263 **** } #endif /* MAP_UAREA && COMPAT_43 */ ! if (syscode == 0) { ! /* ! * Indirect system call. ! */ ! syscode = *args++; } /* --- 259,278 ---- } #endif /* MAP_UAREA && COMPAT_43 */ ! /* ! * Check for indirect system call. ! */ ! switch (syscode) { ! case 0 /* SYS_syscall */: ! syscode = *args++; ! break; ! case 198 /* SYS___syscall */: ! /* code is a quad argument with the high order bits 0. ! * Endian dependent XXX ! */ ! syscode = *args; ! args += 2; ! break; } /* *************** *** 286,294 **** } if (syscall_debug > 2) ! e_emulator_error("emul_syscall[%d] %s(x%x, x%x, x%x, x%x, x%x)", syscode, callp->name, args[0], args[1], args[2], ! args[3], args[4]); /* * Set up the initial return values. */ --- 301,309 ---- } if (syscall_debug > 2) ! e_emulator_error("emul_syscall[%d] %s(x%x, x%x, x%x, x%x, x%x, x%x, x%x, x%x)", syscode, callp->name, args[0], args[1], args[2], ! args[3], args[4], args[5], args[6], args[7]); /* * Set up the initial return values. */ *************** *** 336,341 **** --- 351,364 ---- error = (*callp->routine)( args[0], args[1], args[2], args[3], args[4], args[5], args[6], + rval); + break; + + case 8: + error = (*callp->routine)( + args[0], args[1], args[2], + args[3], args[4], args[5], args[6], + args[7], rval); break; *** ../lites-1/emulator/ns532/e_lite_sysent.c Wed Sep 28 21:50:23 1994 --- emulator/ns532/e_lite_sysent.c Sun Oct 23 15:27:04 1994 *************** *** 82,88 **** int e_lite_stat(), e_lite_fstat(), e_lite_lstat(), e_lite_lseek(); int e_lite_truncate(), e_lite_ftruncate(), e_lite_getrlimit(); int e_lite_setrlimit(), e_lite_getdirentries(); ! int e_lite_wait4(), e_mmap(); struct sysent e_bsd_sysent[] = { SYS_NULL(e_indir), /* 0 */ --- 82,88 ---- int e_lite_stat(), e_lite_fstat(), e_lite_lstat(), e_lite_lseek(); int e_lite_truncate(), e_lite_ftruncate(), e_lite_getrlimit(); int e_lite_setrlimit(), e_lite_getdirentries(); ! int e_lite_wait4(), e_lite_mmap(); struct sysent e_bsd_sysent[] = { SYS_NULL(e_indir), /* 0 */ *************** *** 289,295 **** sysg(e_lite_getrlimit, 2), /* 194 */ sysg(e_lite_setrlimit, 2), /* 195 */ sysg(e_lite_getdirentries, 4), /* 196 */ ! sysg(e_mmap, 8), /* 197 */ sysg(e_nosys, 0), /* 198 */ sysg(e_lite_lseek, 5), /* 199 */ sysg(e_lite_truncate, 4), /* 200 */ --- 289,295 ---- sysg(e_lite_getrlimit, 2), /* 194 */ sysg(e_lite_setrlimit, 2), /* 195 */ sysg(e_lite_getdirentries, 4), /* 196 */ ! sysg(e_lite_mmap, 8), /* 197 */ sysg(e_nosys, 0), /* 198 */ sysg(e_lite_lseek, 5), /* 199 */ sysg(e_lite_truncate, 4), /* 200 */ *** ../lites-1/emulator/e_bsd_stubs.c Tue Oct 4 02:18:33 1994 --- emulator/e_bsd_stubs.c Sun Oct 23 15:56:53 1994 *************** *** 27,32 **** --- 27,42 ---- */ /* * HISTORY + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added e_lite_mmap with slightly different arguments. + * + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Kludge to handle netbsd mount which gives us a string instead of + * an integer as a filesystem type. + * + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added "pad" tp lseek arguments. offset is quad word aligned. + * * 04-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) * Kludge to use MOUNT_UFS if mount type is unknown. * *************** *** 43,48 **** --- 53,59 ---- #include #include + #include /* GLOBALS */ mode_t saved_umask = 022; *************** *** 588,594 **** return err; } ! errno_t e_lite_lseek(int fd, off_t offset, int sbase, off_t *pos) { errno_t err; kern_return_t kr; --- 599,605 ---- return err; } ! errno_t e_lite_lseek(int fd, int pad, off_t offset, int sbase, off_t *pos) { errno_t err; kern_return_t kr; *************** *** 887,893 **** errno_t err; kern_return_t kr; int intr, rv[2]; - struct { int type; const char *dir; --- 898,903 ---- *************** *** 894,912 **** int flags; caddr_t data; } a; a.data = data; a.flags = flags; a.dir = dir; a.type = type; - /* Kludge alert. The netbsd mount binary seems to give us garbage - * in the type field - */ - if (type < 0 || type > 15) { - a.type = 1; /* MOUNT_UFS */ - e_emulator_error("e_mount: type %d unknown, assuming ufs\n", type); - } - kr = emul_generic(process_self(), &intr, SYS_mount, &a, &rv); err = kr ? e_mach_error_to_errno(kr) : 0; return err; --- 904,927 ---- int flags; caddr_t data; } a; + + /* Kludge alert. The netbsd mount command gives us a string + * in the type field + */ + if (type < 0 || type > MOUNT_MAXTYPE) { + int i; + const char *mountnames[] = INITMOUNTNAMES; + for (i = 0; i <= MOUNT_MAXTYPE; i++) + if(strcmp((char *) type, mountnames[i]) == 0) { + type = i; + break; + } + } a.data = data; a.flags = flags; a.dir = dir; a.type = type; kr = emul_generic(process_self(), &intr, SYS_mount, &a, &rv); err = kr ? e_mach_error_to_errno(kr) : 0; return err; *************** *** 1752,1757 **** --- 1767,1786 ---- return err; } + /* Open fd as port and map it. Later cache the fd->port mapping */ + errno_t e_lite_mmap( + caddr_t bsd_addr, + size_t len, + int bsd_prot, + int flags, + int fd, + int pad, + off_t offset, + caddr_t *addr_out) + { + return e_mmap(bsd_addr, len, bsd_prot, flags, fd, (vm_offset_t) offset, + addr_out); + } /* Open fd as port and map it. Later cache the fd->port mapping */ errno_t e_mmap( caddr_t bsd_addr, *** ../../../hut/src/lites/emulator/e_bnr_stubs.c Tue Jun 28 12:14:25 1994 --- emulator/e_bnr_stubs.c Sun Oct 23 01:19:33 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added "pad" to e_lite_lseek arguments. + * * $Log: $ * */ *************** *** 55,62 **** { off_t tmp_pos; errno_t err; ! err = e_lite_lseek(fd, (off_t) offset, sbase, &tmp_pos); if (!err && pos) *pos = tmp_pos; return err; --- 58,66 ---- { off_t tmp_pos; errno_t err; + int pad; ! err = e_lite_lseek(fd, pad, (off_t) offset, sbase, &tmp_pos); if (!err && pos) *pos = tmp_pos; return err; From DALL@HFRD.DSTO.GOV.AU Sun Oct 23 22:32:24 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 24 Oct 1994 06:20:16 +0200 13:49:50 +0930 Date: Mon, 24 Oct 94 13:51:37 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: Problem with spl lock not held X-Hfrd: 1994102413503709 I occasionally get panics due to spl calling mutex_unlock when the lock isn't held. The slightly modified mutex_unlock lites uses checks for this and panics. The call to spl_n which causes the problem seems to come from the nfs code. It most often happens just as the system goes multi-user. If it gets as far as a multi-user login prompt, you seem to be fairly safe, but then I am not actually using nfs for anything. Maybe if I were, this bug might manifest its self more often. Ian From jvh@cs.hut.fi Mon Oct 24 18:10:19 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 25 Oct 1994 01:56:03 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 25 Oct 1994 01:52:04 +0200 Date: Tue, 25 Oct 1994 01:52:04 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Recent changes In-Reply-To: <9410232342.AA09404@hfrd.dsto.gov.au> References: <9410232342.AA09404@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > + #if SIMPLE_SPL > + /* This is not a complete emulation of spl, but it should > + * be sufficient. Missing is the code to simulate the > + * software interrupts The software interrupts should not be needed if you enable ETHER_AS_SYSCALL (a slightly badly choden option name). This makes the network input thread run the protocol stack directly without any additional queueing. interrupt_enter() should then simply take the single spl mutex. The problem I had with this somewhat experimental code was that inetd's first select would not wake up. Why this happens I wasn't able to figure out but I suspect a race in the socket code. There was two purposes in the direct protocol processing: 1) decreasing latency in network traffic. 2) decouple the network from the spl mechanism. The latter is one step towards eliminating spls. Replacing them with a single mutex is another. Johannes From jvh@cs.hut.fi Tue Oct 25 04:36:10 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 25 Oct 1994 12:20:48 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 25 Oct 1994 12:20:47 +0200 Date: Tue, 25 Oct 1994 12:20:47 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Re: why mach_init hangs for 60 seconds In-Reply-To: <9410180508.AA17656@cs.utah.edu> References: <9410180508.AA17656@cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Mike Hibler wrote: > Here is what causes it on the PA anyway. pause() is implemented as: > > sigpause(sigblock(0L)); > > which is "reasonably atomic" on a uniprocessor, monolithic BSD system. Avoiding this race must clearly be one of the reasons why the signal interfaces were changed. I had totally forgotten but I fixed my copy of mach_init to not have this race. sigblock(sigmask(SIGTERM) | sigmask(SIGALRM)); alarm(60); if (!signalled) sigpause(0); sigblock(0); Now this should work but I'm not sure as I've probably been using old versions of the binary. Fixing the source is not enough :-). If you are distributing mach_init and it does not have my history entries from July and January 1994 please pick the diff below up: Johannes --- latest/src/user/etc/mach_init/main.c Sat Aug 31 22:53:20 1991 +++ work/src/user/etc/mach_init/main.c Fri Jul 1 07:46:49 1994 @@ -23,8 +23,19 @@ * any improvements or extensions that they make and grant Carnegie the * rights to redistribute these changes. */ -/* +/* * HISTORY + * 01-Jul-94 Johannes Helander (jvh) at Helsinki University of Technology + * Made 'signalled' volatile. + * Added sigblock around sigpause to avoid the race that + * sometimes caused an annoying one minute delay. + * Changed pause to sigpause. + * + * 22-Jan-94 Johannes Helander (jvh) at Helsinki University of Technology + * Primarily try to exec /sbin/init. Only if that fails run + * /etc/init. But if that fails as well, try running /bin/sh on the + * console. + * * $Log: main.c,v $ * Revision 2.5 91/08/29 15:50:26 rpd * Changed -n mode so that mach_init doesn't background itself. @@ -97,6 +108,7 @@ #include #include #include +#include #include extern int errno; @@ -111,7 +123,7 @@ char *program_name; -boolean_t signalled = FALSE; +volatile boolean_t signalled = FALSE; #ifdef DEBUG boolean_t debug = TRUE; @@ -197,9 +209,12 @@ if (fork()) { cthread_fork_parent(); + sigblock(sigmask(SIGTERM) | sigmask(SIGALRM)); alarm(60); if (!signalled) - pause(); + sigpause(0); + sigblock(0); + if (debug) printf("Parent terminating.\n"); @@ -208,11 +223,24 @@ if (argv[0] != NULL) argv[0] = "init"; + execve("/sbin/init", argv, envp); + /* Probably didn't exist. try /etc/init instead */ execve("/etc/init", argv, envp); if (verbose) fprintf(error_stream(), - "%s: exec /etc/init failed\n"); + "%s: exec /sbin/init and /etc/init failed trying /bin/sh\n"); + /* + * As a last resort try to run /bin/sh with + * /dev/console as stdin, stdout, and stderr + */ + close(0); + close(1); + close(2); + open("/dev/console", O_RDWR | O_NDELAY, 0); + dup(0); + dup(0); + execve("bin/sh", argv, envp); return(errno); } cthread_fork_child(); From jvh@cs.hut.fi Tue Oct 25 04:54:28 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 25 Oct 1994 12:44:43 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 25 Oct 1994 12:44:42 +0200 Date: Tue, 25 Oct 1994 12:44:42 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: New snapshot and status update Organization: Helsinki University of Technology, CS Lab. A new LITES snapshot is available as leia.cs.hut.fi:foggy/lites/LITES.941025.tar.gz This is not necessarily very stable and might change soon. It has the following changes: - PC532 support from Ian Dall. - I merged in most PA changes to MI files from Mike Hibler and probably broke half of them. - Support for loading emulators linked by NetBSD, FreeBSD, and Linux linkers (untested and probably broken) by me. - Some copyrights fixed by Mary Thompson and me. - Profiling support from Ian. - Various bugfixes. - Support for 4.4 binaries. - UX binaries don't use mapped time anymore for now as the i386 kernel's pmap module is broken and panics the kernel. I tested that it boots on the i386 and runs a couple of different kinds of emacses. The build environment is ODE. This is likely to change soon. Chris Maeda has written BSD makefiles. Bryan Ford and I have written GNU makefiles. Who said make is well standardized? Personally I don't care what the make system is as long as it makes people happy. Maintaining three different kinds, however, doesn't seem feasible in the long run. Johannes From jvh@cs.hut.fi Tue Oct 25 13:24:53 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 25 Oct 1994 21:11:40 +0200 (5.65c8/HUTCS-C 1.3 for lites); Tue, 25 Oct 1994 21:11:39 +0200 Date: Tue, 25 Oct 1994 21:11:39 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Linux Doom works Organization: Helsinki University of Technology, CS Lab. I've just found out that for Linux compat a sound driver in addition to the file system is needed. Doom works but is somewhat slow and doesn't produce an infernal noice as it's supposed to. Johannes From jvh@cs.hut.fi Wed Oct 26 22:18:14 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 27 Oct 1994 06:12:01 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 27 Oct 1994 06:11:57 +0200 Date: Thu, 27 Oct 1994 06:11:57 +0200 From: Johannes Helander To: mach4-users@cs Cc: lites@cs.hut.fi Subject: Re: Things to do, places to go In-Reply-To: <199410261657.KAA06949@schirf.cs.utah.edu> References: <9410260133.AA12484@Trantor.DSO.gov.SG> <199410261657.KAA06949@schirf.cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. > >But, I can > >alway get another machine just for this. The problem is - is Lites really > >readied for big time? The last time I tried (from mach.cs.cmu.edu for > >NetBSD) it wouldn't run. My guess was that the filesystem codes in Lites > >if for the new BSD filesystem while the filesystem of NetBSD0.9 was the old > >version. So the Lites server couldn't load init and hence no go. > > Johannes Helander (or someone else with more direct LITES experience) > really should answer this one. However, LITES is supposed to work best with > NetBSD-0.9 (as opposed to NetBSD-current or FreeBSD); the problem you're > encountering could be something else. We have LITES running on a few > NetBSD-0.9 machines here, and it seems to work great. LITES would need merging of FreeBSD and/or NetBSD bugfixes. Also it has bugs of its own. So when will it be stable enough for real use? That depends on how soon bugs get fixed and what kind of stability is required. (Not a very good answer, I admit :-). As for compatibility. Yes current XBSD-current binaries might not work. This is because the binaries have changed since I wrote the support code. I wrote some code for supporting new 4.4 system calls but didn't enable it at the time as it was untested and impossible to test. In the 941025 snapshot there is more some code for this and it is enabled but it is still untested. One reason is that I don't have a current XBSD-current currently running on any machine. The other issue is linker incompatibility. The emulator loads binaries that are not LITES-native. Currently the only native binary is the emulator itself. I assumed that it is of a known format and put in code for loading only that. However, if you link with a different linker than what I used (CMU UX ZMAGIC) it looks different. I added some code to take care of this (load qmagic emulators produced by FreeBSD or Linux (with -qmagic), ZMAGIC by UX, NetBSD a.out, and SOM. I didn't test this either except for that it still loads my emulator but I'll take care of this when changing the build environment (coordination between linker flags and the exec code is needed). The BSD file system should be compatible. I've seen problems with 4.3 BSD file systems but I guess that merging in XBSD fixes would take care of most ufs and nfs problems. The code is now almost exact 4.4Lite with some changes caused by the split of struct proc and the configuration system (options come from files instead of the command line). After having a Linux file system, changing the build environment, and a few rounds of testing there should be no problems in building or booting on BSD or Linux. Slight incompatibility will remain: Xserver -- only the Mach version works. Others need virtual consoles or similar interfaces that are unimplemented. route, mount* -- these have to be the 4.4 BSD versions. w, ps, top -- LITES specific (the UX versions almost work). gdb -- Mach specific. Versions using ptrace could be made to work but they would still not be able to debug multithreaded programs etc. so I don't think providing ptrace would gain much. There might be more /sbin programs that don't work from Linux. In this case the BSD programs should work. I don't think that some /sbin programs being incompatible is very serious. At least the benefit/work ratio is very low. Johannes From DALL@HFRD.DSTO.GOV.AU Tue Nov 1 17:18:11 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 2 Nov 1994 02:07:49 +0200 10:36:57 +1030 Date: Wed, 2 Nov 94 10:38:08 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: Problems w current snap shot for ns32k. X-Hfrd: 1994110210355168 The main thing is that make picks up emulator/emul_exec.c in preference to emulator/ns532/emul_exec.c. I think emul_exec.c should be machine dependent anyway. Even the "standard" executeable formats have different magic numbers for each machine type. The code to check for the netbsd magic number includes the machine type field but masks off the flags field so where for the i386 you have 0xb018600, for the ns532 it should be 0xb01b900. One could mask off the machine type as well, but if I happen to have a i386 executeable on my disk I don't really want the system to try and execute it. It would be possible to do this with machine dependent macros N_MAGIC or whatever, but the problem is that when you are dealing with so many different variants, you are bound to end up with clashes if you just try and include all the relevent exec.h or whatever. An alternative is to have a whole stack of #ifdef machine_type code, but that gets ugly. The simplest solution is to just have machine dependent functions to do this stuff, especially since there is no reason for a non 386 port to know anything about linux, isc, freebsd but it might want to know about hpux, sunos, ultrix etc. The same problem arises in server_exec.c. Possibly, rather than make all of emul_exec.c machine dependent, it would be worth trying to isolate the machine dependent bits of it. Other changes: doc/FILES: I made entries into this, but it doesn't seem to have been maintained. Do you intend to maintain it? I won't include the diffs here. e_mmap is wrong for 4.4 and netbsd. There needs to be padding to align the off_t arguments on an 8 byte boundary. I made e_lite_mmap, but the sysent table hadn't been changed to use it. More importantly, the e_trampoline code needs an extra case for 8 argument syscalls. Also 4.4 has an extra indirect system call 198. This is different in so far as there is padding to put the first argument on an 8 byte boundary. Netbsd relies on this indirect system call for some reason to do lseek instead of doing lseek directly. The copyright seems to have gone missing from server/conf/files. Is this intentional? Use "static inline" instead of "extern inline". According to my reading of the gcc docs, the latter won't work when compiling -O0 and the two cases are identical when compiling with higher optimization levels. "extern inline" seems to be more appropriate when there is a libarary version of the function to fall back on. Moved get_binary_type() to server/ns532/server/serv_machdep.c from server/serv/server_exec.c. This would have to be done for the other machine types as well. There is some untidyness in so far as some types (binary_type_t, union exec_data) are defined in more than one place. I ran into a tricky problem recompiling MK. Lites puts its own types.h into the export area which gets picked up when makeboot is compiled. This results in lseek being called with the wrong arguments if makeboot is run on an old unix (ux in my case, but would occur for anyone cross compiling from an older unix) I needed to be able to redefine off_t in HOST_CFLAGS. OK. So here are the changes I made: mv emul_exec.c i386/emul_exec.c Diffs for the other changes follow. Ian *** ../../../hut/src/lites/./emulator/Makefile Tue Oct 25 12:34:35 1994 --- ./emulator/Makefile Tue Nov 1 21:58:12 1994 *************** *** 27,32 **** --- 27,35 ---- # # # HISTORY + # 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + # Remove linux and isc files for ns532 case. + # # 25-Oct-94 Johannes Helander (jvh) at Helsinki University of Technology # Merged in PA RISC support from Mike Hibler and PC532 support from # Ian Dall. *************** *** 104,111 **** i386_EMULATOR_OFILES = e_linux_sysent.o e_linux_trampoline.o \ e_isc4_sysent.o e_sysv_stubs.o e_cmu_43ux_sysent.o e_lite_sysent.o ! ns532_EMULATOR_OFILES = e_linux_sysent.o e_linux_trampoline.o \ ! e_isc4_sysent.o e_sysv_stubs.o e_cmu_43ux_sysent.o e_lite_sysent.o \ memcmp.o parisc_EMULATOR_OFILES = e_hpbsd_sysent.o e_hpbsd_stubs.o --- 107,113 ---- i386_EMULATOR_OFILES = e_linux_sysent.o e_linux_trampoline.o \ e_isc4_sysent.o e_sysv_stubs.o e_cmu_43ux_sysent.o e_lite_sysent.o ! ns532_EMULATOR_OFILES = e_cmu_43ux_sysent.o e_lite_sysent.o \ memcmp.o parisc_EMULATOR_OFILES = e_hpbsd_sysent.o e_hpbsd_stubs.o *** ../../../hut/src/lites/./emulator/e_bsd_stubs.c Tue Oct 25 20:16:09 1994 --- ./emulator/e_bsd_stubs.c Tue Nov 1 21:14:55 1994 *************** *** 28,33 **** --- 28,36 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * e_mount(): handle string filesystem types before setting a.type. + * * 25-Oct-94 Johannes Helander (jvh) at Helsinki University of Technology * Word order fix in e_lite_lseek and sigprocmask fixes. * From Mike Hibler . *************** *** 905,914 **** int flags; caddr_t data; } a; - a.data = data; - a.flags = flags; - a.dir = dir; - a.type = type; /* Kludge alert. The netbsd mount command gives us a string * in the type field --- 908,913 ---- *************** *** 922,927 **** --- 921,931 ---- break; } } + + a.data = data; + a.flags = flags; + a.dir = dir; + a.type = type; kr = emul_generic(process_self(), &intr, SYS_mount, &a, &rv); err = kr ? e_mach_error_to_errno(kr) : 0; *** ../../../hut/src/lites/./emulator/ns532/e_lite_sysent.c Tue Oct 25 20:07:48 1994 --- ./emulator/ns532/e_lite_sysent.c Tue Nov 1 21:58:11 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Use e_lite_mmap instead of e_mmap. + * * 26-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Add lite versions of lseek, truncate, ftruncate, stat, fstat, * lstat, getrlimit, setrlimit and get_direntries. *************** *** 82,88 **** int e_lite_stat(), e_lite_fstat(), e_lite_lstat(), e_lite_lseek(); int e_lite_truncate(), e_lite_ftruncate(), e_lite_getrlimit(); int e_lite_setrlimit(), e_lite_getdirentries(); ! int e_lite_wait4(), e_mmap(); struct sysent e_bsd_sysent[] = { SYS_NULL(e_indir), /* 0 */ --- 85,91 ---- int e_lite_stat(), e_lite_fstat(), e_lite_lstat(), e_lite_lseek(); int e_lite_truncate(), e_lite_ftruncate(), e_lite_getrlimit(); int e_lite_setrlimit(), e_lite_getdirentries(); ! int e_lite_wait4(), e_lite_mmap(); struct sysent e_bsd_sysent[] = { SYS_NULL(e_indir), /* 0 */ *************** *** 289,295 **** sysg(e_lite_getrlimit, 2), /* 194 */ sysg(e_lite_setrlimit, 2), /* 195 */ sysg(e_lite_getdirentries, 4), /* 196 */ ! sysg(e_mmap, 8), /* 197 */ sysg(e_nosys, 0), /* 198 */ sysg(e_lite_lseek, 5), /* 199 */ sysg(e_lite_truncate, 4), /* 200 */ --- 292,298 ---- sysg(e_lite_getrlimit, 2), /* 194 */ sysg(e_lite_setrlimit, 2), /* 195 */ sysg(e_lite_getdirentries, 4), /* 196 */ ! sysg(e_lite_mmap, 8), /* 197 */ sysg(e_nosys, 0), /* 198 */ sysg(e_lite_lseek, 5), /* 199 */ sysg(e_lite_truncate, 4), /* 200 */ *** ../../../hut/src/lites/./emulator/ns532/e_trampoline.c Wed Sep 28 22:25:49 1994 --- ./emulator/ns532/e_trampoline.c Tue Nov 1 21:58:10 1994 *************** *** 27,32 **** --- 27,41 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Remove code for isc4 support. + * + * 24-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Added support for 8 argument system calls. + * + * 23-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Detect 4.4 indirect syscall. + * * 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Increased emul_high_entry to 210 to cope with 4.4 system calls. * *************** *** 97,106 **** current_nsysent = e_cmu_43ux_nsysent; current_sysent = e_cmu_43ux_sysent; break; - case BT_ISC4: - current_nsysent = e_isc4_nsysent; - current_sysent = e_isc4_sysent; - break; case BT_386BSD: case BT_OLD_EMULATOR: case BT_NETBSD_09: --- 106,111 ---- *************** *** 253,263 **** } #endif /* MAP_UAREA && COMPAT_43 */ ! if (syscode == 0) { ! /* ! * Indirect system call. ! */ ! syscode = *args++; } /* --- 258,277 ---- } #endif /* MAP_UAREA && COMPAT_43 */ ! /* ! * Check for indirect system call. ! */ ! switch (syscode) { ! case 0 /* SYS_syscall */: ! syscode = *args++; ! break; ! case 198 /* SYS___syscall */: ! /* code is a quad argument with the high order bits 0. ! * Endian dependent XXX ! */ ! syscode = *args; ! args += 2; ! break; } /* *************** *** 286,294 **** } if (syscall_debug > 2) ! e_emulator_error("emul_syscall[%d] %s(x%x, x%x, x%x, x%x, x%x)", syscode, callp->name, args[0], args[1], args[2], ! args[3], args[4]); /* * Set up the initial return values. */ --- 300,308 ---- } if (syscall_debug > 2) ! e_emulator_error("emul_syscall[%d] %s(x%x, x%x, x%x, x%x, x%x, x%x, x%x, x%x)", syscode, callp->name, args[0], args[1], args[2], ! args[3], args[4], args[5], args[6], args[7]); /* * Set up the initial return values. */ *************** *** 336,341 **** --- 350,363 ---- error = (*callp->routine)( args[0], args[1], args[2], args[3], args[4], args[5], args[6], + rval); + break; + + case 8: + error = (*callp->routine)( + args[0], args[1], args[2], + args[3], args[4], args[5], args[6], + args[7], rval); break; *** ../../../hut/src/lites/./emulator/ns532/emul_exec.c Wed Sep 28 20:48:31 1994 --- ./emulator/ns532/emul_exec.c Sun Oct 30 23:55:19 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 30-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Removed linux code. + * * 27-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Make obreak less susceptible to integer overflows. * *************** *** 82,93 **** * Set up the emulator vectors. */ switch (binary_type) { - case BT_LINUX: - case BT_LINUX_O: - case BT_LINUX_SHLIB: - /* Linux uses a nonstandard system call calling convention */ - e_linux_setup(mach_task_self(), binary_type); - break; default: emul_setup(mach_task_self(), binary_type); break; --- 85,90 ---- *************** *** 101,113 **** /* And start running it */ switch (binary_type) { - case BT_LINUX: - case BT_LINUX_O: - case BT_LINUX_SHLIB: - err = emul_exec_linux_start(kframe, binary_type, - argc, argv, envp, - entry_point); - break; default: err = emul_exec_start(kframe, binary_type, argc, argv, envp, --- 98,103 ---- *** ../../../hut/src/lites/./server/conf/MASTER Tue Jun 28 12:49:43 1994 --- ./server/conf/MASTER Fri Oct 7 23:42:36 1994 *************** *** 28,33 **** --- 28,36 ---- # # # HISTORY + # 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) + # Dropped gprof from DEBUG. Debugging and profiling are orthogonal. + # # $Log: $ # *************** *** 82,88 **** # Everything that is known to work # LARGE = [ STD ] # ! # DEBUG = [ debug machid_register lineno gprof diagnostic assertions queue_assertions ] # # Compiles but untested. # UNTESTED = [ mfs umapfs union fdesc cd9660 portal lfs sl ns nsip lfs quota gateway mrouting ] --- 85,91 ---- # Everything that is known to work # LARGE = [ STD ] # ! # DEBUG = [ debug machid_register lineno diagnostic assertions queue_assertions ] # # Compiles but untested. # UNTESTED = [ mfs umapfs union fdesc cd9660 portal lfs sl ns nsip lfs quota gateway mrouting ] *************** *** 169,174 **** --- 172,178 ---- makevariables LINENO="-g" # makevariables MASTER_DEFINES="-DMACH_IPC_COMPAT=0" + makevariables CC_OPT_EXTRA="-g -Dregister= -O0" # # # Ethernet (ARP) # *** ../../../hut/src/lites/./server/conf/files Tue Oct 25 19:04:13 1994 --- ./server/conf/files Sat Oct 29 22:59:37 1994 *************** *** 1,4 **** ! OPTIONS/map_uarea optional map_uarea OPTIONS/second_server optional second_server OPTIONS/machid_register optional machid_register --- 1,52 ---- ! # ! # Mach Operating System ! # Copyright (c) 1994 Helsinki University of Technology ! # All Rights Reserved. ! # ! # Permission to use, copy, modify and distribute this software and its ! # documentation is hereby granted, provided that both the copyright ! # notice and this permission notice appear in all copies of the ! # software, derivative works or modified versions, and any portions ! # thereof, and that both notices appear in supporting documentation. ! # ! # HELSINKI UNIVERSITY OF TECHNOLOGY ALLOWS FREE USE OF THIS SOFTWARE ! # IN ITS 'AS IS' CONDITION. HELSINKI UNIVERSITY OF TECHNOLOGY ! # DISCLAIMS ANY LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER ! # RESULTING FROM THE USE OF THIS SOFTWARE. ! # ! # Helsinki University of Technology requests users of this software ! # to return to ! # ! # Software Distribution Coordinator or Software.Distribution@cs.hut.fi ! # Department of Computer Science ! # Helsinki University of Technology ! # FI-02150 Espoo, Finland ! # ! # any improvements or extensions that they make and grant Helsinki ! # University of Technology the rights to redistribute these changes. ! # ! # ! # HISTORY ! # 06-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) ! # Added tape_io.c. ! # ! # 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) ! # Added libkern/bcmp.c and libkern/mach_error.c. ! # ! # 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) ! # Remove gprof_support.c. We should use the support in libprof1. ! # ! # 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) ! # Added copyright notice etc. ! # ! # $Log: $ ! # ! # File: conf/files ! # Author: Johannes Helander ! # Date: May 1994 ! # ! # ! # OPTIONS/map_uarea optional map_uarea OPTIONS/second_server optional second_server OPTIONS/machid_register optional machid_register *************** *** 363,366 **** --- 411,415 ---- # Library support libkern/scanc.c standard libkern/skpc.c standard + libkern/bcmp.c standard libkern/mach_error.c standard *** ../../../hut/src/lites/./server/kern/uipc_mbuf.c Fri Jul 1 05:49:58 1994 --- ./server/kern/uipc_mbuf.c Tue Nov 1 21:58:09 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Use "register int" instead of just "register". + * * $Log: $ * */ *************** *** 379,385 **** { register int len = req_len; register struct mbuf *m; ! register count; if ((m = mp) == NULL) return; --- 382,388 ---- { register int len = req_len; register struct mbuf *m; ! register int count; if ((m = mp) == NULL) return; *** ../../../hut/src/lites/./server/kern/vnode_if.sh Sat May 14 06:43:11 1994 --- ./server/kern/vnode_if.sh Tue Nov 1 21:58:07 1994 *************** *** 33,38 **** --- 33,45 ---- # # @(#)vnode_if.sh 8.1 (Berkeley) 6/10/93 # + # HISTORY + # 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + # Use "static inline" instead of "extern inline". The latter won't work + # when compiling -O0 and the two cases are identical when compiling with + # higher optimization levels. + # + # # Script to produce VFS front-end sugar. # *************** *** 113,119 **** printf("extern struct vnodeop_desc %s_desc;\n", name); # Print out inline struct. ! printf("extern inline int %s(", uname); sep = ", "; for (c2 = 0; c2 < c1; ++c2) { if (c2 == c1 - 1) --- 120,126 ---- printf("extern struct vnodeop_desc %s_desc;\n", name); # Print out inline struct. ! printf("static inline int %s(", uname); sep = ", "; for (c2 = 0; c2 < c1; ++c2) { if (c2 == c1 - 1) *************** *** 347,353 **** struct buf *a_bp; }; extern struct vnodeop_desc vop_strategy_desc; ! extern inline int VOP_STRATEGY(bp) struct buf *bp; { struct vop_strategy_args a; --- 354,360 ---- struct buf *a_bp; }; extern struct vnodeop_desc vop_strategy_desc; ! static inline int VOP_STRATEGY(bp) struct buf *bp; { struct vop_strategy_args a; *************** *** 362,368 **** struct buf *a_bp; }; extern struct vnodeop_desc vop_bwrite_desc; ! extern inline int VOP_BWRITE(bp) struct buf *bp; { struct vop_bwrite_args a; --- 369,375 ---- struct buf *a_bp; }; extern struct vnodeop_desc vop_bwrite_desc; ! static inline int VOP_BWRITE(bp) struct buf *bp; { struct vop_bwrite_args a; *** ../../../hut/src/lites/./server/ns532/server/serv_machdep.c Thu Sep 29 23:28:10 1994 --- ./server/ns532/server/serv_machdep.c Tue Nov 1 21:58:08 1994 *************** *** 28,33 **** --- 28,37 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Move get_binary_type() here from server/serv/server_exec.c since + * it is machine dependant. + * * 29-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Take code to reserve page 0 out of emul_init. There is now a MI * server_reserve_page0. *************** *** 89,94 **** --- 93,100 ---- #include #include #include + #include + #include #include /* boothowto */ #include #include *************** *** 313,315 **** --- 319,382 ---- #endif } + union exec_data { + unsigned short short_magic; + unsigned magic; + struct exec aout; + struct exechdr coff; + struct som_exechdr som; + char shell[MAXINTERP];/* #! and interpreter name */ + }; + + typedef enum binary_type { + BT_BAD, BT_LITES_Z, BT_LITES_Q, BT_LITES_SOM, + BT_386BSD, BT_NETBSD_09, BT_FREEBSD, BT_CMU_43UX, + BT_SCRIPT, BT_ISC4, BT_LINUX, BT_LINUX_SHLIB, BT_LINUX_O + } binary_type_t; + + binary_type_t get_binary_type( + union exec_data *hdr) + { + #ifdef NOT_FOR_NS32K + /********* First check for LITES binary *************/ + if ((hdr->magic == 0x03200107 || hdr->magic == 0x020b0107) + && (unsigned)hdr->som.ahdr.entry >= 0x10000000) + return BT_LITES_SOM; + + /* Linked by FreeBSD or NetBSD linker or Linux with -qmagic */ + if ((hdr->short_magic == QMAGIC || hdr->magic == 0xb018900) + && hdr->aout.a_entry >= 0x10000000) + return BT_LITES_Q; + #endif + /* UX linker */ + if (hdr->short_magic == ZMAGIC && hdr->aout.a_entry >= 0x10000000) + return BT_LITES_Z; + + + /********* Not a LITES binary *************/ + + /* + * NetBSD tried to make the magic number byte order + * independent but got it the wrong way. + */ + if ((hdr->magic & ~0xfc) == 0x0b018900) + return BT_NETBSD_09; + if (hdr->short_magic == ZMAGIC) { + switch ((hdr->magic >> 16) & 0xff) /* machine id */ + { + case 0x45: /* gnu ld 2.3 */ + case 0: + if (hdr->aout.a_entry) { + return BT_CMU_43UX; + } else { + return BT_BAD; + } + break; + default: + return BT_BAD; + } + } + if (hdr->shell[0] == '#' && hdr->shell[1] == '!') + return BT_SCRIPT; + return BT_BAD; + } *** ../../../hut/src/lites/./server/serv/import_mach.h Wed Jun 29 07:59:52 1994 --- ./server/serv/import_mach.h Tue Nov 1 21:58:06 1994 *************** *** 28,33 **** --- 28,38 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Use "static inline" instead of "extern inline". The latter won`t + * work when compiling -O0 and the two cases are identical when + * compiling with higher optimization levels. + * * $Log: $ */ /* *************** *** 70,76 **** void panic(const char *, ...); #undef mutex_try_lock ! extern inline boolean_t mutex_try_lock(mutex_t m) { if (spin_try_lock(&m->held)) { assert(m->holder == 0); --- 75,81 ---- void panic(const char *, ...); #undef mutex_try_lock ! static inline boolean_t mutex_try_lock(mutex_t m) { if (spin_try_lock(&m->held)) { assert(m->holder == 0); *** ../../../hut/src/lites/./server/serv/server_exec.c Tue Oct 25 18:02:24 1994 --- ./server/serv/server_exec.c Tue Nov 1 21:58:05 1994 *************** *** 27,32 **** --- 27,39 ---- */ /* * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Move get_binary_type() to machine dependent file. + * + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Add server_reserve_page0() function. Use it in + * server_exec_cleanup_task() and server_exec_create_new_task(). + * * $Log: $ * */ *************** *** 297,302 **** --- 304,326 ---- return KERN_SUCCESS; } + mach_error_t server_reserve_page0(struct proc *p) + { + vm_address_t addr = 0; + kern_return_t kr; + kr = vm_allocate(p->p_task, &addr, vm_page_size, FALSE); + if (kr != KERN_SUCCESS) { + printf("server_reserve_page0: vm_allocate page 0: %s", + mach_error_string(kr)); + } + kr = vm_protect(p->p_task, 0, vm_page_size, TRUE, VM_PROT_NONE); + if (kr != KERN_SUCCESS) { + printf("server_reserve_page0: vm_protect page 0: %s", + mach_error_string(kr)); + } + return kr; + } + /* * Cleanup task for exec. Empty its address space and leave just on * thread around. *************** *** 338,343 **** --- 362,369 ---- kr = vm_deallocate(p->p_task, VM_MIN_ADDRESS, VM_MAX_ADDRESS - VM_MIN_ADDRESS); assert(kr == KERN_SUCCESS); + kr = server_reserve_page0(p); + assert(kr == KERN_SUCCESS); #if MAP_UAREA /* Remap shared window */ kr = mapin_user(p); *************** *** 407,412 **** --- 433,439 ---- /* Remap shared window */ kr = mapin_user(p); #endif + (void) server_reserve_page0(p); return KERN_SUCCESS; } *************** *** 707,779 **** else *vnp = vn; return err; - } - - binary_type_t get_binary_type( - union exec_data *hdr) - { - /********* First check for LITES binary *************/ - if ((hdr->magic == 0x03200107 || hdr->magic == 0x020b0107) - && (unsigned)hdr->som.ahdr.entry >= 0x10000000) - return BT_LITES_SOM; - - /* Linked by FreeBSD or NetBSD linker or Linux with -qmagic */ - if ((hdr->short_magic == QMAGIC || hdr->magic == 0xb018600) - && hdr->aout.a_entry >= 0x10000000) - return BT_LITES_Q; - - /* UX linker */ - if (hdr->magic == ZMAGIC && hdr->aout.a_entry >= 0x10000000) - return BT_LITES_Z; - - - /********* Not a LITES binary *************/ - - /* - * NetBSD tried to make the magic number byte order - * independent but got it the wrong way. - */ - if ((hdr->magic & ~0xfc) == 0x0b018600) - return BT_NETBSD_09; - if (hdr->short_magic == ZMAGIC) { - switch ((hdr->magic >> 16) & 0xff) /* machine id */ - { - case 100: - if (hdr->aout.a_entry > 0x10000000) - return BT_LINUX_SHLIB; - else - return BT_LINUX; - break; - case 0: - if (hdr->aout.a_entry) { - return BT_CMU_43UX; - } else { - return BT_386BSD; - } - break; - default: - return BT_BAD; - } - } - /* Interactive coff */ - if (hdr->short_magic == COFF_ISC4_MAGIC) - return BT_ISC4; - - /* FreeBSD or BSDI */ - if (hdr->short_magic == QMAGIC) - return BT_FREEBSD; - - /* - * Linux OMAGIC. It's pretty certain nobody else is - * using this format from the sixties. In any case - * there isn't any way to distinguish them what I know - * of. - */ - if (hdr->short_magic == OMAGIC) - return BT_LINUX_O; - if (hdr->shell[0] == '#' && hdr->shell[1] == '!') - return BT_SCRIPT; - return BT_BAD; } /* Returns vnode locked iff success */ --- 734,739 ---- *** ../../../hut/src/lites/./server/sys/types.h Sat Jan 22 11:55:48 1994 --- ./server/sys/types.h Tue Nov 1 21:58:03 1994 *************** *** 36,41 **** --- 36,46 ---- * SUCH DAMAGE. * * @(#)types.h 8.4 (Berkeley) 1/21/94 + * HISTORY + * 01-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Allow type of off_t to be overridden if __OFF_T is defined. + * Allows for code to run on host using old lseek. + * */ #ifndef _SYS_TYPES_H_ *************** *** 65,71 **** --- 70,80 ---- typedef unsigned long ino_t; /* inode number */ typedef unsigned short mode_t; /* permissions */ typedef unsigned short nlink_t; /* link count */ + #ifdef __OFF_T + typedef __OFF_T off_t; + #else typedef quad_t off_t; /* file offset */ + #endif typedef long pid_t; /* process id */ typedef long segsz_t; /* segment size */ typedef long swblk_t; /* swap offset */ From jvh@cs.hut.fi Wed Nov 2 01:57:11 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 2 Nov 1994 10:47:13 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 2 Nov 1994 10:46:58 +0200 Date: Wed, 2 Nov 1994 10:46:58 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Problems w current snap shot for ns32k. In-Reply-To: <9411020008.AA08046@hfrd.dsto.gov.au> References: <9411020008.AA08046@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian, Just consider the previous merge a first iteration. I'm sorry I didn't get it right the first time but I think the current snapshot is anyways closer to the truth than the previous one. After a couple of more iterations we should have a fairly stable system for all three architectures (i386, ns532, hppa), I hope. Meanwhile I wanted to keep the i386 port working and because of this I merged only the parts I could understand right now. emul_exec.c is currently supposed to work for both i386 and hppa. It would be nice to keep most of the code machine independent. I've been thinking of a new structure for the code that might solve some problems but haven't gotten down to it yet. Also I planned to make a library that could be linked to both the server and the emulator that would include the exec file interpretation among other things. For now I guess we could just make more binary types BT_I386_NETBSD_09 and BT_NS532_NETBSD_09 and perhaps add a machine dependent check for which types are acceptable. Regarding static vs. extern inline: I've never compiled with -O0 so I haven't run into the problem. Static inline generates a zillion redundant code copies which is irritating (and actually caused me some problem I think). A "#pragma implementation" kind of solution would be to use a define, say __INLINE that could be defined as "extern inline" in the normal case or plain "inline" (or empty) in one file to generate a global symbol. Regarding reserving page zero: I think this should really go into the emulator as it depends on the emulated binary (whether or not it is applicable). Some binaries (let's guess old sysV ones) might need readable NULL pointers. Some binaries (such as NMAGIC) need the page for the text segment. It seems nicer to add a dummy page at zero when the situation is known instead of having to deallocate it. Now that cthread_init is gone from ecrt0.c there should appear no memory by mistake at address zero (if that happens it must be due to a bug somewhere). Thanks for the diffs. Johannes PS. Yesterday I implemented sysV shared memory to speed up Doom (it uses the X shared memory extension). Unfortunately my X server binary doesn't support it. grr. From baford@schirf Wed Nov 2 13:32:37 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 2 Nov 1994 22:24:43 +0200 id NAA04671; Wed, 2 Nov 1994 13:24:32 -0700 To: Johannes Helander Cc: lites@cs.hut.fi, baford@schirf Subject: Re: Problems w current snap shot for ns32k. In-Reply-To: Your message of "Wed, 02 Nov 94 10:46:58 +0200." <199411020846.AA16864@laphroaig.cs.hut.fi> Date: Wed, 02 Nov 94 13:24:30 MST From: Bryan Ford Johannes wrote: >emul_exec.c is currently supposed to work for both i386 and hppa. It >would be nice to keep most of the code machine independent. I've been >thinking of a new structure for the code that might solve some >problems but haven't gotten down to it yet. Also I planned to make a >library that could be linked to both the server and the emulator that >would include the exec file interpretation among other things. Note that, since Mach needs to do these kinds of things too (unfortunately), I've already moved the exec file interpretation that used to be in the Mach i386 bootstrap program into libmach; I now use the same code within the kernel to "load" the boostrap program, and within the bootstrap program to load the first server. Would it be possible and/or appropriate to extend it so Lites could use the same mechanism (or something built on the same mechanism), straight out of libmach? Mach probably shouldn't have to recognize all the different formats Lites can, but it has to recognize the various formats that the Mach bootstrap programs and standalone servers may come in - which currently means at least Linux, BSD, and UX. Lites could use libmach's basic mechanism and extend it for other formats such as emulator binaries or ELF executables or whatever... Bryan From DALL@HFRD.DSTO.GOV.AU Wed Nov 2 17:45:23 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 02:37:06 +0200 11:06:18 +1030 Date: Thu, 3 Nov 94 11:07:49 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: Problems w current snap shot for ns32k. In-Reply-To: <199411020846.AA16864@laphroaig.cs.hut.fi> References: <9411020008.AA08046@hfrd.dsto.gov.au> <199411020846.AA16864@laphroaig.cs.hut.fi> X-Hfrd: 1994110311053138 Johannes Helander writes: > Ian, Just consider the previous merge a first iteration. Of course, just providing feedback for the next iteration. > emul_exec.c is currently supposed to work for both i386 and hppa. > It would be nice to keep most of the code machine independent. > I've been thinking of a new structure for the code that might > solve some problems but haven't gotten down to it yet. Also I > planned to make a library that could be linked to both the server > and the emulator that would include the exec file interpretation > among other things. That would avoid duplication of code. > Regarding static vs. extern inline: I've never compiled with -O0 > so I haven't run into the problem. Static inline generates a > zillion redundant code copies which is irritating (and actually > caused me some problem I think). Not so, unless you are compiling without optimization of the function couldn't be inlined anyway. From the gcc info page: When a function is both inline and `static', if all calls to the function are integrated into the caller, and the function's address is never used, then the function's own assembler code is never referenced. In this case, GNU CC does not actually output assembler code for the function, unless you specify the option `-fkeep-inline-functions'. The extern (as opposed to static) says never generate non-inline code regardless. This works if there is a library version to backl the cases where it couldn't be inlined (no optimization etc). > Regarding reserving page zero: I think this should really go into > the emulator as it depends on the emulated binary (whether or not > it is applicable). I guess so. I am not quite sure where. Ian From DALL@HFRD.DSTO.GOV.AU Wed Nov 2 18:10:59 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 03:03:59 +0200 11:33:50 +1030 Date: Thu, 3 Nov 94 11:35:19 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: spl troubles X-Hfrd: 1994110311330137 I have been attempting to put lites to more serious use, but after a while, I always get a panic due to assertion (&spl_lock->holder) == 0. This seems to have arisen from a call interupt_enter(SPLSOFTCLOCK) from the timer loop. The funny thing is that when I use gdb to look at spl_lock, the holder *is* zero. So assuming assert works, the holder must have been zeroed sometime between the assertion and the task_suspend. I guess there is plenty of time for something other thread to be scheduled, but it is a bit odd that the other thread is *always* scheduled in that interval, and of course, no thread should be unlocking a lock that is held by someone else. It is possible that some bit of code is unlocking spl_lock twice, but that is supposed to be being checked for. So, how can the lock be acquired and have holder non zero? About the only thing I can think of is that I could be linking with some library which has been compiled without WAIT_DEBUG. It might help if I knew what sort of problems motivated these checks and why import_mach.h redefines mutex_{un,}lock. Of course, it is possible that something totally unrelated is causing the problem (like a stray pointer overwriting the lock data). Ian From mike@cs Wed Nov 2 20:28:19 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 05:22:04 +0200 Date: Wed, 2 Nov 94 20:21:47 -0700 From: mike@cs (Mike Hibler) To: dall@hfrd.dsto.gov.au, lites@cs.hut.fi Subject: Re: spl troubles I ran into something quite similar on the PA. Try the following fix to mk/user/threads/cthreads.h. Apparently not everyone uses the versions of the macros in import_mach.h. This fixes an obvious race where the holder is cleared after the lock is released. ---- *** /tmp/RCSA013584 Wed Nov 2 20:16:57 1994 --- cthreads.h Tue Oct 4 12:20:46 1994 *************** *** 368,378 **** MACRO_END #define mutex_unlock(m) \ MACRO_BEGIN \ if (spin_unlock(&(m)->held), \ cthread_queue_head(&(m)->queue, vm_offset_t) != 0) { \ mutex_unlock_solid(m); \ } \ - (m)->holder = 0; \ MACRO_END #else /* defined(WAIT_DEBUG */ #define mutex_lock(m) \ --- 368,378 ---- MACRO_END #define mutex_unlock(m) \ MACRO_BEGIN \ + (m)->holder = 0; \ if (spin_unlock(&(m)->held), \ cthread_queue_head(&(m)->queue, vm_offset_t) != 0) { \ mutex_unlock_solid(m); \ } \ MACRO_END #else /* defined(WAIT_DEBUG */ #define mutex_lock(m) \ From jvh@cs.hut.fi Thu Nov 3 01:24:46 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 10:18:35 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 3 Nov 1994 10:18:13 +0200 Date: Thu, 3 Nov 1994 10:18:13 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: spl troubles In-Reply-To: <9411030105.AA14427@hfrd.dsto.gov.au> References: <9411030105.AA14427@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. I had a bug in the first WAIT_DEBUG code in mutex_unlock that first unlocked the lock and then did the check. Obviously the check must be done first. First in the unlock case and after taking the lock in the lock case. I sent a fix to Mary (and perhaps someone else) so it is hopefully correct in MK but I'm not sure I fixed the diff in leia so you might have the faulty version. If not then we might have a more serious problem. Johannes From idall@eleceng.adelaide.edu.au Thu Nov 3 07:12:34 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 16:03:34 +0200 Date: Fri, 4 Nov 1994 00:33:06 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Job control? Symlinks? Job control doesn't seem to work properly. If I have a vi or an emacs, and ^Z, the screen gets refreshed, but nothing else. If I do "sleep 100" I can ^Z and get a shell prompt. I can even "fg" and get the process back in the forground, but after that, any more ^Z's are ignored and further more, the process doesn't exit after its 100 seconds. This behaviour is the same with a UX linked bash or with the netbsd csh. Also, I notice that if I create symlinks, they cause fsck errors and then the value gets trashed. It seems to me that lites is creating old style symlinks with the data in data blocks, but the fsck is expecting the symlink data to be in the inode. This is on old 4.3 file systems. I haven't had a panic since I fixed the mutex_unlock. I have MK83a now. Ian From jvh@cs.hut.fi Thu Nov 3 07:28:44 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 16:19:43 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 3 Nov 1994 16:19:29 +0200 Date: Thu, 3 Nov 1994 16:19:29 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Job control? Symlinks? In-Reply-To: <9411031403.AA21260@augean.eleceng.adelaide.edu.au> References: <9411031403.AA21260@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. I fixed ^Z yesterday. The server's signal code is a horrible mess so I might have broken something but hopefully not too much. Linux emacs still has problems with ^Z but I didn't try to fix that. fsck needs to be the 4.4BSD one. The filesystem is slightly incompatible from 4.3BSD. I'm working on integrating the GNU make environment and will put out a snapshot as soon as that more or less works. I'm going to keep ODE around for a while longer so you can build with either gmake or ODE. In the long run, however, I think ODE will have to go as maintaining both would be a pain. Johannes From jkh@freefall.cdrom.com Thu Nov 3 07:58:29 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 16:48:25 +0200 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Johannes Helander Cc: idall@eleceng.adelaide.edu.au (Ian Dall), lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: Your message of "Thu, 03 Nov 94 16:19:29 +0200." <199411031419.AA09194@laphroaig.cs.hut.fi> Date: Thu, 03 Nov 1994 07:48:10 -0800 From: "Jordan K. Hubbard" > I'm working on integrating the GNU make environment and will put out a > snapshot as soon as that more or less works. I'm going to keep ODE > around for a while longer so you can build with either gmake or ODE. > In the long run, however, I think ODE will have to go as maintaining > both would be a pain. This is obviously a stupid question, and I probably simply haven't been following the discussions for long enough (or I missed something), but why not use bmake? I know that bmake is evil, nasty, bad mannered and does not have anything near to all the features that gmake & ODE have, but considering the environment you're trying to merge with, it seems to me that there's really no other choice! Of course, if I had to vote only between ODE and gmake, I'd take gmake without question. Still, if we're going to get to a point someday where one can take FreeBSD or NetBSD and truly merge it with LITES halfway seamlessly, it seems that bmake is going to become rather a necessity. Jordan From jvh@cs.hut.fi Thu Nov 3 08:22:14 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 17:12:26 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 3 Nov 1994 17:12:15 +0200 Date: Thu, 3 Nov 1994 17:12:15 +0200 From: Johannes Helander To: "Jordan K. Hubbard" Cc: lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: <361.783877690@freefall.cdrom.com> References: <199411031419.AA09194@laphroaig.cs.hut.fi> <361.783877690@freefall.cdrom.com> Organization: Helsinki University of Technology, CS Lab. The complaint with ODE has been that it is too hard to set up and use. To solve this problem configure + gmake is simply the best currently available alternative. According to the plan you can take either CMU's Mach (binary) release or Utah's Mach and compile LITES with it. The build environment is similar to Utah's so LITES should be easy to build both together with Utah Mach from scratch. Personally I don't really care what make flavor is used and I have nothing against ODE or bmake or . I actually used to dislike configure a lot but the new autoconfig system looks surprisingly good. Besides all compilers, emacs, and heaps of other programs use gmake anyways so you will have to support it anyways. Using it for the OS server as well shouldn't make a big difference. Anyways, let's not get too fanatical about this. I'll try gmake now and if someone doesn't like it we can consider changing it. Johannes From jkh@freefall.cdrom.com Thu Nov 3 08:55:11 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 17:48:30 +0200 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: Your message of "Thu, 03 Nov 94 17:12:15 +0200." <199411031512.AA13616@laphroaig.cs.hut.fi> Date: Thu, 03 Nov 1994 07:48:08 -0800 From: "Jordan K. Hubbard" > The complaint with ODE has been that it is too hard to set up and use. > To solve this problem configure + gmake is simply the best currently > available alternative. According to the plan you can take either > CMU's Mach (binary) release or Utah's Mach and compile LITES with it. > The build environment is similar to Utah's so LITES should be easy to > build both together with Utah Mach from scratch. It's not so much ease-of-use for the respective environments I'm arguing, it's difficulty-of-merge. Certainly, one can bury anything below a bmake Makefile that transparently calls gmake on everything below, and we'll do that if we have to, but having the entire FreeBSD system use bmake pays real dividends when we decide we want to change some compile flag or bit of build behavior for the entire system, and we need then only change the .mk macros in one place. I know that gmake lets you do this kind of thing just a easily, but now we have two build systems to maintain! :-( It's just one more hurdle to jump over when and if we decide that a FreeBSD system based on Mach would be a nice option to offer. Anyway, I don't feel religiously about it, I just felt compelled to point it out at this early juncture. We can revisit this topic again when this all becomes less hypothetical, if you wish. Jordan From Mary_Thompson@ERNST.MACH.CS.CMU.EDU Thu Nov 3 09:21:08 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 17:54:19 +0200 3 Nov 94 10:54:04 EST From: Mary Thompson To: Johannes Helander , dall@hfrd.dsto.GOV.AU Cc: lites@CS.HUT.FI Subject: Re: spl troubles In-Reply-To: Your message of "Thu, 03 Nov 94 10:18:13 +0200." <199411030818.AA15599@laphroaig.cs.hut.fi> Date: Thu, 03 Nov 94 10:54:01 EST Sender: Mary_Thompson@ERNST.MACH.CS.CMU.EDU Uh no..., The fix to mutex_unlock in cthreads.h did not make it into MK83A. I have an earlier and incorrect version from HUT. There is always one more bug... Mary From Robert.Baron@ERNST.MACH.CS.CMU.EDU Thu Nov 3 09:46:30 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 18:35:19 +0200 Date: Thu, 3 Nov 1994 11:30-EST From: Robert.Baron@ERNST.MACH.CS.CMU.EDU To: "Jordan K. Hubbard" , Johannes Helander Cc: Ian Dall , lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: "Jordan K. Hubbard"'s mail message of Thu, 03 Nov 1994 07:48:10 -0800 I don't understand. I have long had the technology to build the bsdss tree with bmake. (And these makefiles have the ability to do shadowing and other CMU magic for those who care.) The MK83a kernel release has a "flat/" directory which will restructure the kernel to do this kind of bmake build. I believe that Maeda exported similar bmakefiles for lites. In any case I can make my makefiles for the bsdss server and emulator available to anyone who wants to use them as a template for the lites server/emulator. I have to agree with Jordan that I find it out of keeping to use gmake as a build tool for netbsd/freebsd. We want the system to be as "native" as possible. From baford@schirf Thu Nov 3 11:59:31 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 20:51:44 +0200 id LAA09455; Thu, 3 Nov 1994 11:51:38 -0700 To: "Jordan K. Hubbard" Cc: lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: Your message of "Thu, 03 Nov 94 07:48:08 PST." <1267.783877688@freefall.cdrom.com> Date: Thu, 03 Nov 94 11:51:37 MST From: Bryan Ford >> The complaint with ODE has been that it is too hard to set up and use. >> To solve this problem configure + gmake is simply the best currently >> available alternative. According to the plan you can take either >> CMU's Mach (binary) release or Utah's Mach and compile LITES with it. >> The build environment is similar to Utah's so LITES should be easy to >> build both together with Utah Mach from scratch. > >It's not so much ease-of-use for the respective environments I'm >arguing, it's difficulty-of-merge. Certainly, one can bury anything >below a bmake Makefile that transparently calls gmake on everything >below, and we'll do that if we have to, but having the entire FreeBSD >system use bmake pays real dividends when we decide we want to change >some compile flag or bit of build behavior for the entire system, and >we need then only change the .mk macros in one place. > >I know that gmake lets you do this kind of thing just a easily, but >now we have two build systems to maintain! :-( Johannes and I talked about these issues quite a bit before starting in on the new Lites build environment. Basically there were two reasons we used gmake instead of bmake: * The Mach build environment already uses gmake, so any merge with FreeBSD or NetBSD would have to involve working around these two makefile flavors anyway. Is it more important for the Lites build environment to be similar to Mach's (the lower-level layer), or the user programs (the higher-level layer)? * GNU make is very portable, and can easily be made available under BSD (and in my experience, usually is). BSD make, on the other hand, is quite specific to BSD; I've never heard of anyone building it on anything else. By using GNU make we ensure that Mach and Lites can easily be built on either BSD or Linux, while if we used BSD make it could be a big problem for Linux users. This is rather important considering that the Linux community is probably at least ten times bigger than the i386 BSD community. One thing I was planning to do originally, but didn't for some reason I can't remember now, was to name all the makefiles in the Mach build environment 'GNUmakefile' instead of 'Makefile'; that way only GNU make would pick them up and alternate makefile sets could be dropped in if desired. I'm still willing to make this change, if some people would find it desirable to be able to have multiple sets of makefiles. Bryan From jvh@cs.hut.fi Thu Nov 3 12:20:54 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 21:09:07 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 3 Nov 1994 21:09:06 +0200 Date: Thu, 3 Nov 1994 21:09:06 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Re: Job control? Symlinks? In-Reply-To: <199411031851.LAA09455@schirf.cs.utah.edu> References: <1267.783877688@freefall.cdrom.com> <199411031851.LAA09455@schirf.cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Bryan Ford writes: > One thing I was planning to do originally, but didn't for some reason > I can't remember now, was to name all the makefiles in the Mach build > environment 'GNUmakefile' instead of 'Makefile'; that way only GNU > make would pick them up and alternate makefile sets could be dropped in > if desired. I'm still willing to make this change, if some people > would find it desirable to be able to have multiple sets of makefiles. There is no Makefile -- they are all called Makefile.in or Makerules or Makeconf.in The ODE makefiles are now called Makefile (or Makeconf) and there is no conflict unless you build in your source directory which you don't want to do anyways (I'm not going to even try). To the horror of all GNU-make haters I can tell you that LITES now cross builds with both gmake and ODE (simultaneously if you wish). I haven't tried if the binaries produced work yet though. As Bryan pointed out, an important reason to go for GNU make was the desire to make it easier to build on a Linux machine (and in general make the portability better). With Linux binary compatibilty and soon ext2fs it might be interesting to some people. This doesn't mean we shouldn't attempt to merge Lites with the FreeBSD kernel, but when thinking about merging the makefiles are not relatively speaking a very big issue. Johannes From jvh@cs.hut.fi Thu Nov 3 13:22:44 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 3 Nov 1994 22:16:01 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 3 Nov 1994 22:16:00 +0200 Date: Thu, 3 Nov 1994 22:16:00 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: BNR vs. Lite incompatibilities Organization: Helsinki University of Technology, CS Lab. Now that we added support for 4.4Lite system calls the BNR binaries don't work anymore. Namely wait4 is incompatible but has the same system call number but BNR passes in a short pointer and Lite an int pointer (because pid_t is different). Now for Lite binaries a 32 bit value should be written in the user memory but if that is done for BNR binaries the user stack gets trashed or other horrors happen since the program reserved only 16 bits of space. Is there any way of distinguishing BNR biaries from Lite binaries? Am I wrong in believing that NetBSD and FreeBSD use the same magic code and flags in the exec header? One alternative that (usually) works on little endian machines is to return just 16 bits always. But this doesn't work if - the application didn't zero the high 16 bits. - a pid is larger than something like 2^16. - a returned pid is negative (needs sign extension). An example of applications blowing up is /sbin/init when halting the machine. After wait4 it ends up continuosly calling emul_exec_open for the file "|_?" instead of shutting down the system. This is why I originally added e_bnr_wait4 and one reason to have a separate e_bnr_sysent.c. Now if I just could distinguish Lite binaries from BNR binaries in a reliable way I'd be happy. Johannes From DALL@HFRD.DSTO.GOV.AU Thu Nov 3 16:53:30 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 4 Nov 1994 01:45:51 +0200 10:15:30 +1030 Date: Fri, 4 Nov 94 10:17:11 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Job control? Symlinks? In-Reply-To: <199411031419.AA09194@laphroaig.cs.hut.fi> References: <9411031403.AA21260@augean.eleceng.adelaide.edu.au> <199411031419.AA09194@laphroaig.cs.hut.fi> X-Hfrd: 1994110410144942 Johannes Helander writes: > I fixed ^Z yesterday. The server's signal code is a horrible mess > so I might have broken something but hopefully not too much. Any chance of getting these fixes sooner rather than later? I'd really like to start using lites as the default. Ian From jvh@cs.hut.fi Thu Nov 3 17:18:18 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 4 Nov 1994 02:11:24 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 4 Nov 1994 02:11:13 +0200 Date: Fri, 4 Nov 1994 02:11:13 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Job control? Symlinks? In-Reply-To: <9411032347.AA20116@hfrd.dsto.gov.au> References: <9411031403.AA21260@augean.eleceng.adelaide.edu.au> <199411031419.AA09194@laphroaig.cs.hut.fi> <9411032347.AA20116@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > Any chance of getting these fixes sooner rather than later? > I'd really like to start using lites as the default. ok. leia.cs.hut.fi:foggy/lites/LITES.941104.tar.gz I think the server works when compiled with either ODE or GNU but the emulator only with ODE. My testing got a bit delayed as my second disk that I use for testing lost its disklabel. Fortunately I had saved the few first blocks of the disk on the first disk so after finding them it was just a matter of dd'ing. I'll make a new snapshot after I've gotten some stability into it. Johannes From idall@eleceng.adelaide.edu.au Fri Nov 4 06:18:57 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 4 Nov 1994 15:08:42 +0200 Date: Fri, 4 Nov 1994 23:38:04 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: jvh@cs.hut.fi, lites@cs.hut.fi In-Reply-To: <9411032019.AA19155@hfrd.dsto.gov.au> Subject: "BNR vs. Lite incompatibilities" > Now that we added support for 4.4Lite system calls the BNR binaries > don't work anymore. Namely wait4 is incompatible but has the same > system call number but BNR passes in a short pointer and Lite an int > pointer (because pid_t is different). I don't know the answer to this. It is obviously a mistake to have incompatable system calls with the same number and not be able to distinguish the executables. One possibility would be to modify bnr executeables in some way like adding a flag into the flag field of the magic number. I don't know if bnr2ss checks the flag field. Anyway, do you really want to be able to still run bnr2ss, or is it that you just want to run old binaries? It would be very simple to write a little "conversion" program which overwrote the magic in existing binaries. It would be good to do a check first. Ian From root@corbin.Root.COM Fri Nov 4 06:45:11 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 4 Nov 1994 15:30:02 +0200 X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: "BNR vs. Lite incompatibilities" > Now that we added support for 4.4Lite system calls the BNR binaries > don't work anymore. Namely wait4 is incompatible but has the same > system call number but BNR passes in a short pointer and Lite an int > pointer (because pid_t is different). In-Reply-To: Your message of "Fri, 04 Nov 94 23:38:04 +1030." <9411041308.AA00871@augean.eleceng.adelaide.edu.au> From: David Greenman Reply-To: davidg@root.com Date: Fri, 04 Nov 1994 05:28:02 -0800 Sender: root@corbin.Root.COM > Now that we added support for 4.4Lite system calls the BNR binaries > don't work anymore. Namely wait4 is incompatible but has the same > system call number but BNR passes in a short pointer and Lite an int > pointer (because pid_t is different). Hmmm. In FreeBSD 1.x (which is BNR2 derived): struct wait4_args { int pid; int *status; int options; struct rusage *rusage; int compat; }; int wait4(p, uap, retval) struct proc *p; struct wait4_args *uap; int *retval; { uap->compat = 0; return (wait1(p, (struct wait1_args *)uap, retval)); } So where is the pid_t? At least in the sources I have here, it has always taken an int for the pid. The above is the same in the 4.4-lite sources. -DG From jvh@cs.hut.fi Sat Nov 5 00:35:52 1994 (5.65c8/HUTCS-S 1.4 for ); Sat, 5 Nov 1994 09:23:07 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sat, 5 Nov 1994 09:20:47 +0200 Date: Sat, 5 Nov 1994 09:20:47 +0200 From: Johannes Helander To: davidg@root.com Cc: lites@cs.hut.fi Subject: Re: "BNR vs. Lite incompatibilities" In-Reply-To: <199411041328.FAA00404@corbin.Root.COM> References: <9411041308.AA00871@augean.eleceng.adelaide.edu.au> <199411041328.FAA00404@corbin.Root.COM> Organization: Helsinki University of Technology, CS Lab. Ahem ahem. It seems I got the wait4 issue wrong. The truth was more something like that init was calling wait repeatedly and I had loaded the wrong symbol table into my debugger as I forgot to umount the disk in between and had the wrong file in a disk cache (sometimes it gets confusing with multiple servers at once). Init was supposed to stay in a loop waiting for the server to die. It didn't die because reboot() was never called. Reboot() was never called because halt got killed by signal 9 sent by itself. This was sent because the current messy psignal sometimes calls sig_default even when not signalling the "current" process. sig_default did not take the process as an argument and instead killed the caller of kill, i.e. /sbin/halt. It should have been rather obvious that not being able to halt the machine was due to the recent changes in the signal code. Thus I should not have sent the late night message blaming wait4. Anyways I fixed the sig_default interface and got this fixed for now. I thought this might have fixed Linux job control but that was mostly due to a simpler mistake. I didn't convert signal numbers in the kill system call. This converted a SIGTSTP to a SIGCHLD. A remaining lack of compatibility is error numbers. This will have to be fixed at some point. Also Linux's tcsh still prints 'Continued' when a process is stopped (instead of 'Stopped'). This might be due to a difference in the wait status word, probably the signal number again (yeah, SIGTSTP (18) is SIGCONT on Linux). I'll fix that and put out a new snapshot. Meanwhile I hope you didn't too much mind me thinking out loud. It's getting rather early again :-). Johannes From law@snake Mon Nov 7 13:26:08 1994 id AB09441; Mon, 7 Nov 94 13:26:08 -0700 (5.65c8/HUTCS-S 1.4 for ); Mon, 7 Nov 1994 22:14:05 +0200 id NAA01542; Mon, 7 Nov 1994 13:13:37 -0700 To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: why mach_init hangs for 60 seconds Reply-To: law@cs In-Reply-To: Your message of Tue, 25 Oct 94 12:20:47 +0200. <199410251020.AA17432@laphroaig.cs.hut.fi> Date: Mon, 07 Nov 94 13:13:37 MST From: Jeffrey A Law In message <199410251020.AA17432@laphroaig.cs.hut.fi> you write: > Mike Hibler wrote: > > Here is what causes it on the PA anyway. pause() is implemented as: > > > > sigpause(sigblock(0L)); > > > > which is "reasonably atomic" on a uniprocessor, monolithic BSD system. > > Avoiding this race must clearly be one of the reasons why the signal > interfaces were changed. I had totally forgotten but I fixed my copy > of mach_init to not have this race. > > sigblock(sigmask(SIGTERM) | sigmask(SIGALRM)); > alarm(60); > if (!signalled) > sigpause(0); > sigblock(0); > > Now this should work but I'm not sure as I've probably been using old > versions of the binary. Fixing the source is not enough :-). If you > are distributing mach_init and it does not have my history entries > from July and January 1994 please pick the diff below up: Actually, the patch was incorrect -- sigblock(0) is a nop and leaves SIGTERM and SIGALRM masked for all of mach_init's children that don't explicitly unmask them. You should apply this patch on top of yours: * main.c (main): Restore the signal mask properly. *** /tmp/RCSA001499 Mon Nov 7 13:09:57 1994 --- usr/etc/mach_init/main.c Mon Nov 7 13:09:09 1994 *************** *** 210,222 **** cthread_fork_prepare(); if (fork()) { cthread_fork_parent(); ! sigblock(sigmask(SIGTERM) | sigmask(SIGALRM)); alarm(60); if (!signalled) sigpause(0); ! sigblock(0); if (debug) printf("Parent terminating.\n"); --- 210,223 ---- cthread_fork_prepare(); if (fork()) { + unsigned int omask; cthread_fork_parent(); ! omask = sigblock(sigmask(SIGTERM) | sigmask(SIGALRM)); alarm(60); if (!signalled) sigpause(0); ! sigsetmask(omask); if (debug) printf("Parent terminating.\n"); From DALL@HFRD.DSTO.GOV.AU Tue Nov 8 17:08:44 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 9 Nov 1994 01:55:28 +0200 10:23:55 +1030 Date: Wed, 9 Nov 94 10:23:59 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Sent-Via: lites@cs.hut.fi Subject: Current snapshot (1107) X-Hfrd: 1994110910214492 I built the current snapshot and got it working with relatively little trouble. Notably, with Jeffrey Law's fix for mach_init, it seems to halt cleanly. The main difficulties were still in detecting and handling different executable types, although I think we are making progress in the right direction. The things I ran into were first, some missing files: ./emulator/extra/memcmp.c ./emulator/ns532/ntoh.s ./server/ns532/server/queue.c I think maybe I should put these first two in libmach_sa anyway. queue.c seems to have dissapeared from the i386 MD code too, and it doesn't seem to have reappeared in the MI code. Is the long term plan to use server/serv/exec_file.c for the emulator too? The only real issue which arose is the definition of TEXT_START_TRUNC. It seems to me untidy to have an apparently arbitrary 1 page added to the EMULATOR_BASE because server_exec.c can't figure out where to load it. Granted, due to the deficiencies of a.out *some* assumption has to be made. I would have thought that truncating a_entry to a page boundary would be a pretty good heuristic for B_LITES_Z files, if B_LITES_Z files are essentially Z_MAGIC with high a_entry values. Since there is no great legacy of code in this format (I assume?) why not just make it part of the definition of BT_LITES_Z files, that the entry point it always in the first page of the text segment? Of course, you have in effect an alternate restriction that BT_LITES_Z files to being linked with a text start on a 16MB + 1 page boundary. I guess either of these is workable. My way means my old emulators continue to work but I guess your old emulators wouldn't ;-(. I'm linking emulator with gnu ld2 so it would be good if, in the detection of BT_LITES_Z, only shortmagic instead of magic was used since gnu ld2 puts machine types and flags in the other short word. Does that work properly on a big-endian machine too? emulator/Makefile: add ns532_emul_exec.o to DEP_OFILES emulator/ns532/ecrt0.c: model after new i386/ecrt0.c emulator/ns532/ns532_emul_exec.c: Use up to date BT_xxx emulator/programs/emulator_base.c: Don't add extra page server/serv/exec_file.c: Use shortmagic to determine BT_LITES_Z server/serv/server_exec.c: Use trunc_page instead of TEXT_START_TRUNC for BT_LITES_Z Diffs follow. Ian *** ../../../cmu/src/lites/./emulator/Makefile Fri Nov 4 12:03:53 1994 --- ./emulator/Makefile Sat Nov 5 11:05:32 1994 *************** *** 117,123 **** DEP_OFILES = e_mig_support.o emul_generic.o error_codes.o emul_init.o \ emul_mapped.o mvfs_interface.o e_machinedep.o emul_misc_asm.o atoi.o \ strtol.o ctype_.o ntoh.o e_bsd_stubs.o e_cmu_43ux_stubs.o \ ! e_linux_stubs.o emul_vector.o emul_exec.o \ e_trampoline.o e_lite_sysent.o e_isc4_sysent.o e_linux_sysent.o \ e_sysv_stubs.o e_linux_trampoline.o e_exception.o e_mach_msg_server.o \ e_cmu_43ux_sysent.o zprintbsd.o process_self.o \ --- 117,123 ---- DEP_OFILES = e_mig_support.o emul_generic.o error_codes.o emul_init.o \ emul_mapped.o mvfs_interface.o e_machinedep.o emul_misc_asm.o atoi.o \ strtol.o ctype_.o ntoh.o e_bsd_stubs.o e_cmu_43ux_stubs.o \ ! e_linux_stubs.o emul_vector.o emul_exec.o ns532_emul_exec.o \ e_trampoline.o e_lite_sysent.o e_isc4_sysent.o e_linux_sysent.o \ e_sysv_stubs.o e_linux_trampoline.o e_exception.o e_mach_msg_server.o \ e_cmu_43ux_sysent.o zprintbsd.o process_self.o \ No differences encountered *** ../../../cmu/src/lites/./emulator/ns532/e_trampoline.c Tue Nov 8 21:12:12 1994 --- ./emulator/ns532/e_trampoline.c Tue Nov 8 21:13:07 1994 *************** *** 102,109 **** current_sysent = e_cmu_43ux_sysent; break; case BT_386BSD: ! case BT_OLD_EMULATOR: ! case BT_NETBSD_09: case BT_FREEBSD: default: current_nsysent = e_bsd_nsysent; --- 102,108 ---- current_sysent = e_cmu_43ux_sysent; break; case BT_386BSD: ! case BT_NETBSD: case BT_FREEBSD: default: current_nsysent = e_bsd_nsysent; *** ../../../cmu/src/lites/./emulator/ns532/ecrt0.c Sun Oct 2 19:09:52 1994 --- ./emulator/ns532/ecrt0.c Tue Nov 8 22:05:40 1994 *************** *** 28,42 **** */ /* * HISTORY - * 02-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) - * Try leaving out the cthread_init again. - * - * 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) - * Pute cthread_init back until we figure out a better way. - * - * 26-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) - * Remove cthread initialization/exit and also monstartup. - * * $Log: $ */ /* --- 28,33 ---- *************** *** 43,48 **** --- 34,42 ---- * Emulator entry point. */ + /* just in case someone defined it to empty */ + #undef register + #define cthread_sp() \ ({ int _sp__; \ __asm__("sprd sp, %0" \ *************** *** 50,72 **** _sp__; }) int (*mach_init_routine)(); - - #ifdef CTHREADS - int (*_cthread_init_routine)(); - int (*_cthread_exit_routine)(); - int (*_monstartup_routine)(); - #endif int exit(); - extern unsigned char etext; extern unsigned char _eprol; _start() { ! int old_sp; ! int new_sp; ! old_sp = new_sp = cthread_sp(); if (mach_init_routine) (void) mach_init_routine(); --- 44,72 ---- _sp__; }) int (*mach_init_routine)(); int exit(); extern unsigned char _eprol; _start() { ! /* ! * The server set_emulator_state() sets pc, sp, psr, r0, r1 ! * sp points to the arguments. ! * r0 points to the BSS dirty page (shared with data) ! * that needs to be cleared. ! * r1 is the clearing count for the BSS fragment. ! */ ! register char *zero_start asm("r0"); ! register int zero_count asm("r1"); ! register int sp; ! /* Sotre the stack pointer in a variable */ ! sp = cthread_sp(); + /* Clear beginning of BSS (on the page shared with DATA) */ + for ( ; zero_count > 0; zero_count--) + *zero_start++ = 0; + if (mach_init_routine) (void) mach_init_routine(); *************** *** 73,95 **** asm(".globl __eprol"); asm("__eprol:"); ! #ifdef CTHREADS ! if (_cthread_init_routine) { ! new_sp = (*_cthread_init_routine)(); ! if (new_sp) { ! asm volatile("lprd sp, %0" : : "g" (new_sp) ); ! } ! } ! ! if (_monstartup_routine) { ! _monstartup_routine(&_eprol, &etext); ! } ! ! (* (_cthread_exit_routine ? _cthread_exit_routine : exit)) ! (emulator_main(old_sp, new_sp)); ! #else ! (*exit)(emulator_main(old_sp, new_sp)); ! #endif } - - --- 73,77 ---- asm(".globl __eprol"); asm("__eprol:"); ! exit(emulator_main(sp, sp)); } *** ../../../cmu/src/lites/./emulator/ns532/ns532_emul_exec.c Wed Sep 28 20:48:31 1994 --- ./emulator/ns532/ns532_emul_exec.c Tue Nov 8 22:13:57 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 30-Oct-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Removed linux code. + * * 27-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) * Make obreak less susceptible to integer overflows. * *************** *** 82,93 **** * Set up the emulator vectors. */ switch (binary_type) { - case BT_LINUX: - case BT_LINUX_O: - case BT_LINUX_SHLIB: - /* Linux uses a nonstandard system call calling convention */ - e_linux_setup(mach_task_self(), binary_type); - break; default: emul_setup(mach_task_self(), binary_type); break; --- 85,90 ---- *************** *** 101,113 **** /* And start running it */ switch (binary_type) { - case BT_LINUX: - case BT_LINUX_O: - case BT_LINUX_SHLIB: - err = emul_exec_linux_start(kframe, binary_type, - argc, argv, envp, - entry_point); - break; default: err = emul_exec_start(kframe, binary_type, argc, argv, envp, --- 98,103 ---- *************** *** 192,198 **** * NetBSD magic's are in inverted byte order * 0xfc is mask for flags field. */ ! *binary_type = BT_NETBSD_09; bcopy(&exdata.exec, exech, sizeof(exdata.exec.aout)); } else if (exdata.short_magic == ZMAGIC) { /* a.out */ --- 182,188 ---- * NetBSD magic's are in inverted byte order * 0xfc is mask for flags field. */ ! *binary_type = BT_NETBSD; bcopy(&exdata.exec, exech, sizeof(exdata.exec.aout)); } else if (exdata.short_magic == ZMAGIC) { /* a.out */ *************** *** 276,289 **** text_start = 0; text_offset = NBPG; break; ! case BT_OLD_EMULATOR: ! text_size = round_page(exech->aout.a_text ! + sizeof(struct exec)); ! text_start = EMULATOR_BASE; ! text_offset = 0; ! e_emulator_error("exec_load: using BT_OLD_EMULATOR code\n"); ! break; ! case BT_NETBSD_09: text_size = round_page(exech->aout.a_text); text_start = 0x1000; text_offset = 0; --- 266,272 ---- text_start = 0; text_offset = NBPG; break; ! case BT_NETBSD: text_size = round_page(exech->aout.a_text); text_start = 0x1000; text_offset = 0; *************** *** 290,305 **** break; case BT_CMU_43UX: text_size = round_page(exech->aout.a_text ! + sizeof(struct exec)); text_start = 0x10000; text_offset = 0; break; - case BT_WARP1: - text_size = round_page(exech->aout.a_text - + sizeof(struct exec)); - text_start = trunc_page(exech->aout.a_entry); - text_offset = 0; - break; case BT_FREEBSD: text_size = round_page(exech->aout.a_text); text_start = 0x1000; --- 273,282 ---- break; case BT_CMU_43UX: text_size = round_page(exech->aout.a_text ! + sizeof(struct aout_hdr)); text_start = 0x10000; text_offset = 0; break; case BT_FREEBSD: text_size = round_page(exech->aout.a_text); text_start = 0x1000; *************** *** 346,357 **** return ENOEXEC; } switch (binary_type) { ! case BT_386BSD: ! case BT_OLD_EMULATOR: ! case BT_NETBSD_09: case BT_CMU_43UX: - case BT_WARP1: - case BT_FREEBSD: entry = exech->aout.a_entry; data_offset = text_offset + text_size; data_start = text_start + text_size; --- 323,330 ---- return ENOEXEC; } switch (binary_type) { ! case BT_NETBSD: case BT_CMU_43UX: entry = exech->aout.a_entry; data_offset = text_offset + text_size; data_start = text_start + text_size; *** ../../../cmu/src/lites/./emulator/programs/emulator_base.c Fri Nov 4 11:45:19 1994 --- ./emulator/programs/emulator_base.c Sat Nov 5 00:57:52 1994 *************** *** 49,55 **** EMULATOR_BASE + (1024*1024)); #else #if defined(PC532) && defined(GNU_LD2) ! printf("%lx\n", EMULATOR_BASE + sizeof (struct exec) + 0x1000); #else printf("%x\n", EMULATOR_BASE + 0x1000); #endif --- 49,55 ---- EMULATOR_BASE + (1024*1024)); #else #if defined(PC532) && defined(GNU_LD2) ! printf("%lx\n", EMULATOR_BASE + sizeof (struct exec)); #else printf("%x\n", EMULATOR_BASE + 0x1000); #endif *** ../../../cmu/src/lites/./server/ns532/server/serv_machdep.c Mon Nov 7 03:22:38 1994 --- ./server/ns532/server/serv_machdep.c Tue Nov 8 22:09:50 1994 *************** *** 82,87 **** --- 82,88 ---- #include + #include /* for struct exec_load_info */ #include #include #include *************** *** 142,149 **** ts.sb = 0; ts.fp = 0; ! ts.XXX = li->zero_start; ! ts.YYY = li->zero_count; if ((ret=thread_set_state(p->p_thread, NS532_THREAD_STATE, --- 143,150 ---- ts.sb = 0; ts.fp = 0; ! ts.r0 = li->zero_start; ! ts.r1 = li->zero_count; if ((ret=thread_set_state(p->p_thread, NS532_THREAD_STATE, *** ../../../cmu/src/lites/./server/serv/exec_file.c Mon Nov 7 10:44:35 1994 --- ./server/serv/exec_file.c Tue Nov 8 23:44:49 1994 *************** *** 105,111 **** } /* UX linker */ ! if (hdr->magic == ZMAGIC && hdr->aout.a_entry >= 0x10000000) { *bt = BT_LITES_Z; return; } --- 105,111 ---- } /* UX linker */ ! if (hdr->short_magic == ZMAGIC && hdr->aout.a_entry >= 0x10000000) { *bt = BT_LITES_Z; return; } *************** *** 334,340 **** switch (bt) { case BT_LITES_Z: text->size = round_page(hdr->a_text + sizeof(struct aout_hdr)); ! text->va = TEXT_START_TRUNC(hdr->a_entry); break; case BT_LITES_Q: text->va = TEXT_START_TRUNC(hdr->a_entry); --- 334,340 ---- switch (bt) { case BT_LITES_Z: text->size = round_page(hdr->a_text + sizeof(struct aout_hdr)); ! text->va = trunc_page(hdr->a_entry); break; case BT_LITES_Q: text->va = TEXT_START_TRUNC(hdr->a_entry); *** ../../../cmu/src/lites/./server/serv/server_exec.c Mon Nov 7 10:25:41 1994 --- ./server/serv/server_exec.c Tue Nov 8 23:22:14 1994 *************** *** 1277,1283 **** switch (binary_type) { case BT_LITES_Z: text_size = round_page(exech->a_text +sizeof(struct aout_hdr)); ! text_start = TEXT_START_TRUNC(exech->a_entry); text_offset = 0; break; case BT_LITES_Q: --- 1277,1283 ---- switch (binary_type) { case BT_LITES_Z: text_size = round_page(exech->a_text +sizeof(struct aout_hdr)); ! text_start = trunc_page(exech->a_entry); text_offset = 0; break; case BT_LITES_Q: From jvh@cs.hut.fi Tue Nov 8 17:19:56 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 9 Nov 1994 02:12:03 +0200 (5.65c8/HUTCS-C 1.3 for lites); Wed, 9 Nov 1994 02:10:36 +0200 Date: Wed, 9 Nov 1994 02:10:36 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Current snapshot (1107) In-Reply-To: <9411082353.AA19510@hfrd.dsto.gov.au> References: <9411082353.AA19510@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian, queue.c is moved to libkern the emulator now uses the exec_file.c The one page is some kind of compatibility but perhaps really only bogus. Truncating a_entry to the nearest page boundary is not nice as then crt0 needs to be in the beginning of the link command. With the current macro it needs to be within the first 16MB. Your old emulators will not work anyways and if they do I promise to break them soon :-). In fact I've about 100% made them incompatible since yesterday. The emulator is always supposed to go with the server so you need to change them together. I'm not going to deal with backwards compatibility issues in that interface. If you can make the guess_binary_file_type heuristic more precise and complete that would be great. It is just a first version and I didn't want to spend too much time on that as there was other code to write at the moment. I should note that I'm compiling with the Gnu environment now myself so I might forget to update the opther files now and then. I'll put in the diffs you wish. You really will need the zero count code in ecrt0.c with the next snapshot so removing that was premature. Hopefully the new exec code will work for everyone so you can remove the MD version. Johannes From DALL@HFRD.DSTO.GOV.AU Tue Nov 8 18:05:37 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 9 Nov 1994 02:55:01 +0200 11:24:16 +1030 Date: Wed, 9 Nov 94 11:25:12 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: Current snapshot (1107) In-Reply-To: <199411090010.AA05450@laphroaig.cs.hut.fi> References: <9411082353.AA19510@hfrd.dsto.gov.au> <199411090010.AA05450@laphroaig.cs.hut.fi> X-Hfrd: 1994110911230010 Johannes Helander writes: > Your old emulators will not work anyways and if they do I promise > to break them soon :-). I recognize there is no guarantee, but it is nice when things don't work to be able to isolate whether it is the emulator or the server by trying an old emulator. It would be handy if you can highlight releases which you know are incompatable with the old emulator. > I should note that I'm compiling with the Gnu environment now > myself so I might forget to update the opther files now and then. Are there any notes on building using the gnu environment? I've no real problem making the switch except that there will inevitably be some hassle. Also, the gnu environment doesn't really support shadowing which I find very useful. If I make the switch, is the gnu build environment for mk and user available also? > You really will need the zero count code in ecrt0.c with the next > snapshot so removing that was premature. ? I don't understand. I *added* the zero count code which wasn't in the ns532 version of ecrt0.c > Hopefully the new exec code will work for everyone so you can > remove the MD version. I must check. Maybe emulator is using the exec_file.c without me being aware of it! Ian From jvh@cs.hut.fi Tue Nov 8 18:50:48 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 9 Nov 1994 03:29:11 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 9 Nov 1994 03:28:34 +0200 Date: Wed, 9 Nov 1994 03:28:34 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Current snapshot (1107) In-Reply-To: <9411090055.AA20753@hfrd.dsto.gov.au> References: <9411082353.AA19510@hfrd.dsto.gov.au> <199411090010.AA05450@laphroaig.cs.hut.fi> <9411090055.AA20753@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > by trying an old emulator. It would be handy if you can highlight > releases which you know are incompatable with the old emulator. I was thinking of incrementing the minor version number when this happens. However, if I do snapshots often enough I might forget to do that. Like the previous one was just a tar of my work tree as I kind of indicated in the ftp area. > Are there any notes on building using the gnu environment? I've no Here are some: o Install gcc and binutils for the relevant target architectures. Gcc must be 2.5.8 or newer. o Create an object directory o cd there o run configure o gmake o gmake install Configure takes a few options --build=BBB specifies the machine you are building on. --host=TTT specifies the target (this is confusing. It ought to be --target). --prefix=III specifies the install area. --srcdir=SSS specifies where the source is. --with-release=RRR specifies a Mach release tree (sup one from CMU for example). Libraries and includes not found in the prefix directory are searched from here. --enable-debug adds +DEBUG to the configuration --enable-profiling adds -DGPROF and -pg and uses libmach_sa_p.a etc. --with-configuraton=CCC sets the server configuration. See conf/MASTER.h and other MASTER files. The default is STD+WS. Here is a sample shell script I use for running configure: ----------------- begin runconfigure.sh ----------------------- #!/bin/sh -x cd /obj/lites mkdir obj cd obj # Example: cross compile pmax -> i386 /p/mach/mach3/work/src/lites/configure -v --host=i386-mach --build=mips-dec-mach --prefix=/obj/lites/inst --srcdir=/p/mach/mach3/work/src/lites --enable-debug --with-release=/p/mach/mach3/work/export/pmax_mach_X_i386_lite $* #--enable-profiling ----------------- end runconfigure.sh ----------------------- If you are compiling Mach4 then you should first complie and install it with the same install directory. If you are using Mach3 then you need to create a release tree with the kernel etc. In theory you could pick up a standard MK83a release and build with that. Mach4 moved some includes etc. so Lites might not compile without some minor tweaking with it at the moment. Perhaps some ifdefs or similar could take care of the differences so we could use both. > I must check. Maybe emulator is using the exec_file.c without me being > aware of it! It seems we are out of sync again. If I make snapshots all the time you will get versions that might not compile or work or whatever. If I make them too seldom (every other day or so) you will end up with out of sync code. But don't worry, I will have to do some other work for a while soon so there will be a slowdown. Let's do it this way: whenever I make a reasonably working snapshot (compiles, boots), I'll send an announcement to the list. Intermediate versions will just appear and you are on your own (like the previous one). Johannes From DALL@HFRD.DSTO.GOV.AU Sun Nov 13 19:56:30 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 14 Nov 1994 04:50:15 +0200 13:19:54 +1030 Date: Mon, 14 Nov 94 13:21:16 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Cntl Z still a problem? X-Hfrd: 1994111413184888 With the November 7 snapshot, cntl Z still doesn't work. I'm not sure if it meant to. I recall the fixed signal code introducing some other problem, so maybe you rolled out the "fix"? I notice there is a 1109a snapshot, but haven't tried it. Also, the mach ps and top etc didn't work. I traced this to the fact that the -6 system call is handled by the bsd_sysent[SYS_table] entry, which doen't exist. In fact SYS_table turns out to be 200 which is the correct thing in the cmu43_ux_sysent (or whatever its called) table. The syscall.h is derived from syscall.master or something, which is out of date wrt e_lites_sysent.c. I'm not sure of the correct thing to do. I guess the syscall.master should reflect the current "pure" lites syscall table. I would suggest handling the cmu extensions by having a new e_cmu_sysent.c. Then in e_trampoline.c do something like if (code < 0) sysent = &e_cmu_sysent[-code]; then all those special sysent variables currently at the end of e_lites_sysent.c could go. Ian From jvh@cs.hut.fi Mon Nov 14 04:03:23 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 14 Nov 1994 12:57:26 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 14 Nov 1994 12:56:37 +0200 Date: Mon, 14 Nov 1994 12:56:37 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Cntl Z still a problem? In-Reply-To: <9411140251.AA28743@hfrd.dsto.gov.au> References: <9411140251.AA28743@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > With the November 7 snapshot, cntl Z still doesn't work. I'm not > sure if it meant to. I recall the fixed signal code introducing some > other problem, so maybe you rolled out the "fix"? I notice there > is a 1109a snapshot, but haven't tried it. I've also noticed it doesn't work in some cases. I don't know why but it's easy to guess that the server signal code is still broken. I don't think there is too much sense in trying to fix it so much as it really needs a total redesign (move most signal handling to the emulator). One simple problem that occurs with 4.3 binaries is that sigvec doesn't enable the asynch signal handler. sigvec ought to call sigaction instead of pulling its own. > Also, the mach ps and top etc didn't work. I traced this to the fact > that the -6 system call is handled by the bsd_sysent[SYS_table] entry, > which doen't exist. In fact SYS_table turns out to be 200 which is the > correct thing in the cmu43_ux_sysent (or whatever its called) table. Perhaps we could write a new ps for Lites anyways. Now the program is basically UX compatible. But ok, adding the SYS_table would fix the acute problem. > The syscall.h is derived from syscall.master or something, which > is out of date wrt e_lites_sysent.c. I'm not sure of the correct thing > to do. I guess the syscall.master should reflect the current "pure" I think the emul_generic RPC should be replaced with a bunch of specialized RPC calls. This would make the server insensitive to the syscall.master file. The syscall.h file would be just for the benefit of user programs. perhaps we could get rid of syscalls.master altogether. > lites syscall table. I would suggest handling the cmu extensions > by having a new e_cmu_sysent.c. Then in e_trampoline.c > do something like > > if (code < 0) > sysent = &e_cmu_sysent[-code]; Fine. But all the CMU calls migh not be adjacent. But if we make the table big enough that should be ok. > then all those special sysent variables currently at the end of > e_lites_sysent.c could go. Yes, it would be much cleaner. BTW, I noticed that the server doesn't work without +DEBUG when I tried to use it for some quick benchmarking. It crashes on the i386 the same way as the mips port with +DEBUG (the second mapped u area mapping fails). I guess fixing this should make the mips port I wrote a week ago work sans signals and ultrix support that are unimplemented. Has anyone tried other configurations besides STD+WS+DEBUG? Johannes From DALL@HFRD.DSTO.GOV.AU Mon Nov 14 16:30:26 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Nov 1994 01:23:41 +0200 09:53:13 +1030 Date: Tue, 15 Nov 94 09:54:45 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: Cntl Z still a problem? In-Reply-To: <199411141056.AA11462@laphroaig.cs.hut.fi> References: <9411140251.AA28743@hfrd.dsto.gov.au> <199411141056.AA11462@laphroaig.cs.hut.fi> X-Hfrd: 1994111509521566 Johannes Helander writes: > Ian Dall writes: >> With the November 7 snapshot, cntl Z still doesn't work. I overstated the case a bit. It seems to work OK for netbsd binaries run from an netbsd shell. When using either bash or emacs compiled for 4.3, it doesn't work. > BTW, I noticed that the server doesn't work without +DEBUG when I > tried to use it for some quick benchmarking. It crashes on the > i386 the same way as the mips port with +DEBUG (the second mapped > u area mapping fails). I have used STD+WS and STD+WS+gprof with success. I was experiencing some random "emul_lib: can't handle error 0xffffffff" type messages and then the task would be terminated. It turns out that this was due to the server putting ERESTART (-1) in the return code for the system call. This was being treated as a bad error in e_mach_error_to_lites_errno (or whatever) so that the code in e_trampoline.c to handle ERESTART never gets used. I'm not sure if this is quite the right way to go. ERESTART is a kind of special code maybe it should be "encapsulated" like other unix error codes to a void potential clashes with any other mach error. Then it would have to be sign extended before it would test equal to ERESTART. The following simple fix seems to work OK though. Ian *** ../../../hut/src/lites/./emulator/error_codes.c Mon Nov 7 02:59:29 1994 --- ./emulator/error_codes.c Mon Nov 14 22:56:14 1994 *************** *** 127,132 **** --- 127,134 ---- return e_mach_error_to_linux_errno(kr); } /* Then we are BSD */ + if (kr == ERESTART || kr == EJUSTRETURN) + return kr; /* Check for encapsulated errno */ err = err_get_code(kr); if (kr == unix_err(err)) *** ../../../hut/src/lites/./emulator/ns532/e_trampoline.c Tue Nov 8 21:12:12 1994 --- ./emulator/ns532/e_trampoline.c Sun Nov 13 21:57:14 1994 *************** *** 283,289 **** if (syscode == -33) callp = &sysent_task_by_pid; else if (syscode == -6) ! callp = &e_bsd_sysent[SYS_table]; else if (syscode == -34) callp = &sysent_pid_by_task; else if (syscode == -41) --- 282,288 ---- if (syscode == -33) callp = &sysent_task_by_pid; else if (syscode == -6) ! callp = &e_cmu_43ux_sysent[SYS_table]; else if (syscode == -34) callp = &sysent_pid_by_task; else if (syscode == -41) From law@snake Mon Nov 14 16:40:44 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Nov 1994 01:35:03 +0200 id QAA21087; Mon, 14 Nov 1994 16:34:18 -0700 To: Ian Dall Cc: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: Cntl Z still a problem? Reply-To: law@cs In-Reply-To: Your message of Tue, 15 Nov 94 09:54:45 +1030. <9411142324.AA03469@hfrd.dsto.gov.au> Date: Mon, 14 Nov 94 16:34:18 MST From: Jeffrey A Law In message <9411142324.AA03469@hfrd.dsto.gov.au> you write: > > I was experiencing some random "emul_lib: can't handle error > 0xffffffff" type messages and then the task would be terminated. It > turns out that this was due to the server putting ERESTART (-1) in the > return code for the system call. This was being treated as a bad error > in e_mach_error_to_lites_errno (or whatever) so that the code in > e_trampoline.c to handle ERESTART never gets used. Yup. We (mike & myself) were wondering why nobody else was complaining... You change is correct. Jeff From law@snake Mon Nov 14 17:15:48 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Nov 1994 02:07:46 +0200 id RAA21122; Mon, 14 Nov 1994 17:06:58 -0700 To: lites@cs.hut.fi Reply-To: law@cs Subject: signals Date: Mon, 14 Nov 94 17:06:57 MST From: Jeffrey A Law I was sitting here debugging yet another signal problem (an apparent race condition causes the emulator to jump to zero during signal deliver) and I've run across something I just don't understand... The comments in send_signal seem to indicate to me that very bad things could happen if the process you wish to signal is anywhere but exception_raise or bsd_take_signal. Is that correct? If so, we've got a problem. send_signal can certainly be called for a process that isn't in one of those states. [ Imagine a timer expire from kern/kern_clock.c; this calls psignal, psignal may then call send_signal, and we're in (according to the comments) a undefined state if the process being signaled didn't just happen to be in exeception_raise or bsd_take_signal. ] What's going on here? jeff From law@snake Tue Nov 15 00:18:58 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Nov 1994 09:12:33 +0200 To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Reply-To: law@cs Subject: Minor suggestions Date: Tue, 15 Nov 94 00:12:27 MST From: Jeffrey A Law * I've found it quite useful to be able to keep multiple variants of lites hanging around in the ode build environment. The easiest I've found is to have several source directories like lites-941105 lites-941107 lites-941109a then in lites-XXYYZZ/Makeconf change lites -> lites-XXYYZZ. Now you can build several versions of lites without needing multiple copies of the mk tree and other misc junk. It'd be nice the snapshots were automatically setup to unpack with this directory structure and Makeconf appropriately changed. It'd be even better if we could do this with gnumake too. * It'd also be a great help if diffs between successive snapshots were made available. It'd certainly cut down on the time spent waiting for the not-too-fast cross-atlantic links. * And finally, some sort of brief readme/changelog/whatever which describes the changes between successive shapshots at some reasonable level of detail. I've been burned by exec changes in 941105, 941107 & 941109a. I've been burned by signal changes in 941107 & 941109a. Having some clue about what's changed would make it easier to determine what needs to be fixed in the machine dependent files, or places to look for new bugs when things that worked in one snapshot stop working in the next snapshot. Jeff From jvh@cs.hut.fi Tue Nov 15 04:54:26 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Nov 1994 13:47:35 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 15 Nov 1994 13:46:43 +0200 Date: Tue, 15 Nov 1994 13:46:43 +0200 From: Johannes Helander To: law@cs Cc: lites@cs.hut.fi Subject: Re: signals In-Reply-To: <21119.784858017@snake.cs.utah.edu> References: <21119.784858017@snake.cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. The server shouldn't be careful about when to do send_signal. Instead the emulator should coordinate the state. There is a spin lock in the emulator (e_mig_lock) that can be used to provide atomicity. In addition we could add a few state flags and other state information. The emulator would set a flag indicating when signals can't be accepted (i.e. while doing an RPC and maybe when doing something within the emulator). If the signal thread sees the no-signal flag it would just set another flag indicating there is work to do. The work thread would check this flag when releasing the no-signal flag. Sigmasks etc. ought to be moved to the emulator too. In the end almost all signal management could be done there and all signal state would be kept in the emulator. Johannes From DALL@HFRD.DSTO.GOV.AU Tue Nov 15 17:30:50 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 16 Nov 1994 02:17:52 +0200 10:07:46 +1030 Date: Wed, 16 Nov 94 10:09:22 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: ptys? X-Hfrd: 1994111610064957 I am now using the 1109a snapshot which fixed a couple of problems. Pseudo terminals seem to be a bit flakey. I tried "rlogin localhost" and also starting a shell window in emacs. Both work sometimes and fail sometimes. The odd thing is that when it succeeds, it tends to keep on succeeding and when it fails, it tends to keep on failing! I'd guess there is some sort of race in ptcopen or ptsopen. Sometimes processes don't exit cleanly. I have seen this with emacs and rlogin. For example, sometimes on exiting emacs, it positions the cursor etc but I don't get my shell prompt back. A ^Z (which normally is caught by emacs) suspends it OK and then I can "kill -9" it. This may be an emacs thing (it is a 4.3 binary) but I have seen something similar with the rlogin I mentioned. In the rlogin case, I exited the "remote" shell, but never got the local shell back intil I mkill'd the rlogind. Both of these are occasional which makes them hard to debug. It could be related to the signal problems or it could be related to the pty problems (I don't know whether the emacs which displayed the problem had any pty's open). I am using the generic emul_exec.c and exec_file.c in the emulator now so the MD version can go. The only problem I had was that the emulator makefile (odemake) doesn't build or link exec_file.o. I couldn't see a clean fix for this and so I just made a symbolic link from the server exec_file.c to emulator/extra/exec_file.c. There must be a better way! I guess I will give the gnumake environment a try. Ian From jvh@cs.hut.fi Tue Nov 15 20:18:06 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 16 Nov 1994 05:09:53 +0200 (5.65c8/HUTCS-C 1.3 for lites); Wed, 16 Nov 1994 05:09:53 +0200 Date: Wed, 16 Nov 1994 05:09:53 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot, Changes, TODO list. Organization: Helsinki University of Technology, CS Lab. There is a new snapshot in leia.cs.hut.fi:foggy/lites/LITES.941116.tar.gz It doesn't differ from the previous intermediate snapshot that much but has a few fixes. Here are some changes from a period of about two weeks. - mapped gettimeofday is now enabled on all i386 configurations by default. The kernel crash is avoided by not inheriting the kernel page but instead remapping after fork. Somebody ought to fix the kernel in the future but the problem is no longer acute. Linux gettimeofday is now 500 times faster (in the worst vs. best case). The char devices /dev/time (25,0) and /dev/timezone (26,0) are needed (use mknod). - The server now uses Mach error numbers everywhere. The emulator translates the errors to a suitable errno depending on the running binary. sys/errno.h hides the differences. For source compatibilty reasons the server uses the traditional defines. The numeric values are just different. mach_error_string may be used to get a string corresponding to the internal error code. NOTE: mach_error_string has a bug that makes it return NULL sometimes. The explanation is simply that the library code assumes it is doing unsigned coparisons. Unfortunately kern_return_t (and transitively mach_error_t) is signed. Either libmach or kern_return.h needs to be fixed. - There is a preliminary mips port. The server works, binaries are loaded, system calls are performed. No signals, no Ultrix support yet. I might continue on this if I have time (I doubt it). Two CMU files in the mips port are not included in the list of files I have signed from CMU. They must be either replaced or cleared in a future additional list. - The server and emulator now share a new exec code. The exec is divided in more stages: - find file and fetch header - look at header and guess what binary it is - parse header according to guess and turn it into internal representation. Currently AOUT, ECOFF, and SOM are supported. The internal form is an array of sections and a load info struct. - walk through the sections and call a mapping method for each.. - Setup the execution environment according to the load info. BSS dirty page clearing used to be a pain from the server. The server now sets two registers in the user thread (it calls thread_set_state anyways) and ecrt0.c does the zeroing. In the emulator exec it is simpler: just bzero the area. ecrt0.c is a machine dependent part of the emulator. The register reading is easy to do with gcc asm variables. - The signal code is patched to work a little more. It is still a mess and needs a total redesign. - Job control works with Linux programs. Signal numbers are translated in more places such as wait4. - Lite system calls are on by default. The e_lite_sysent.c could be made MI soon. - There is a new alternative build environment that uses gmake, autoconf, and a couple of scripts. ODE still works but will probably deteriorate over time. conf/* has new configuration files. server/conf/* is ODE. For ODE to survive a bit longer it should be chnaged to use the configuration scripts in conf/* instead of the config program and related scripts. The gmake environment is most notably missing shadowing which shouldn't be impossible to add. Cross compilation works with both environments. The emulator building should be more similar to the server building. The emulator make files automatically picks up all files it can find. I don't think this is a particularly good idea. A simple list of files in the makefile makes it possible to be more selective. - SysV shared memory for making Doom faster. The totally emulator implementation makes files in /tmp/shm/ and pages to them. /etc/rc needs to create the directory and empty it on boot. The implementation is still untested as my X server binary did not support shared memory extensions. An X server with this feature is needed. - STD+WS now works without +DEBUG also on i386 This was due to mapin_user not initializing the address given to vm_map. vm_map's anywhere option is TRUE but it seems the kernel only scans from the given address forward and gives up when it hits the end. I think this behavior is ok even if not really expected. The simple fix is to zero the address hint always. TODO ---- - A library for code common to the server and emulator and perhaps later other programs. At least exec_file.c, bcopy etc., ntoh, and so on could be moved there. Requires changes to the build system. - Figure out how to avoid deadlocking risks arising from printf calling functions taking locks. Printf is called in a large variety of places where all kinds of locks may be held. Printing to ttys, selwakeup, etc. in this situation creates a big potential for deadlock. I added a comment next to printf noting this problem. - Fix and test build environment so that building on Linux and BSD really works. - Enhance the sysv support to make it real. - 64 bit cleanup. - Add support for Linux and or BSD X servers. This is mostly related to virtual consoles I think. - Write /sbin/cored -- the core dumping daemon. - Experiment with +ether_as_syscall and get it to work enough to make it default. This is about running protocol stacks on the network input thread instead of going through netisrs. It is important for simplifying splx and the whole spl mechanism. Also network latency ought to decrease. The first select in inetd didn't wake up last time I tried. After this I've fixed some bug related to select but there are still some uncertainty related to sockets so this might be a difficult thing to debug. - Fix /proc and other Lite stuff that is in conf/MASTER.h listed in the UNTESTED, ALMOST, and NOTYET categories. More later. Johannes From shap@viper.cis.upenn.edu Tue Nov 15 21:24:50 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 16 Nov 1994 06:14:50 +0200 (1.37.109.4/16.2) id AA26610; Tue, 15 Nov 94 23:16:31 -0500 Date: Tue, 15 Nov 94 23:16:31 -0500 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: jvh@cs.hut.fi Cc: lites@cs.hut.fi In-Reply-To: <199411160309.AA25572@laphroaig.cs.hut.fi> (message from Johannes Helander on Wed, 16 Nov 1994 05:09:53 +0200) Subject: Re: Snapshot, Changes, TODO list. - Figure out how to avoid deadlocking risks arising from printf calling functions taking locks. Printf is called in a large variety of places where all kinds of locks may be held. Printing to ttys, selwakeup, etc. in this situation creates a big potential for deadlock. We had the same problem in the KeyKOS implementation for the i386. Perhaps the solution we used will be adaptable. The KeyKOS kernel contains a small circular buffer. Printf output was dropped in this buffer rather than directly to the output channel. In the KeyKOS system, there exists a user-level task that sits on the equivalent of a receive port that gets woken up when the buffer is non-empty. In the event that the kernel panics, just before halting, we reset the video subsystem (might be running X!) and print the entire buffer to the screen (on the theory that the last several lines were probably sent to a window that has since been eliminated by the video mode switch. Similar tricks can be used for kernel debuggers. If you're really brave you can switch back and forth between the X video mode and the console video mode. We were not so brave. Hope the idea is helpful. From law@snake Wed Nov 16 15:35:04 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 00:25:58 +0200 id PAA28772; Wed, 16 Nov 1994 15:25:34 -0700 To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: Snapshot, Changes, TODO list. Reply-To: law@cs In-Reply-To: Your message of Wed, 16 Nov 94 05:09:53 +0200. <199411160309.AA25572@laphroaig.cs.hut.fi> Date: Wed, 16 Nov 94 15:25:33 MST From: Jeffrey A Law In message <199411160309.AA25572@laphroaig.cs.hut.fi> you write: > BSS dirty page clearing used to be a pain from the server. > The server now sets two registers in the user thread (it calls > thread_set_state anyways) and ecrt0.c does the zeroing. > In the emulator exec it is simpler: just bzero the area. > ecrt0.c is a machine dependent part of the emulator. The > register reading is easy to do with gcc asm variables. The only thing that make me worry about this change is some object formats have more than one bss-like section. One for small uninitialized blocks, typically called .sbss or $SHORT_BSS$, another for the rest of the uninitialized data blocks .bss $BSS$. [ In fact for PA/SOM, you can end up with 3 or even more when using the HP V9 compilers... ] Of course you can pass more start/size pointers in registers (or in memory as we have to do with MK83 on the PA). The world isn't a 3-segment a.out binary, and we need to keep that in mind.... Jeff From jvh@cs.hut.fi Wed Nov 16 15:50:33 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 00:44:08 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 17 Nov 1994 00:43:27 +0200 Date: Thu, 17 Nov 1994 00:43:27 +0200 From: Johannes Helander To: law@cs Cc: lites@cs.hut.fi Subject: Re: Snapshot, Changes, TODO list. In-Reply-To: <28770.785024733@snake.cs.utah.edu> References: <199411160309.AA25572@laphroaig.cs.hut.fi> <28770.785024733@snake.cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Jeffrey A. Law writes: > In message <199411160309.AA25572@laphroaig.cs.hut.fi> you write: > > > BSS dirty page clearing used to be a pain from the server. > > The server now sets two registers in the user thread (it calls > > thread_set_state anyways) and ecrt0.c does the zeroing. > > In the emulator exec it is simpler: just bzero the area. > > ecrt0.c is a machine dependent part of the emulator. The > > register reading is easy to do with gcc asm variables. > The only thing that make me worry about this change is some object > formats have more than one bss-like section. One for small > uninitialized blocks, typically called .sbss or $SHORT_BSS$, another > for the rest of the uninitialized data blocks .bss $BSS$. Sure. There is a method in exec file for doing the rest the hard way. I bothered implementing them only for whole pages but there is no reason why you couldn't do it for smaller pieces (as was always done before). In most cases there is one small piece of dirty memory that needs to be zeroed. The current implementation optimizes this case. Large pieces with whole pages is like the BSS residue that you just make EXEC_M_ZERO_ALLOCATE. Doesn't matter how many of these you have. > [ In fact for PA/SOM, you can end up with 3 or even more when > using the HP V9 compilers... ] sbss sections? Then you need to implement EXEC_M_MAP_PARTIAL or EXEC_M_ZERO or whatever you need. I didn't need them so I didn't write them. > Of course you can pass more start/size pointers in registers > (or in memory as we have to do with MK83 on the PA). If that is a common case you might want to do it. Otherwise just use vm_* kernel calls. Johannes PS. If i understand correctly the difference between .sbss and .bss I do in fact split an a.out BSS into one .sbss and one .bss. (The .sbss is handled through the zeroing magic and the .bss section through vm_mapping anonymous memory). From jvh@cs.hut.fi Wed Nov 16 18:39:12 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 03:33:20 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 17 Nov 1994 03:33:19 +0200 Date: Thu, 17 Nov 1994 03:33:19 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Namei macros added Organization: Helsinki University of Technology, CS Lab. I added the following namei expansions together with Juki @sys expands to i386_lites, mips_lites, etc. per system basis @cpu expands to i386, mips, ns532, ... @host expands to the host name. @bin expands like @sys but per binary basis depending on what kind of a binary is being executed. The strings are i386_linux, i386_freebsd, i386_netnsd, i386_ux, mips_ultrix, etc. (Comments about the name choices are welcome: see exec_file.h) The macros are expanded by namei. A path component must be the literal string (the macro must occupy an entire path component). Symlinks may contain namei macros. The idea is to make it easier to have several sets of binaries on the same machine and to make switching between OSs easier. For example FreeBSD and NetBSD use the same names and paths for shared libraries. However, they are not compatible with each other. @bin may be used to distinguish (make a symlink containing @bin). Another otherwise hard case is device numbers. Now you may have two /dev directories and choose on runtime. Create /@sys in Linux, and move dev there. ln -s /@sys/dev /dev. Create /i386_lites/dev and create the suitable devices there. Now both Lites and Linux will work (in this respect). @host and @cpu might be nice sometimes so they got added too. But more than that I think is too much so now @uid, @pid, @date, or was added. I didn't make it default yet. Build with +atsys for now. That can be done from configure by giving the option --with-config=STD+WS+atsys A diff and new snapshot are available in the usual place. Johannes From DALL@HFRD.DSTO.GOV.AU Wed Nov 16 19:52:07 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 04:44:22 +0200 13:12:50 +1030 Date: Thu, 17 Nov 94 13:14:07 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Namei macros added In-Reply-To: <199411170133.AA02232@laphroaig.cs.hut.fi> References: <199411170133.AA02232@laphroaig.cs.hut.fi> X-Hfrd: 1994111713113595 Johannes Helander writes: > I added the following namei expansions together with Juki > @sys expands to i386_lites, mips_lites, etc. per > system basis @cpu expands to i386, mips, ns532, ... @host expands > to the host name. @bin expands like @sys but per binary basis > depending on what kind of a binary is being executed. The strings > are i386_linux, i386_freebsd, i386_netnsd, i386_ux, mips_ultrix, > etc. (Comments about the name choices are welcome: see > exec_file.h) Something to provide this functionality is a great idea. What happens if a) there is already a file really called @sys? and b) you want to create a file really called @sys? I'd imagine the macro expansion should only happen if a file of that name doesn't exist. Ian From jvh@cs.hut.fi Thu Nov 17 03:10:54 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 12:05:12 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 17 Nov 1994 12:04:55 +0200 Date: Thu, 17 Nov 1994 12:04:55 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Namei macros added In-Reply-To: <9411170244.AA22164@hfrd.dsto.gov.au> References: <199411170133.AA02232@laphroaig.cs.hut.fi> <9411170244.AA22164@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > Something to provide this functionality is a great idea. What happens > if a) there is already a file really called @sys? and b) you want to > create a file really called @sys? > > I'd imagine the macro expansion should only happen if a file of > that name doesn't exist. One alternative we thought of is not to expand it in the leaf component of a path. This wouldn't be too hard to do. However, it might be confusing and it would be different from AFS/DFS @sys expansion. We also thought about various quoting mechanisms but then how do you quote the quoting etc. Gets messy. Johannes From brezak@apollo.hp.com Thu Nov 17 07:46:13 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 16:40:19 +0200 (1.37.109.13/15.5+ECS 3.3) id AA245493211; Thu, 17 Nov 1994 06:40:11 -0800 for lites@cs.hut.fi To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: Namei macros added In-Reply-To: Your message of "Thu, 17 Nov 1994 03:33:19 +0200." <199411170133.AA02232@laphroaig.cs.hut.fi> X-Mailer: exmh version 1.4.1 7/21/94 Date: Thu, 17 Nov 1994 09:40:10 -0500 From: John Brezak Great - I've wanted these for some time. However what if a specific filesystem has their of interpretation of these special names ? Specifically AFS and DFS. Also are these compiled in values or can they be set at runtime through some syscall (sysctl() and/or uname() ?). > I added the following namei expansions together with Juki > > @sys expands to i386_lites, mips_lites, etc. per system basis > @cpu expands to i386, mips, ns532, ... > @host expands to the host name. > @bin expands like @sys but per binary basis depending on what kind > of a binary is being executed. The strings are > i386_linux, i386_freebsd, i386_netnsd, i386_ux, mips_ultrix, > etc. (Comments about the name choices are welcome: see > exec_file.h) > > The macros are expanded by namei. A path component must be the > literal string (the macro must occupy an entire path component). > Symlinks may contain namei macros. > > The idea is to make it easier to have several sets of binaries on the > same machine and to make switching between OSs easier. For example > FreeBSD and NetBSD use the same names and paths for shared libraries. > However, they are not compatible with each other. @bin may be used to > distinguish (make a symlink containing @bin). > > Another otherwise hard case is device numbers. Now you may have two > /dev directories and choose on runtime. Create /@sys in Linux, and > move dev there. ln -s /@sys/dev /dev. Create /i386_lites/dev and > create the suitable devices there. Now both Lites and Linux will work > (in this respect). > > @host and @cpu might be nice sometimes so they got added too. But > more than that I think is too much so now @uid, @pid, @date, or > was added. > > I didn't make it default yet. Build with +atsys for now. That can be > done from configure by giving the option --with-config=STD+WS+atsys > > > A diff and new snapshot are available in the usual place. > > Johannes =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5140 From shap@viper.cis.upenn.edu Thu Nov 17 08:34:09 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 17:28:40 +0200 (1.37.109.4/16.2) id AA26551; Thu, 17 Nov 94 10:30:21 -0500 Date: Thu, 17 Nov 94 10:30:21 -0500 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: jvh@cs.hut.fi Cc: lites@cs.hut.fi In-Reply-To: <199411170133.AA02232@laphroaig.cs.hut.fi> (message from Johannes Helander on Thu, 17 Nov 1994 03:33:19 +0200) Subject: Re: Namei macros added Johannes: Did you see the note about page 0 problems running lites under linux/mach4? I looked briefly at the mach4 kernel, and it does not appear to be unmapping page 0. Is it possible that lites is doing something whose effect is to unmap page 0 of the lites image? I can think of a couple workarounds from the linux end, but I'ld like to understand the problem before trying to fix it (how's that for radical!). Jonathan From shap@viper.cis.upenn.edu Thu Nov 17 08:54:24 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 17:48:16 +0200 (1.37.109.4/16.2) id AA26554; Thu, 17 Nov 94 10:49:36 -0500 Date: Thu, 17 Nov 94 10:49:36 -0500 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: dall@HFRD.DSTO.GOV.AU Cc: jvh@cs.hut.fi, lites@cs.hut.fi In-Reply-To: <9411170244.AA22164@hfrd.dsto.gov.au> (message from Ian Dall on Thu, 17 Nov 94 13:14:07 +1030) Subject: Re: Namei macros added > I added the following namei expansions together with Juki > @sys expands to i386_lites, mips_lites, etc. per > system basis @cpu expands to i386, mips, ns532, ... Something to provide this functionality is a great idea. What happens if a) there is already a file really called @sys? and b) you want to create a file really called @sys? I'd imagine the macro expansion should only happen if a file of that name doesn't exist. Johannes does so much great work for all of us that I was going to keep my mouth shut, but people are already identifying problems with this, so... As a temporary solution this is a very reasonable thing to do. In the long term it strikes me as a kludge, and I'm leary of it. I suggest that a better long-term solution is to use per-process path prefixes similar to the approach used by sprite, plan-9, and the hurd. In this approach, each process has a list of path prefixes against which file names are resolved. Within the kernel, each prefix names the server that supplies the files that begin with that prefix. For example, a lites process might carry the following prefix table: /usr/bin -- lites-specific files in /usr/bin /usr/lib -- lites-specific files in /usr/lib /bin -- lites-specific files in /bin /lib -- lites-specific files in /lib /etc -- lites specific files in /etc / -- / files used by all architectures This achieves the same goal without putting a kludge in the kernel, and has the advantage that it subsumes the need for 'mount'. Note, however, that some important problems remain unsolved in either proposal: 1. Under this model, (or Johannes') there is no single /bin that carries a unified view of all available binaries. 2. Many files, even in /bin, can be shared across implementations (e.g. most of the shell scripts). This mechanism does not support that. 3. As programs are installed, there will tend to be overlap among the various bin directories. There is no easy solution to this. The mechanism I describe deliberately does not do transparent lookup. Adding two /bin entries solves problems (1) and (2), but creates ambiguities about which directory new files should be created in. The point, I suppose, is that this problem does not have a simple solution. Jonathan From csb@ullman.elte.hu Thu Nov 17 10:11:27 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 17 Nov 1994 19:05:15 +0200 1994 18:04:07 +0200 1994 18:03:45 +0100 Date: Thu, 17 Nov 1994 18:03:45 +0100 (NFT) From: Csizmazia Balazs Subject: Re: Namei macros added To: Jonathan Shapiro Cc: jvh@cs.hut.fi, lites@cs.hut.fi In-Reply-To: <199411171528.AA21064@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! On Thu, 17 Nov 1994, Jonathan Shapiro wrote: > Did you see the note about page 0 problems running lites under linux/mach4? > I looked briefly at the mach4 kernel, and it does not appear to be > unmapping page 0. Is it possible that lites is doing something whose > effect is to unmap page 0 of the lites image? Yes, Lites unmaps it (in file ~server/serv/server_init.c main() function), and not the Mach4. > I can think of a couple workarounds from the linux end, but I'ld like > to understand the problem before trying to fix it But Johannes wrote the solutions: 1.) either uncomment that system call (the vm_protect one) it's only to debug Lites. 2.) or use the -qmagic link flags (I posted the mail him too - not only to the Mach4-users mailing list, and thus You haven't got his answer). Regards: Csizmazia Balazs csb@ullman.elte.hu From DALL@HFRD.DSTO.GOV.AU Thu Nov 17 17:28:57 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 18 Nov 1994 02:20:57 +0200 10:50:34 +1030 Date: Fri, 18 Nov 94 10:51:58 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: Stack alignment bug + patches X-Hfrd: 1994111810492356 All comments are for the 941116 snapshot. I ran into a tricky bug: $ cat > foo #!/bin/sh echo foo ^D $ chmod a+x foo foo --- core dumped $ sh foo foo ie. Explicitly running the shell with a script as an argument worked fine, but using #! to specify an interpreter didn't. If I changed the interpreter to bash it would work. It turns out that the problem is that bsd_msg in emul_generic.c wasn't aligned to an int boundary. Then the code which gets that data out of the message and into user space goes wrong after it aligns the pointer to an integer boundary, when what is really required is that the *offset* from the start of bsd_msg should be rounded up modulo sizeof int. System calls with only one return value were OK but sysctl caused problems. Amusingly, following the above example, $ ln foo foo1 $ foo1 foo works. This begs the question, why is bsd_msg misaligned? On some machines that would be fatal much earlier. It turns out that the problem is when space is made on the stack for the arguments. Normally, this is just pointers, but when an interpreter is used, some extra strings go on the stack. I have fixed this two ways. I've made emul_generic more robust, and I have fixed the alignment in emul_init. I have also revisited the TEXT_START_TRUNC issue. I have made it so that it it evaluates to max(vm_page_size, entry point truncated to a 16MB boundary) All the extra arbitrary extra pages then go from emulator_base. This seems to me marginally more elegant in so far as you believe EMULATOR_BASE. In error_codes.c, I independently arrived at if (kr == ERESTART || kr == EJUSTRETURN) return kr; wheras in the nov 16 snapshot if (kr == ERESTART) return kr; The EJUSTRETURN looked right to me, but I don't know for sure if it is necessary or not. The ns532 has been tested (and works) with the mapped time code. The other changes are mainly minor build environment changes. I am still using odemake although I am planning to give the gmake environment a try. Ian *** ../../../hut/src/lites/./emulator/Makefile Fri Nov 4 12:03:53 1994 --- ./emulator/Makefile Tue Nov 15 20:34:23 1994 *************** *** 69,75 **** DEFINES = -DCMU=1 -DTypeCheck=0 -DMACH_IPC_COMPAT=0 -DCOMPAT_43 -DEMULATOR -DMAP_UAREA=1 -DNFS -DLITES -DASYNCH_SIGNALS CFLAGS = ${DEFINES} -g -nostdinc -I- ! PC532_CFLAGS = -mhimem -DGNU_LD2 MIGFLAGS = ${DEFINES} ASFLAGS = ${${TARGET_MACHINE}ASFLAGS} --- 69,75 ---- DEFINES = -DCMU=1 -DTypeCheck=0 -DMACH_IPC_COMPAT=0 -DCOMPAT_43 -DEMULATOR -DMAP_UAREA=1 -DNFS -DLITES -DASYNCH_SIGNALS CFLAGS = ${DEFINES} -g -nostdinc -I- ! PC532_CFLAGS = -mhimem -DGNU_LD2 -Dns532 MIGFLAGS = ${DEFINES} ASFLAGS = ${${TARGET_MACHINE}ASFLAGS} *************** *** 102,114 **** runit_OFILES = ${COMMON_OFILES} runit.o libsys_support.o zprintbsd_OFILES= zprintbsd.o bsd_1_user.o process_self.o ! i386_EMULATOR_OFILES = e_linux_sysent.o e_linux_trampoline.o emul_exec.o \ e_isc4_sysent.o e_sysv_stubs.o e_cmu_43ux_sysent.o e_lite_sysent.o ! ns532_EMULATOR_OFILES = e_cmu_43ux_sysent.o e_lite_sysent.o memcmp.o \ ! ns532_emul_exec.o ! parisc_EMULATOR_OFILES = e_hpbsd_sysent.o e_hpbsd_stubs.o emul_exec.o ! EMULATOR_OFILES = ${COMMON_OFILES} emul_vector.o \ e_trampoline.o e_exception.o e_mach_msg_server.o \ e_stat.o e_bnr_stubs.o \ ${${target_cpu}_EMULATOR_OFILES} --- 102,113 ---- runit_OFILES = ${COMMON_OFILES} runit.o libsys_support.o zprintbsd_OFILES= zprintbsd.o bsd_1_user.o process_self.o ! i386_EMULATOR_OFILES = e_linux_sysent.o e_linux_trampoline.o \ e_isc4_sysent.o e_sysv_stubs.o e_cmu_43ux_sysent.o e_lite_sysent.o ! ns532_EMULATOR_OFILES = e_cmu_43ux_sysent.o e_lite_sysent.o memcmp.o ! parisc_EMULATOR_OFILES = e_hpbsd_sysent.o e_hpbsd_stubs.o ! EMULATOR_OFILES = ${COMMON_OFILES} emul_vector.o emul_exec.o exec_file.o\ e_trampoline.o e_exception.o e_mach_msg_server.o \ e_stat.o e_bnr_stubs.o \ ${${target_cpu}_EMULATOR_OFILES} *************** *** 123,129 **** e_cmu_43ux_sysent.o zprintbsd.o process_self.o \ testprog.o libsys_support.o e_signal.o e_bnr_stubs.o e_stat.o \ e_uname.o e_mapped_time.o e_readwrite.o \ ! e_hpbsd_sysent.o e_hpbsd_stubs.o e_sysvipc.o .include <${RULES_MK}> --- 122,128 ---- e_cmu_43ux_sysent.o zprintbsd.o process_self.o \ testprog.o libsys_support.o e_signal.o e_bnr_stubs.o e_stat.o \ e_uname.o e_mapped_time.o e_readwrite.o \ ! e_hpbsd_sysent.o e_hpbsd_stubs.o e_sysvipc.o exec_file.o .include <${RULES_MK}> *** ../../../hut/src/lites/./emulator/emul_generic.c Fri Jul 1 12:46:52 1994 --- ./emulator/emul_generic.c Fri Nov 18 01:19:24 1994 *************** *** 162,172 **** if (tp->msgtl_header.msgt_inline) { bcopy(start, (char *)user_addr, size); - start += size; /* data is rounded to int-size */ ! start = (char *) ! ( ((vm_offset_t)start + sizeof(int) - 1) ! & ~(sizeof(int) - 1) ); } else { msg_addr = *(vm_address_t *)start; start += sizeof(vm_address_t); --- 162,171 ---- if (tp->msgtl_header.msgt_inline) { bcopy(start, (char *)user_addr, size); /* data is rounded to int-size */ ! size = ( ((vm_offset_t)size + sizeof(int) - 1) ! & ~(sizeof(int) - 1) ); ! start += size; } else { msg_addr = *(vm_address_t *)start; start += sizeof(vm_address_t); *** ../../../hut/src/lites/./emulator/emul_init.c Sun Nov 13 04:14:25 1994 --- ./emulator/emul_init.c Fri Nov 18 07:51:51 1994 *************** *** 27,32 **** --- 27,35 ---- */ /* * HISTORY + * 18-Nov-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Make sp aligned to an int boundary after args are loaded. + * * $Log: $ * */ *************** *** 190,195 **** --- 193,200 ---- if (with_kframe) space_needed += sizeof(int); + /* Round up to int boundary to keep stack aligned*/ + space_needed = (space_needed + sizeof(int) - 1) & ~(sizeof(int) - 1); #if 0 /* The server now makes the stack big enough */ if ((space_needed > vm_page_size) && 0) { *** ../../../hut/src/lites/./emulator/error_codes.c Wed Nov 9 22:58:54 1994 --- ./emulator/error_codes.c Wed Nov 16 22:45:44 1994 *************** *** 116,122 **** if (kr == KERN_SUCCESS) return 0; ! if (kr == ERESTART) return kr; /* First collapse all errors into Lites errors */ --- 116,122 ---- if (kr == KERN_SUCCESS) return 0; ! if (kr == ERESTART || kr == EJUSTRETURN) return kr; /* First collapse all errors into Lites errors */ *** ../../../hut/src/lites/./emulator/ns532/e_cmu_43ux_sysent.c Tue Oct 25 20:08:50 1994 --- ./emulator/ns532/e_cmu_43ux_sysent.c Wed Nov 16 22:58:11 1994 *************** *** 182,188 **** sysg(e_recvmsg, 3), /* 113 */ sysg(e_sendmsg, 3), /* 114 */ sysg(e_nosys, 2), /* 115 */ ! #if 0 sysg(e_mapped_gettimeofday, 2), /* 116 */ #else sysg(e_gettimeofday, 2), /* 116 */ --- 182,188 ---- sysg(e_recvmsg, 3), /* 113 */ sysg(e_sendmsg, 3), /* 114 */ sysg(e_nosys, 2), /* 115 */ ! #if 1 sysg(e_mapped_gettimeofday, 2), /* 116 */ #else sysg(e_gettimeofday, 2), /* 116 */ *** ../../../hut/src/lites/./emulator/ns532/e_lite_sysent.c Wed Nov 2 20:49:26 1994 --- ./emulator/ns532/e_lite_sysent.c Thu Nov 17 08:13:51 1994 *************** *** 84,89 **** --- 84,91 ---- int e_lite_setrlimit(), e_lite_getdirentries(); int e_lite_wait4(), e_lite_mmap(); + int e_mapped_gettimeofday(); + struct sysent e_bsd_sysent[] = { SYS_NULL(e_indir), /* 0 */ sysg(exit, 1), /* 1 */ *************** *** 201,207 **** sysg(e_recvmsg, 3), /* 113 */ sysg(e_sendmsg, 3), /* 114 */ sysg(e_nosys, 2), /* 115 vtrace unimplimented*/ ! sysg(e_gettimeofday, 2), /* 116 */ sysg(e_getrusage, 2), /* 117 */ sysg(e_getsockopt, 5), /* 118 */ sysg(e_nosys, 0), /* 119 */ --- 203,213 ---- sysg(e_recvmsg, 3), /* 113 */ sysg(e_sendmsg, 3), /* 114 */ sysg(e_nosys, 2), /* 115 vtrace unimplimented*/ ! #if 1 ! sysg(e_mapped_gettimeofday, 2), /* 116 */ ! #else ! sysg(e_gettimeofday, 2), /* 116 */ ! #endif sysg(e_getrusage, 2), /* 117 */ sysg(e_getsockopt, 5), /* 118 */ sysg(e_nosys, 0), /* 119 */ *** ../../../hut/src/lites/./emulator/ns532/e_trampoline.c Wed Nov 16 02:02:44 1994 --- ./emulator/ns532/e_trampoline.c Tue Nov 15 20:07:08 1994 *************** *** 128,133 **** --- 128,138 ---- int pc; }; + errno_t e_htg_syscall(...) + { + return e_mach_error_to_errno(LITES_ENOSYS); + } + /* * Wait has a weird parameter passing mechanism. */ *************** *** 202,207 **** --- 207,213 ---- return ESUCCESS; } + errno_t ns532_e_vfork( int *argp, int *rval, *************** *** 217,222 **** --- 223,233 ---- else rval[1] = 1; /* child r0 = 1 */ return ESUCCESS; + } + + errno_t ns532_e_htg_syscall(...) + { + return e_mach_error_to_errno(LITES_ENOSYS); } /* *** ../../../hut/src/lites/./emulator/programs/emulator_base.c Fri Nov 4 11:45:19 1994 --- ./emulator/programs/emulator_base.c Fri Nov 18 01:40:29 1994 *************** *** 45,57 **** #else #ifdef mips printf("%x -D %x\n", ! EMULATOR_BASE + 0x1000, EMULATOR_BASE + (1024*1024)); #else #if defined(PC532) && defined(GNU_LD2) ! printf("%lx\n", EMULATOR_BASE + sizeof (struct exec) + 0x1000); #else ! printf("%x\n", EMULATOR_BASE + 0x1000); #endif #endif #endif --- 45,57 ---- #else #ifdef mips printf("%x -D %x\n", ! EMULATOR_BASE, EMULATOR_BASE + (1024*1024)); #else #if defined(PC532) && defined(GNU_LD2) ! printf("%lx\n", EMULATOR_BASE + sizeof (struct exec)); #else ! printf("%x\n", EMULATOR_BASE); #endif #endif #endif *** ../../../hut/src/lites/./server/conf/MASTER Wed Nov 2 21:04:33 1994 --- ./server/conf/MASTER Fri Nov 4 23:41:47 1994 *************** *** 28,33 **** --- 28,36 ---- # # # HISTORY + # 28-Sep-94 Ian Dall (dall@hfrd.dsto.gov.au) + # Dropped gprof from DEBUG. Debugging and profiling are orthogonal. + # # $Log: $ # *************** *** 82,88 **** # Everything that is known to work # LARGE = [ STD ] # ! # DEBUG = [ debug machid_register lineno diagnostic assertions queue_assertions gprof ] # # Compiles but untested. # UNTESTED = [ mfs umapfs union fdesc cd9660 portal lfs sl ns nsip lfs quota gateway mrouting ] --- 85,91 ---- # Everything that is known to work # LARGE = [ STD ] # ! # DEBUG = [ debug machid_register lineno diagnostic assertions queue_assertions noopt ] # # Compiles but untested. # UNTESTED = [ mfs umapfs union fdesc cd9660 portal lfs sl ns nsip lfs quota gateway mrouting ] *** ../../../hut/src/lites/./server/conf/ns532/files Wed Nov 2 20:59:51 1994 --- ./server/conf/ns532/files Wed Nov 16 23:26:59 1994 *************** *** 47,53 **** ns532/server/conf.c optional lites ns532/server/ns532_exception.c optional lites ns532/server/misc_asm.s optional lites - ns532/server/queue.c optional lites ns532/server/second_syscalls.s optional second_server libkern/bcmp.c standard --- 47,53 ---- ns532/server/conf.c optional lites ns532/server/ns532_exception.c optional lites ns532/server/misc_asm.s optional lites ns532/server/second_syscalls.s optional second_server + libkern/queue.c optional lites libkern/bcmp.c standard *** ../../../hut/src/lites/./server/serv/exec_file.c Wed Nov 16 09:54:32 1994 --- ./server/serv/exec_file.c Fri Nov 18 01:43:53 1994 *************** *** 295,301 **** * Use entry address to decide where to load. Truncate to 16M boundary. * Add 0x1000 in order to cope with standard QMAGIC loaded at 0x1000. */ ! #define TEXT_START_TRUNC(A) ((~((vm_address_t)0xffffff) & A) + vm_page_size) mach_error_t aout_parse_exec_file( struct aout_hdr *hdr, --- 295,301 ---- * Use entry address to decide where to load. Truncate to 16M boundary. * Add 0x1000 in order to cope with standard QMAGIC loaded at 0x1000. */ ! #define TEXT_START_TRUNC(A) (A < 0xffffff? vm_page_size: (~((vm_address_t)0xffffff) & A)) mach_error_t aout_parse_exec_file( struct aout_hdr *hdr, From DALL@HFRD.DSTO.GOV.AU Sun Nov 20 18:31:56 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 21 Nov 1994 03:26:31 +0200 10:45:05 +1030 Date: Mon, 21 Nov 94 10:46:40 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: bootstrap doesn't understand the new file system? X-Hfrd: 1994112110435761 If I try and boot lites as the first server, the mach bootstrap doesn't seem to understand the 4.4 file system. The complaint I get is can't find /mach_servers directory. The directory certainly is there! Has anyone made whatever changes are necessary to bootstrap? Another problem I have run into resulted in a panic with seqnos_memory_object_unlock unimplimented. It turns out that this seems to arise after a mmap with the MAP_SHARED flag set. This arose from running the NetBSD strip. I have temprarilly solved the problem by using a strip which doesn't use mmap. The NetBSD cp uses mmap, so I no that mmap does work in some circumstances, at least. The 4.3 executeables still seem very flakey in their signal handling. I compiled the current emacs 19 and bash in the lites environment and they seem to work pretty well. In that case it is debateable how much effort it makes sense to put into support for older binaries. >From a personal point of view, it is probably easier to recompile anything which gives trouble than find the bug in the server! On the other hand, if we are looking for a wide user base, the ability to run (on the appropriate machines) ultrix, SunOs and various i386 unix executeable seems pretty desirable. Ian From shap@viper.cis.upenn.edu Mon Nov 21 13:33:23 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 21 Nov 1994 22:26:25 +0200 (1.37.109.4/16.2) id AA14905; Mon, 21 Nov 94 11:29:20 -0500 Date: Mon, 21 Nov 94 11:29:20 -0500 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: dall@HFRD.DSTO.GOV.AU Cc: lites@cs.hut.fi In-Reply-To: <9411210016.AA09007@hfrd.dsto.gov.au> (message from Ian Dall on Mon, 21 Nov 94 10:46:40 +1030) Subject: Re: bootstrap doesn't understand the new file system? If I try and boot lites as the first server, the mach bootstrap doesn't seem to understand the 4.4 file system. The complaint I get is can't find /mach_servers directory. The directory certainly is there! There is an unresolved issue in identifying boot partitions in the mach4 kernel. For the time being you will need to recompile. Grep your mach4 sources for the string 'liXnux'. Change all instances to linux, and you will boot lites okay under linux. Per some other discussions here, however, the resulting lites may or may not work. Jonathan From jvh@cs.hut.fi Mon Nov 21 14:27:27 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 21 Nov 1994 23:18:23 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 21 Nov 1994 23:18:22 +0200 Date: Mon, 21 Nov 1994 23:18:22 +0200 From: Johannes Helander >From: Johannes Helander To: lites@cs.hut.fi Subject: A few fixes In-Reply-To: <9411210016.AA09007@hfrd.dsto.gov.au> References: <9411210016.AA09007@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. First of all thanks to Ian for the stack alignment fixes. I had seen the symptoms but didn't understand the problem. I merged that and added a few other fixes. - *_sigvec now call e_bnr_sigvec instead of contacting the server. The new function converts sigvec to a sigaction call. This hopefully fixes some sigvec problems (at least we should have only one set of problems now). - I added m_o_data_unlock. It always grants the requested access. This should be ok as access rights are checked on map time. If this is not correct in some case more state needs to be added to vn_pager_t. I didn't put in very much thought to this but instead just implemented a first version. - vnode_pager_uncache now also flushes cached pages and not only marks the memory object uncached. This is the right thing to do in some cases where the function is called. vnode_pager_uncache is also supposed to return info on whether or not the object was terminated. All uses should be checked more carefully and perhaps more specialized interfaces added. - fsync now attempts to do some cleaning of memory objects too. More needs to be added. What is missing is 1) waiting for cleaning to complete when fsync is asked to wait and 2) calling vn_page_sync from all *fs_sync calls. The sync code is distributed and every file system has its own even if the buffer cache is common and there would seem to be a lot of common code (with some new added). Anyways, ffs_sync now also starts some pageout on objects associated with files. The syncing needs some more work. Also msync should be implemented. This is slightly problematic since the server doesn't know what objects are mapped where and nor does the emulator. However, the emulator could do some vm_region calls and use the name port to identify to the server what needs to be cleaned. This would preserve the roles: the server does access control and provides backing store. The emulator (and the task itself) is responsible for the address space. In general the vnode pager would benefit from some work. The current one I originally wrote as a quick hack to make demand paged binaries work but it seems to be rather extendable -- at least adding writing didn't take any more time than writing this mail. To do things efficiently we should add new VFS interfaces for just moving pages instead of copying and caching them. But that is already more work. I put a new diff in Leia. I didn't test the code almost at all but it's there if someone wants to have it. I'll do some testing etc. after changing to John's newer buffer cache (tomorrow or later). BTW, Ian. I didn't quite understand why you disliked the one page offset in loading emulators. I think there are two reasons why the offset is a good idea: 1) QMAGIC binaries (which I consider default a.out) by default start at 0x1000. Keeping the same one page offset around later makes the transformation more linear (just add a gigabyte or so). 2) It is convenient to have some place that keeps constant where to put magic pointers for binary compat trampolines. I've now put a page for Linux rather-fast-emulation somewhere later in the emulator space. Putting it right at the beginning would seem nicer as then EMULATOR_BASE could be used as the magic constant. If you have better reasons I will integrate your TEXT_START_TRUNC change. What do you think? Johannes From DALL@HFRD.DSTO.GOV.AU Mon Nov 21 20:14:14 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 22 Nov 1994 05:01:02 +0200 11:42:47 +1030 Date: Tue, 22 Nov 94 11:44:27 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: A few fixes In-Reply-To: <199411212118.AA06688@laphroaig.cs.hut.fi> References: <9411210016.AA09007@hfrd.dsto.gov.au> <199411212118.AA06688@laphroaig.cs.hut.fi> X-Hfrd: 1994112211414247 > BTW, Ian. I didn't quite understand why you disliked the one page > offset in loading emulators. I think there are two reasons why the > offset is a good idea: > 1) QMAGIC binaries (which I consider default a.out) by default start > at 0x1000. Keeping the same one page offset around later makes the > transformation more linear (just add a gigabyte or so). ZMAGIC on many machines starts at 1 page too. Who introduced QMAGIC anyway? Is it a linux'ism? This "linearity" doesn't seem a very strong reason. I can't think why you would ever want to calculate the text load address by addition to the default text load address. > 2) It is convenient to have some place that keeps constant where to > put magic pointers for binary compat trampolines. I've now put a > page for Linux rather-fast-emulation somewhere later in the > emulator space. Putting it right at the beginning would seem > nicer as then EMULATOR_BASE could be used as the magic constant. Essentially we are talking about two conventions for restricting the way you can link a.out executeables. One says they have to be linked with -Ttext nn000000, the other says they have to be linked with -Ttext nn001000. The former seems cleaner to me, but I don't have a *strong* opinion as, in practice, with the gnu ld2 you have to add the size of exec_header anyway which is pretty untidy too. The rules then are -Ttext nn000020 compared with -Ttext nn001020. If you want another region before EMULATOR_BASE, there really should be another variable or two. I'm not sure what it would be called. Say EXTRA_BASE and EXTRA_SIZE. If you one day need two pages instead of just one, then all you have to do is change EXTRA_SIZE and the new emulator gets linked and loaded at the right place. One problem I have with this, is it would break any "native" executeables. Currently emulator is the only one, but that might not always be true. My feeling is that EMULATOR_BASE should stay at 0xc0000000. Then the extra space you need could either be at 0xbffff000 or very high in virtual memory. Johannes> If you have better reasons I will integrate your Johannes> TEXT_START_TRUNC change. What do you think? I aren't all that worried. I think my approach is marginally better, but I agree it is only marginal. What is important is that the convention for how to load executeables doesn't keep changing. Ian From jkh@freefall.cdrom.com Mon Nov 21 20:52:16 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 22 Nov 1994 05:42:45 +0200 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Ian Dall Cc: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: A few fixes In-Reply-To: Your message of "Tue, 22 Nov 94 11:44:27 +1030." <9411220114.AA16599@hfrd.dsto.gov.au> Date: Mon, 21 Nov 1994 19:40:05 -0800 From: "Jordan K. Hubbard" > ZMAGIC on many machines starts at 1 page too. Who introduced QMAGIC > anyway? Is it a linux'ism? This "linearity" doesn't seem a very To the best of my knowledge, BSDI introduced QMAGIC. FreeBSD has standardised on it as part of an ongoing effort to be fully BSDI compatible. Jordan From shap@viper.cis.upenn.edu Tue Nov 22 10:34:49 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 22 Nov 1994 19:27:49 +0200 (1.37.109.4/16.2) id AA17673; Tue, 22 Nov 94 11:55:24 -0500 Date: Tue, 22 Nov 94 11:55:24 -0500 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: dall@HFRD.DSTO.GOV.AU Cc: jvh@cs.hut.fi, lites@cs.hut.fi In-Reply-To: <9411220114.AA16599@hfrd.dsto.gov.au> (message from Ian Dall on Tue, 22 Nov 94 11:44:27 +1030) Subject: Re: A few fixes > 2) It is convenient to have some place that keeps constant where to > put magic pointers for binary compat trampolines. I've now put a > page for Linux rather-fast-emulation somewhere later in the > emulator space. Putting it right at the beginning would seem > nicer as then EMULATOR_BASE could be used as the magic constant. In KeyKOS we had an analogous problem. The KeyKOS kernel is (on paper) not mapped into user space at all. We cheat, and I think the trick we used could be used for the trampoline logic as well. The i386 uses a two-level page table. Each entry in the upper level maps a 4M region. In theory, a KeyKOS process address space does not map the kernel. Unfortunately, most processors don't let us seperate things so cleanly. Here is how we do it: At startup time, the kernel chooses two first-level PTE slots. One is used for kernel text, the other for the per-process save area. The same virtual region pair is used in ALL processes. We use the region as a staging area that gives us enough of a toe hold to save the current process state and load the real kernel mapping. We know how to find that because we hardwire the kernel's root page table at address zero, though any fixed address will do. If the process takes a legitemate access fault in the region currently occupied by the kernel, we move the kernel mapping up one slot in ALL first-level TLB's (including the kernel mapping table) and rewrite all of the interrupt vectors to point to the new location. On the i386 family, we cheat here again, and rewrite the kernel text and data segment entries in the global descriptor table rather than rewrite the interrupt vectors. [With a minimal amount of work it is possible to move the kernel to the next region that is known not to conflict.] We quickly discover a 4M region that is not used by any process, and the kernel stops "moving." When it was all over, we were surprised at how little performance cost this imposed. Once things stabilize, it's basically a single The point is that bouncing the trampoline area around may not be all that expensive if you choose your mapping address carefully. Essentially we are talking about two conventions for restricting the way you can link a.out executeables. One says they have to be linked with -Ttext nn000000, the other says they have to be linked with -Ttext nn001000. The former seems cleaner to me, but I don't have a *strong* opinion as, in practice, with the gnu ld2 you have to add the size of exec_header anyway which is pretty untidy too. The rules then are -Ttext nn000020 compared with -Ttext nn001020. GNU ld can be wired either to include the exec header in the text area or not. It should be included. The advantage is that it allows disk I/O to be page aligned, which eliminates the need for a kernel copy. The only other way to get this advantage is to put padding after the text header. I suggest that the only restriction be to reserve page 0 for "native" binaries. The trampoline issue cannot be allowed to decide this, since we aren't in a position to dictate the binary formats of the environments we wish to emulate. Jonathan From root@corbin.Root.COM Wed Nov 23 08:29:35 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 23 Nov 1994 17:11:16 +0200 X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Ian Dall Cc: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: A few fixes In-Reply-To: Your message of "Tue, 22 Nov 94 11:44:27 +1030." <9411220114.AA16599@hfrd.dsto.gov.au> From: David Greenman Reply-To: davidg@root.com Date: Wed, 23 Nov 1994 07:11:05 -0800 Sender: root@corbin.Root.COM >ZMAGIC on many machines starts at 1 page too. Who introduced QMAGIC >anyway? Is it a linux'ism? This "linearity" doesn't seem a very QMAGIC has been around for a long time. ZMAGIC has historicly been defined as starting at virtual address 0. It was later changed in SunOS and NetBSD to mean something quite different. BSDI and FreeBSD took the sensible approach and used the already established/defined 'QMAGIC' format for its original created purpose. -DG From sjlai@broncho.ct.monash.edu.au Wed Nov 23 13:24:06 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 23 Nov 1994 22:07:21 +0200 From: Simon Lai Subject: FreeBSD under Mach To: lites@cs.hut.fi Date: Thu, 24 Nov 1994 07:06:35 +1100 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 687 Hi, Please send info about FreeBSD under Mach. Sorry for the brevity. Thank you ------------------------------------------------------------------------------ Simon Lai | "Microsoft is not the answer. Microsoft sjlai@broncho.ct.monash.edu.au | is the question. NO is the answer." Department of Computer Technology, | -------------------------------------- Monash University (Caulfield Campus) | I claim all disclaimers. Caulfield 3145, Australia, Earth. | Take me to your leader !! -------------------------------------+----------------------------------------- Philospher's Union : "We demand rigidly defined areas of doubt and uncertainty" From karant@gallium.csusb.edu Wed Nov 23 13:31:18 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 23 Nov 1994 22:25:35 +0200 Date: Wed, 23 Nov 1994 12:20:10 -0800 From: karant@gallium.csusb.edu (Dr. Yasha Karant) To: lites@cs.hut.fi Subject: FreeBSD under Mach Jordan Hubbard has posted to one of the FreeBSD lists that you have FreeBSD running under Mach. We were going to be doing that, as we need a SMP version to run on servers and, eventually, certain research machines. Are you willing to release source? Can your implementation co-exist with other Mach front ends running on the same platform? If we need to sign non-disclosures, etc., please let me know. Thanks for any reply. Yasha Karant karant@gallium.csusb.edu From jvh@cs.hut.fi Wed Nov 23 15:55:31 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 24 Nov 1994 00:48:50 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 24 Nov 1994 00:48:28 +0200 Date: Thu, 24 Nov 1994 00:48:28 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: bootstrap doesn't understand the new file system? In-Reply-To: <9411210016.AA09007@hfrd.dsto.gov.au> References: <9411210016.AA09007@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > If I try and boot lites as the first server, the mach bootstrap > doesn't seem to understand the 4.4 file system. The complaint I get is > can't find /mach_servers directory. The directory certainly is there! > > Has anyone made whatever changes are necessary to bootstrap? This is most likely due to the change in the layout of struct dirent. As you can see below the d_namlen field has been split in two and effectively the d_namlen has been moved by 8 bits on a little endian machine. An example on how to convert can be seen in e_bnr_getdirentries() in emulator/e_bnr_stubs.c. Where in the bootstrap this change has to be made I haven't checked. Johannes struct dirent { unsigned long d_fileno; /* file number of entry */ unsigned short d_reclen; /* length of this record */ unsigned char d_type; /* file type, see below */ unsigned char d_namlen; /* length of string in d_name */ #ifdef _POSIX_SOURCE char d_name[255 + 1]; /* name must be no longer than this */ #else #define MAXNAMLEN 255 char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ #endif }; struct bnr_dirent { unsigned int d_fileno; unsigned short d_reclen; unsigned short d_namlen; char d_name[255 + 1]; }; errno_t e_bnr_getdirentries( int fd, char *buf, int nbytes, long *basep, int *nread) { struct dirent *de; unsigned int namlen; int n; errno_t err = e_lite_getdirentries(fd, buf, nbytes, basep, nread); /* * Convert Lite style direntries to net2 style direntries. The * size stays the same so the conversion is done in situ. */ if (!err && *nread >= sizeof(struct dirent)) { for (de = (struct dirent *) buf, n = 0; de->d_reclen != 0 && n < *nread; n += de->d_reclen, de = (struct dirent *)(buf + n) ) { ((struct bnr_dirent *)de)->d_namlen = de->d_namlen; } } return err; } From luigi@discovery.dia.unisa.it Thu Nov 24 02:09:27 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 24 Nov 1994 10:47:09 +0200 From: Luigi Catuogno Subject: Mach & FreeBSD To: lites@cs.hut.fi Date: Thu, 24 Nov 1994 09:53:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 612 Jordan K. Hubbard said me you ported FreeBSD under Mach kernel. Can you send me informations about doing that? Thanks :) -- ---------------------------------------------------------------- _/ _/_/_/ Luigi Catuogno _/ _/ e_mail: luigi@discovery.dia.unisa.it _/ _/ _/_/_/ _/ _/_/_/ _/ Phone +39 (81) 837-2700 ---------------------------------------------------------------- From hd@world.std.com Thu Nov 24 08:51:33 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 24 Nov 1994 17:42:22 +0200 id KAA00465; Thu, 24 Nov 1994 10:42:02 -0500 From: hd@world.std.com (HD Associates) Subject: FreeBSD and Mach To: lites@cs.hut.fi Date: Thu, 24 Nov 1994 10:17:07 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 314 Jordan says about FreeBSD and mach: > Send mail to lites@cs.hut.fi - they've done exactly that. Where can I find out more? Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 FAX: 508 433 5267 Pepperell, MA hd@world.std.com From chuckr@Glue.umd.edu Thu Nov 24 10:48:55 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 24 Nov 1994 19:39:42 +0200 Date: Thu, 24 Nov 1994 12:39:32 -0500 (EST) From: Chuck Robey To: lites@cs.hut.fi Subject: Mach Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I read the FreeBSD mail lists, and recently saw a comment that some work has been done here, adapting FreeBSD to run under Mach. Is that true, and could I maybe get some more information on your project, perhaps the location of any FAQ or other material? Thanks very much. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Esix SVR4) and n3lxx (FreeBSD) (301) 459-2316 | ----------------------------+----------------------------------------------- From jvh@kampi.hut.fi Fri Nov 25 01:41:19 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 25 Nov 1994 10:25:26 +0200 Date: Fri, 25 Nov 1994 06:58:23 +0200 From: Johannes Helander Sender: jvh@kampi.hut.fi To: lites@cs.hut.fi Subject: New snapshot Organization: Helsinki University of Technology, CS Lab. LITES.941125.tar.gz is available from leia:foggy/lites * Many 64 bit fixes from Juki. * ioctl cmds are now ioctl_cmd_t instead of int. This affects among other things conf.c files. * Lites is now compiled with -W and produces less noice than before without any options. * Boots multiuser on NetBSD 1.0 * Explicit memory object syncing is not done for now as it was too slow. An optimized version should be added later. * Several bugfixes here and there. * The emulator can now be used as a "shell interpreter" for running other binaries. For example ./emulator.test /usr/bin/emacs -d han:0 runs emacs with emulator.test as the emulator. (The emulator is not inherited, the default is used if not explicitely specified). * stdargs should be used instead of varargs. In most cases this is already true. * extern inlines are now called __INLINE__. This is normally extern inline but may be overridden. The intention is that one file defines __INLINE__ as empty and gets global entry points for out of line versions of the routines. Johannes From ldd@step.polymtl.ca Fri Nov 25 21:15:00 1994 (5.65c8/HUTCS-S 1.4 for ); Sat, 26 Nov 1994 06:03:59 +0200 (5.67a/IDA-1.5 for lites@cs.hut.fi); Fri, 25 Nov 1994 23:02:23 -0500 Date: Fri, 25 Nov 1994 23:02:23 -0500 From: "Louis-D. Dubeau" To: lites@cs.hut.fi Subject: Lites partitionning scheme Ok, here's a small question: Is Lites able to work with partitions that do not have BSD labels? My experience with Mach is mostly with UX42 which does not mount anything not in a BSD partition and with the Hurd which mounts everything but needs a mk patch (the patch is required only for the ext2fs server right now). ldd -- If you play Doctor Who's theme in reverse, you'll hear garbage. From jvh@cs.hut.fi Mon Nov 28 16:47:50 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 29 Nov 1994 01:37:26 +0200 (5.65c8/HUTCS-C 1.3 for lites); Tue, 29 Nov 1994 01:37:25 +0200 Date: Tue, 29 Nov 1994 01:37:25 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 941128 and some plans Organization: Helsinki University of Technology, CS Lab. Another pre-release snapshot is available from Leia. New this weekend: * Memory object caches and buffer caches are kept consistent. * Sync cleans memory objects. This time the speed is ok. * Lites boots on mips with Ultrix binaries. The port is still incomplete though. * More warning options are added and zillions of warnings are eliminated. * More type cleanup. The diffs from November 16 are rather large (290k unidiff). This is mostly due to 64 bit fixes and other fixes as well as eliminating warnings. A few files have changed a lot for other reasons. Unfortunately large diffs now and later will make life hard for other developers but that can't be helped except by quick integration. I have not fixed warnings in files that I haven't otherwise changed much. This is to make integration of FreeBSD and NetBSD fixes easier. If someone has time to look at merging file system and other changes that'd be most useful. I won't get to that in 2-4 months I think. Instead I plan to fix the following bugs: - mapped file sizes get rounded up on pageout. Should believe ftrunc. - perhaps fix the mips port a bit more. - fix copyrights etc. administrative stuff. - integrate all the great code you send me. (or most of it anyway). - make a public release soon (this could be called version 0.X). more sometimes 1995. Other bugs that are known but not being worked on: - umount doesn't seem to do enough flushing (if you first run fsck and then do mount -u there will still be junk in the caches). - gdb stack traces from the emulator to user space doesn't work on the MIPS. I can't see what's wrong in the debug info I wrote in the assembly code or what is going wrong and I'm ready to give up on this. - NFS between Lites and most our servers doesn't work. It works with some old sun4s though. NetBSD doesn't work any better in this respect. I already picked up some fixes in the early stages of Lites and tested it with a sparc box then. - Support for Linux/FreeBSD/NetBSD X servers is missing. Here is an old but still valid todo list: - A library for code common to the server and emulator and perhaps later other programs. At least exec_file.c, bcopy etc., ntoh, and so on could be moved there. Requires changes to the build system. - Figure out how to avoid deadlocking risks arising from printf calling functions taking locks. Printf is called in a large variety of places where all kinds of locks may be held. Printing to ttys, selwakeup, etc. in this situation creates a big potential for deadlock. I added a comment next to printf noting this problem. - Fix and test build environment so that building on Linux and BSD really works. - Enhance the sysv support to make it real. - 64 bit cleanup. [PARTIALLY DONE] - Add support for Linux and or BSD X servers. This is mostly related to virtual consoles I think. - Write /sbin/cored -- the core dumping daemon. - Experiment with +ether_as_syscall and get it to work enough to make it default. This is about running protocol stacks on the network input thread instead of going through netisrs. It is important for simplifying splx and the whole spl mechanism. Also network latency ought to decrease. The first select in inetd didn't wake up last time I tried. After this I've fixed some bug related to select but there are still some uncertainty related to sockets so this might be a difficult thing to debug. - Fix /proc and other Lite stuff that is in conf/MASTER.h listed in the UNTESTED, ALMOST, and NOTYET categories. --- Johannes From jvh@cs.hut.fi Tue Nov 29 18:44:02 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 30 Nov 1994 03:33:56 +0200 (5.65c8/HUTCS-C 1.3 for lites); Wed, 30 Nov 1994 03:33:55 +0200 Date: Wed, 30 Nov 1994 03:33:55 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: another update Organization: Helsinki University of Technology, CS Lab. The file 941128-941129.udiff.gz in leia contains mostly fixes to the vnode pager. Summary: * kern_prot.c fixes from Mike Hibler. * e_bnr_sigvec() now tolerates a null nsv (from Mike Hibler). * File sizes should now work correctly with mapped files. * vnode_pager_umount is implemented. It makes memory objects asspciated with a file system non-peristent. This avoids some unnecessary "device busy" errors from umount. * Paging locks inodes during i/o. * Some race conditions and other bugs in the cache consistency code are fixed. Johannes From hd@world.std.com Wed Nov 30 05:51:40 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 30 Nov 1994 14:44:02 +0200 id HAA11169; Wed, 30 Nov 1994 07:43:58 -0500 From: hd@world.std.com (HD Associates) Subject: Re: FreeBSD and Mach To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 30 Nov 1994 07:44:02 -0500 (EST) Cc: luigi@discovery.dia.unisa.it, FreeBSD-questions@freefall.cdrom.com, lites@cs.hut.fi In-Reply-To: <3652.785607977@freefall.cdrom.com> from "Jordan K. Hubbard" at Nov 23, 94 08:26:17 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 409 > > > Can FreeBSD work under Mach? > > and How one can do it? > > Send mail to lites@cs.hut.fi - they've done exactly that. > > Jordan Could you summarize? I've had no response from that address. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 FAX: 508 433 5267 Pepperell, MA hd@world.std.com From jvh@cs.hut.fi Wed Nov 30 12:42:16 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 30 Nov 1994 21:35:29 +0200 (5.65c8/HUTCS-C 1.3 for lites); Wed, 30 Nov 1994 21:35:23 +0200 Date: Wed, 30 Nov 1994 21:35:23 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: 4.4 ftruncate fixed Organization: Helsinki University of Technology, CS Lab. I found out that the problem with rcp and ar was after all in the emulator. e_lite_ftruncate got the words swapped in the length field. The extermely large file size failed in ffs_setattr. Adding pad arguments isn't very nice as they make the code machine dependent (word size dependent). If we can't think of any better way I think adding separate semi-machine dependent file for 32 bit and 64 bit machines with stubs with pads that would call the real functions through a proper prototype. The quick fix is so short that I'm including it here. Johannes --- lites.941128/emulator/e_bsd_stubs.c Mon Nov 28 08:34:02 1994 +++ lites/emulator/e_bsd_stubs.c Wed Nov 30 21:12:43 1994 @@ -573,7 +573,12 @@ return kr ? e_mach_error_to_errno(kr) : 0; } -errno_t e_lite_truncate(const char *path, off_t length) +errno_t e_lite_truncate( + const char *path, +#ifndef alpha /* XXX depends on pointer length */ + int pad, +#endif + off_t length) { kern_return_t kr; struct vattr va; @@ -585,7 +590,7 @@ return kr ? e_mach_error_to_errno(kr) : 0; } -errno_t e_lite_ftruncate(int fd, off_t length) +errno_t e_lite_ftruncate(int fd, int pad, off_t length) { kern_return_t kr; struct vattr va; From DALL@HFRD.DSTO.GOV.AU Wed Nov 30 17:23:43 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 1 Dec 1994 02:12:50 +0200 10:41:45 +1030 Date: Thu, 1 Dec 94 10:43:58 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: 4.4 ftruncate fixed In-Reply-To: <199411301935.AA04757@laphroaig.cs.hut.fi> References: <199411301935.AA04757@laphroaig.cs.hut.fi> X-Hfrd: 1994120110413042 Johannes Helander writes: > Adding pad arguments isn't very nice as they make the code machine > dependent (word size dependent). On the alpha, ints are 32 bits, longs are 64 bits. Presumably quad_t and off_t are long? The problem must come because there is a long argument followed by an off_t. If it was an int followed by a long it would still need padding wouldn't it? Anyway, another 64 bit machine, or even a different compiler for the same 64 bit machine could alter the requirement for padding. I think there may also be some assumptions about sizeof(int)== sizeof(long), because e_trampoline.c (for the i386 and the ns532) treats the argument list as an array of ints. Of course, the alpha might put its arguments in registers for all I know. I think there is no getting away from this stuff being machine dependent. It would be really nice if it were possible to have all the argument fiddling happen in e_trampoline.c which is already MD, but the trouble is, e_trampoline.c knows nothing about how the arguments should be interpreted. I wonder if it is possible to use the gcc extensions __alignof__ and __atribute__ ((aligned(n))) to be more machine independent (albeit more machine dependent). Eg, you could pretend the arguments are a structure and do something like: struct x_args { int arg1, off_t arg2 __attribute__ ((aligned (sizeof(off_t)))); }; e_x(struct x_args args) { } This would be a significant change, of course. Ian From DALL@HFRD.DSTO.GOV.AU Fri Dec 2 00:17:18 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 2 Dec 1994 09:10:18 +0200 15:18:20 +1030 Date: Fri, 2 Dec 94 15:20:21 +1030 From: Ian Dall To: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Patches against current snapshot X-Hfrd: 1994120215175209 I compiled the current snap shot and had the following problems: * No namei_macros.h * Type causing syntax errors in emulator/ns532/e_trampoline.c and server/ns532/server/serv_machdep.c * VOP_* undefined when compileing with noopt * blktochr undefined Patches follow. the VOP_* undefined are due to one extern inline still being used instead of __INLINE__ and also because there is no case where the .h files are included with __INLINE__ defined to be empty. I added an extra 3 line file, which is only required with the noopt configuration called vnode.c: -----------vnode.c---- #define __INLINE__ #include #include ----------end--------- *** ../../../hut/src/lites/./emulator/ns532/e_trampoline.c Mon Nov 21 22:08:26 1994 --- ./emulator/ns532/e_trampoline.c Fri Dec 2 08:01:32 1994 *************** *** 173,179 **** { return e_bnr_sigvec((int) argp[0], (struct sigvec *) argp[1], /* nsv */ ! (struct sigvec *) argp[2], /* osv */x (vm_address_t) regs->r1 & ~0x80000000); /* tramp */ } --- 173,179 ---- { return e_bnr_sigvec((int) argp[0], (struct sigvec *) argp[1], /* nsv */ ! (struct sigvec *) argp[2], /* osv */ (vm_address_t) regs->r1 & ~0x80000000); /* tramp */ } *** ../../../hut/src/lites/./server/conf/MASTER Sat Nov 19 00:46:39 1994 --- ./server/conf/MASTER Thu Dec 1 23:44:30 1994 *************** *** 110,115 **** --- 113,119 ---- options FILE_PORTS # options MAP_ETHER # Use mapped ethernet # options MAP_TIME # Use mapped time from kernel # + options NAMEI_MACROS # # Experimnetal features options ETHER_AS_SYSCALL # No net thread or ISR # *************** *** 168,173 **** --- 172,179 ---- options KTRACE # options RMP # options KMEMSTATS # + + options NOOPT # profile # build for profiling # *** ../../../hut/src/lites/./server/conf/files Sun Nov 6 16:58:50 1994 --- ./server/conf/files Fri Dec 2 07:19:18 1994 *************** *** 41,46 **** --- 41,47 ---- # # + OPTIONS/namei_macros optional namei_macros OPTIONS/map_uarea optional map_uarea OPTIONS/second_server optional second_server OPTIONS/machid_register optional machid_register *************** *** 101,106 **** --- 102,108 ---- OPTIONS/kmemstats optional kmemstats OPTIONS/rmp optional rmp OPTIONS/trace optional trace + OPTIONS/noopt optional noopt conf/param.c standard *************** *** 403,408 **** --- 405,411 ---- serv/mach_init_ports.c optional machid_register ./kern/syscalls.c standard ./vnode_if.c standard + kern/vnode.c optional noopt # Library support libkern/scanc.c standard *** ../../../hut/src/lites/./server/kern/vnode_if.sh Fri Nov 25 03:13:46 1994 --- ./server/kern/vnode_if.sh Fri Dec 2 00:07:18 1994 *************** *** 350,356 **** struct buf *a_bp; }; extern struct vnodeop_desc vop_strategy_desc; ! extern inline int VOP_STRATEGY(bp) struct buf *bp; { struct vop_strategy_args a; --- 350,356 ---- struct buf *a_bp; }; extern struct vnodeop_desc vop_strategy_desc; ! __INLINE__ int VOP_STRATEGY(bp) struct buf *bp; { struct vop_strategy_args a; *************** *** 365,371 **** struct buf *a_bp; }; extern struct vnodeop_desc vop_bwrite_desc; ! extern inline int VOP_BWRITE(bp) struct buf *bp; { struct vop_bwrite_args a; --- 365,371 ---- struct buf *a_bp; }; extern struct vnodeop_desc vop_bwrite_desc; ! __INLINE__ int VOP_BWRITE(bp) struct buf *bp; { struct vop_bwrite_args a; *** ../../../hut/src/lites/./server/ns532/server/conf.c Sat Nov 5 20:18:20 1994 --- ./server/ns532/server/conf.c Fri Dec 2 07:11:53 1994 *************** *** 281,287 **** /*28*/ { "", 0, no_ops, }, /* - */ /*29*/ { "", 0, no_ops, }, /* - */ }; ! int nchrdev = sizeof(cdevsw)/sizeof(cdevsw[0]); dev_t cttydev = makedev(1, 0); int mem_no = 2; --- 281,288 ---- /*28*/ { "", 0, no_ops, }, /* - */ /*29*/ { "", 0, no_ops, }, /* - */ }; ! #define NCHRDEV sizeof(cdevsw)/sizeof(cdevsw[0]) ! int nchrdev = NCHRDEV; dev_t cttydev = makedev(1, 0); int mem_no = 2; *************** *** 393,400 **** /* NOTREACHED */ } ! #define MAXDEV 21 ! static int chrtoblktbl[MAXDEV] = { /* VCHR */ /* VBLK */ /* 0 */ NODEV, /* 1 */ NODEV, --- 394,400 ---- /* NOTREACHED */ } ! static int chrtoblktbl[NCHRDEV] = { /* VCHR */ /* VBLK */ /* 0 */ NODEV, /* 1 */ NODEV, *************** *** 423,435 **** * * A minimal stub routine can always return NODEV. */ ! chrtoblk(dev) ! dev_t dev; { int blkmaj; ! return FALSE; /* XXX */ ! if (major(dev) >= MAXDEV || (blkmaj = chrtoblktbl[major(dev)]) == NODEV) return (NODEV); return (makedev(blkmaj, minor(dev))); } --- 423,449 ---- * * A minimal stub routine can always return NODEV. */ ! /* ! * Routine to convert from character to block device number. ! * ! * A minimal stub routine can always return NODEV. ! */ ! dev_t chrtoblk(dev_t dev) { int blkmaj; ! if (major(dev) >= NCHRDEV || (blkmaj = chrtoblktbl[major(dev)]) == NODEV) return (NODEV); return (makedev(blkmaj, minor(dev))); + } + + dev_t blktochr(dev_t bdev) + { + int i; + + for (i = 0; i < NCHRDEV; i++) { + if (major(bdev) == chrtoblktbl[i]) + return makedev(i, minor(bdev)); + } + return NODEV; } *** ../../../hut/src/lites/./server/ns532/server/serv_machdep.c Thu Nov 17 08:20:06 1994 --- ./server/ns532/server/serv_machdep.c Thu Dec 1 18:17:21 1994 *************** *** 82,88 **** #include ! + #include /* for struct exec_load_info */ #include #include #include --- 82,88 ---- #include ! #include /* for struct exec_load_info */ #include #include #include From jvh@cs.hut.fi Mon Dec 5 02:50:26 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 5 Dec 1994 11:39:38 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sun, 4 Dec 1994 19:56:30 +0200 Date: Sun, 4 Dec 1994 19:56:30 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 941204 Organization: Helsinki University of Technology, CS Lab. [ I sent this mail to the list 14 hours ago but it seems it got stuck somewhere. You will thus probably get this a second time later. ] There is a new snapshot in leia.cs.hut.fi:foggy/lites/ * vfs_bio.c updated as requested by John Dyson. * Fixes by Ian Dall merged. * Several port leaks plugged. The Lites server doesn't appear to leak ports anymore. I think that it still leaks some memory but have no idea where and how (otherwise it would already be fixed). * Fixes to the pager. * Changes and fixes all over to fix things that broke when plugging the port leaks. For details see the diff. * The server still runs multiuser on NetBSD 0.9 and 1.0. It also boots multiuser on FreeBSD 2.0 but with a few problems. The worst were: - fsck never checks any disks. This probably requires manipulating the superblock clean bit somewhere in UFS. - name server lookups fail. the query is sent correctly and the name server sends a correct reply (according to etherfind) but the application never sees it. If someone wishes to debug this or repeat the experiment it would be good. I added a file in doc describing what I had to do to boot Lites on FreeBSD. With NetBSD 0.9 or FreeBSD 1.5.1 you need to replace fsck, route, mount, and perhaps a few others with newer versions. * I tested Lites with RTMach MK83i in a NetBSD 0.9 environment. It booted happily multiuser without any problems. With newer filesystems the default pager can't interpret directories. I sent a patch to mach3@cs.cmu.edu. Johannes From jvh@cs.hut.fi Mon Dec 5 02:55:23 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 5 Dec 1994 11:45:44 +0200 (5.65c8/HUTCS-C 1.3 for lites); Sun, 4 Dec 1994 06:36:36 +0200 Date: Sun, 4 Dec 1994 06:36:36 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 941204 Organization: Helsinki University of Technology, CS Lab. There is a new snapshot in leia.cs.hut.fi:foggy/lites/ * vfs_bio.c updated as requested by John Dyson. * Fixes by Ian Dall merged. * Several port leaks plugged. The Lites server doesn't appear to leak ports anymore. I think that it still leaks some memory but have no idea where and how (otherwise it would already be fixed). * Fixes to the pager. * Changes and fixes all over to fix things that broke when plugging the port leaks. For details see the diff. * The server still runs multiuser on NetBSD 0.9 and 1.0. It also boots multiuser on FreeBSD 2.0 but with a few problems. The worst were: - fsck never checks any disks. This probably requires manipulating the superblock clean bit somewhere in UFS. - name server lookups fail. the query is sent correctly and the name server sends a correct reply (according to etherfind) but the application never sees it. If someone wishes to debug this or repeat the experiment it would be good. I added a file in doc describing what I had to do to boot Lites on FreeBSD. With NetBSD 0.9 or FreeBSD 1.5.1 you need to replace fsck, route, mount, and perhaps a few others with newer versions. * I tested Lites with RTMach MK83i in a NetBSD 0.9 environment. It booted happily multiuser without any problems. With newer filesystems the default pager can't interpret directories. I sent a patch to mach3@cs.cmu.edu. Johannes From DALL@HFRD.DSTO.GOV.AU Wed Dec 7 06:26:25 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 7 Dec 1994 15:18:26 +0200 09:40:45 +1030 Date: Wed, 7 Dec 94 09:42:47 +1030 From: Ian Dall To: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Approaching convergence! X-Hfrd: 1994120709400808 With the latest snapshot, I only needed two changes. The first to ns532/param.h is a new one. The second seems very obstinate! I have supplied a patch for it many times, but it just won't go away! I wonder if patch could get confused? Anyway, it would be as easy to to by hand. There is a spurious "+" sign at the start of the line. I imagine it is due to an error applying an earlier patch. Ian *** ../../../hut/src/lites/./include/ns532/param.h Sat Jul 16 18:58:23 1994 --- ./include/ns532/param.h Tue Dec 6 20:29:51 1994 *************** *** 166,169 **** #define TRAMPOLINE_MAX_SIZE 0x100 ! #define PAGE_SIZE vm_page_size --- 166,169 ---- #define TRAMPOLINE_MAX_SIZE 0x100 ! #define PAGE_SIZE NS532_PGBYTES *** ../../../hut/src/lites/./server/ns532/server/serv_machdep.c Thu Nov 17 08:20:06 1994 --- ./server/ns532/server/serv_machdep.c Thu Dec 1 18:17:21 1994 *************** *** 82,88 **** #include ! + #include /* for struct exec_load_info */ #include #include #include --- 82,88 ---- #include ! #include /* for struct exec_load_info */ #include #include #include From DALL@HFRD.DSTO.GOV.AU Wed Dec 7 06:28:39 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 7 Dec 1994 15:23:28 +0200 13:14:23 +1030 Date: Wed, 7 Dec 94 13:16:32 +1030 From: Ian Dall To: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Lites as first server? X-Hfrd: 1994120713135370 I applied Johannes mk bootstrap patch, and it now appears to find the files in the filesystem OK. However, after the message from mk which says it is loading startup's symbol table, nothing happens. ddb says that mk is in the idle loop. Does lites need to becompiled differently (without "second_server" for example), to be used as a first server? Ian From jvh@cs.hut.fi Wed Dec 7 06:41:00 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 7 Dec 1994 15:34:11 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 7 Dec 1994 15:33:48 +0200 Date: Wed, 7 Dec 1994 15:33:48 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Lites as first server? In-Reply-To: <9412070246.AA14754@hfrd.dsto.gov.au> References: <9412070246.AA14754@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Lites works as first server for me. However, it has to be xstripped because otherwise the symbol table and debug info will fill all available memory when loaded into ddb and nothing more will happen. The size of an unstripped server's debug info and symbol table are about nine megabytes. Xstrip leaves enough info for ddb and then only about half of the binary size is debug stuff. Instead of xstripping you could also compile without -g but then gdb isn't very useful. Your problem could be something different too of course... Johannes From idall@eleceng.adelaide.edu.au Thu Dec 8 06:33:08 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 8 Dec 1994 15:27:15 +0200 Date: Thu, 8 Dec 1994 23:56:56 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi Subject: 1st console troubles I can readily boot lites as the 1st server now and it works so long as I don't do too much terminal output. If I cat /etc/termcap it will panic after about a screenfull. It turns out, that when running as a second server, I can duplicate the problem by outputting to another tty (not the console). So, it looks like a general tty output problem which doesn't manifest its self for a second console. Does that give a clue? I haven't spent much time on this yet, but here is the backtrace: #0 warning_panic ( fmt=0xb317c "port_object_receive_lookup: type check failure") at /usr1/mach-build/cmu/src/lites/server/kern/subr_prf.c:178 #1 0xb3337 in port_object_receive_lookup (port=2037308, seqno=14, pot=POT_IO_BUFFER) at /usr1/mach-build/cmu/src/lites/server/serv/port_object.c:203 #2 0x8f27c in seqnos_device_write_reply (reply_port=2037308, seqno=14, return_code=0, bytes_written=52) at /usr1/mach-build/cmu/src/lites/server/serv/device_reply_hdlr.c:143 #3 0xbb92a in mach_msg () #4 0xbba1f in seqnos_device_reply_server () #5 0x8f20c in device_reply_loop (arg=0x0) at /usr1/mach-build/cmu/src/lites/server/serv/device_reply_hdlr.c:112 #6 0x96c26 in ux_thread_bootstrap (real_routine=0x8f19c ) at /usr1/mach-build/cmu/src/lites/server/serv/ux_server_loop.c:116 #7 0xb857c in cthread_body (Cannot access memory at address 0x0.) Ian From jvh@cs.hut.fi Thu Dec 8 06:46:50 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 8 Dec 1994 15:39:01 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 8 Dec 1994 15:38:50 +0200 Date: Thu, 8 Dec 1994 15:38:50 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Re: 1st console troubles In-Reply-To: <9412081326.AA15094@augean.eleceng.adelaide.edu.au> References: <9412081326.AA15094@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. Ian, Check what the type is expected to be (print the port object). Terminal i/o is supposed to be using device_write_inband, not device_write. I guess the problem is that the reply is expected from a block type of device and it came from a tty (did it?) If your driver uses a different interface we need to figure out a way to take care of difference in an MI way. It is still a good idea to have some type checking. This problem is not present in the i386 port. Johannes Ian Dall writes: > I can readily boot lites as the 1st server now and it works > so long as I don't do too much terminal output. If I cat /etc/termcap > it will panic after about a screenfull. > > It turns out, that when running as a second server, I can duplicate > the problem by outputting to another tty (not the console). So, it looks > like a general tty output problem which doesn't manifest its self > for a second console. Does that give a clue? From agl@mac.glasnet.ru Thu Dec 8 10:13:45 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 8 Dec 1994 18:48:07 +0200 (Smail3.1.29.1 #5) id m0rFm10-000GoYN; Thu, 8 Dec 94 19:48 +0300 (Smail3.1.28.1 #12) id m0rFm1F-0006xeN; Thu, 8 Dec 94 19:48 +0300 Date: Thu, 8 Dec 94 19:54 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: when compiling lites under linux I'm getting the following output (seemed to be strange to me). Btw I haven't configured gcc/binutils for i386-gnu taget yet (I suppose I need to compile lites server in ecoff? right?) But the errors seemed to have no connection with the mentioned issue. Btw, do I need the UFS partition to run lites or I can continue to live with ext2fs? Yeah, one more thing, /bin/sh is bash-1.14.2 in linux actually but it seemed to be compatible... Thanx! AGL [stderr] ./conf/doconfig.sh: ./conf/doconfig.sh: No such file or directory ./conf/i386/MASTER:49: invalid preprocessor directive name ./conf/i386/MASTER:58: invalid preprocessor directive name ./conf/i386/MASTER:62: invalid preprocessor directive name cpp: output pipe has been closed [stdout] loading cache ./config.cache checking for gcc... (cached) gcc checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking for ranlib... (cached) ranlib CPP reset to gcc -E -x c checking for mawk... (cached) gawk checking for a BSD compatible install... (cached) /usr/bin/ginstall -c setting LITES_CONFIG to STD+WS setting PROFILING to "no" updating cache ./config.cache creating ./config.status creating Makefile creating bin/Makefile creating emulator/Makefile creating include/Makefile creating server/Makefile creating conf/Makeconf SY, AGL From jvh@cs.hut.fi Thu Dec 8 15:57:21 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 8 Dec 1994 23:20:55 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 8 Dec 1994 23:20:54 +0200 Date: Thu, 8 Dec 1994 23:20:54 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 941208 Organization: Helsinki University of Technology, CS Lab. A new lites version is available as leia.cs.hut.fi:foggy/lites/LITES.941208.tar.gz Important bugfixes: * The big memory leak is plugged. server_exec_open_header looked at the wrong field in the namei buffer for determining whether or not to deallocate SAVENAME path names. No deallocation was done and a leak of one memory page per executed program occurred. The fix was simple, finding it was not. * A memory overwrite problem is removed. strcat was mistakenly used instead of strcpy in bsd_set_atexpansion. An overwrite that happened when starting /etc/init caused a crash in zalloc when running stage2 in make bootstrap of gcc. The fix was even more trivial. New functionality: * 4.4 socket interfaces now work. FreeBSD 2.0 binaries use the new interfaces and previously nameserver lookups didn't work with them. Old interfaces are now implemented in the emulator through converting to the new ones. Send and sendto are implemented through sendmsg, recv and recfrom through recvmsg. The server only needs to implement the new sendmsg and recvmsg calls (and accept etc). This is actually a performance loss as sendto and recfrom used specialized interfaces but sendmsg and recvmsg don't. In any case there are now less calls to optimize (does anyone want to write specialized interfaces for sendmsg and recvmsg?) * Fsck clean bit management code is picked up from FreeBSD. When using fsck from FreeBSD 2.0 cleanly umounted file systems will not be fsck'd on reboot. NetBSD's fsck works as before. umounting file systems automatically on shutdown is needed. Other: * I experimented with reducing the levels of SPLs to one. The server still works but seems a bit slower. High priority threads should not queue themselves in the tail of mutexes but in the front. This might help? The long term plan is to collapse all spls and the master lock together into a single mutex. This way there would be only one global lock. the role of the master lock is that it protects all such data that doesn't have its own lock. Data that is protected by other locks doesn't need the master lock. Slowly the system could get parallelized (of course we need to get rid of the tsleep system at some point). I guess I should mention that I left the single SPL level code in the snapshot. * I did some experimentation with +ether_as_syscall but couldn't get it to work reliably. Johannes From rougeau@ensta.fr Mon Dec 12 08:02:44 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Dec 1994 16:53:55 +0200 From: Patrick Rougeau Date: Mon, 12 Dec 1994 15:53:50 +0100 To: lites@cs.hut.fi Subject: help help From eldmgr@sdf.luth.se Mon Dec 12 14:25:39 1994 (5.65c8/HUTCS-S 1.4 for ); Mon, 12 Dec 1994 23:16:24 +0200 From: Mattias Gronlund Subject: help To: lites@cs.hut.fi Date: Mon, 12 Dec 1994 22:17:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 5 help From DALL@HFRD.DSTO.GOV.AU Mon Dec 12 16:55:02 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Dec 1994 01:48:39 +0200 10:18:32 +1030 Date: Tue, 13 Dec 94 10:20:56 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: stty doesn't X-Hfrd: 1994121310180270 The 4.4 termios ioctl (TIOCSETA and friends) doesn't change the device settings (eg baud, parity stop bits etc) although a get of the terminal status shows it changed. i.e. lites remembers the change, but it is never communicated to mk. The old bsd tty stuff works. I discovered I could talk to my (2400 baud) modem by setting the speed using an old stty and then running a new kermit! The problem seems to be that ttioctl() uses tp->t_param to set the parameter, but t_param is null. If ttioctl returns a non negative error code tty_ioctl has code to call device_set_status, but only for old style ioctls. I can think of at least 2 ways to fix this. One is to define a function to set the parameters and make t_param point to it. The other is to expand the code in tty_ioctl to handle the new ioctls. The t_param mechanism is presumably to allow device dependent paramter setting, but in our case, the device independence is handled by mk anyway. I think I'd argue for the t_param mechanism anyway. The code in tty_ioctl to set the device parameter should then probably be moved to the function pointed to by t_param (whatever we call it). I'll have a go at doing this unless someone has a better plan. Ian From jmc@telecom.ksu.edu Mon Dec 12 17:19:04 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Dec 1994 02:13:49 +0200 From: jmc@telecom.ksu.edu (James M. Chacon) Subject: Lites doesn't recognize my scsi labels? To: lites@cs.hut.fi Date: Mon, 12 Dec 1994 18:12:55 -0600 (CST) In-Reply-To: <9412122350.AA16891@hfrd.dsto.gov.au> from "Ian Dall" at Dec 13, 94 10:20:56 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 272 I have lites booting and running just fine as a first server on my netbsd 1.0 system. Now when I try to access /dev/sd0a it complains about the label. Does lites not recognize a disk with a bsd only label on it? Why does it recognize my IDE drive I boot off then? James From jvh@cs.hut.fi Tue Dec 13 06:04:23 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Dec 1994 14:55:14 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 13 Dec 1994 14:54:59 +0200 Date: Tue, 13 Dec 1994 14:54:59 +0200 From: Johannes Helander To: jmc@telecom.ksu.edu (James M. Chacon) Cc: lites@cs.hut.fi Subject: Re: Lites doesn't recognize my scsi labels? In-Reply-To: <199412130012.SAA28283@telecom.ksu.edu> References: <9412122350.AA16891@hfrd.dsto.gov.au> <199412130012.SAA28283@telecom.ksu.edu> Organization: Helsinki University of Technology, CS Lab. Lites doesn't interpret disklabels at all. In case it needs a partition table for some reason (e.g. the user made an ioctl) it asks the kernel. It can be argued that the labels should not be interpreted by the kernel etc. but as it currently stands it doesn't make sense to duplicate the code. The kernel scsi driver understands a bunch of different kinds of labels. My experience has been that the scsi driver in general works better than the hd driver. One nice feature is that the driver understands several labels at once and it is possible to move a disk from one machine to another (although I found out that the Boblabel code did unaligned accesses which wasn't nice on a Decstation). Johannes James M. Chacon wrote: > I have lites booting and running just fine as a first server on my > netbsd 1.0 system. Now when I try to access /dev/sd0a it complains > about the label. Does lites not recognize a disk with a bsd only label on it? > > Why does it recognize my IDE drive I boot off then? > > James From CRITCHSS@ctrvax.Vanderbilt.Edu Tue Dec 13 08:30:52 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Dec 1994 17:13:54 +0200 #7190) id <01HKL8I3K0QO8XDZ51@ctrvax.Vanderbilt.Edu>; Tue, 13 Dec 1994 09:12:54 CST Date: Tue, 13 Dec 1994 09:12:54 -0600 (CST) From: CRITCHSS@ctrvax.Vanderbilt.Edu Subject: subscribe To: lites@cs.hut.fi X-Vms-To: IN%"lites@cs.hut.fi" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT subscribe critchss@ctrvax.vanderbilt.edu From CRITCHSS@ctrvax.Vanderbilt.Edu Wed Dec 14 01:22:35 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 14 Dec 1994 10:12:06 +0200 #7190) id <01HKL9JFVGGW8XDZ51@ctrvax.Vanderbilt.Edu>; Tue, 13 Dec 1994 09:42:44 CST Date: Tue, 13 Dec 1994 09:42:44 -0600 (CST) From: CRITCHSS@ctrvax.Vanderbilt.Edu Subject: subscribe To: lites@cs.hut.fi X-Vms-To: IN%"lites@cs.hut.fi" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT subscribe critchss@ctrvax.vanderbilt.edu Steven Critchfield From DALL@HFRD.DSTO.GOV.AU Wed Dec 14 02:26:31 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 14 Dec 1994 11:20:26 +0200 09:08:38 +1030 Date: Wed, 14 Dec 94 09:10:54 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: tty ioctl fix X-Hfrd: 1994121409075913 I wrote: > The 4.4 termios ioctl (TIOCSETA and friends) doesn't change the > device settings (eg baud, parity stop bits etc) although a get of > the terminal status shows it changed. i.e. lites remembers the > change, but it is never communicated to mk. The old bsd tty stuff > works. I have fixed this. I have also removed some redundant code. The ttcompat function converts old ioctls to new ioctls and calls ttioctl (again). So long as the new ioctl code works, there is no need for the code in tty_ioctl which handles old ioctls. The following diffs also include a change to server/ns532/server/second_syscalls.s which is inline with the current i386 version of this file. Ian *** ../../../hut/src/lites/./server/kern/tty.c Fri Nov 25 07:24:26 1994 --- ./server/kern/tty.c Mon Dec 12 21:12:51 1994 *************** *** 37,43 **** * * @(#)tty.c 8.8 (Berkeley) 1/21/94 */ ! #include "compat_43.h" #include "diagnostic.h" --- 37,48 ---- * * @(#)tty.c 8.8 (Berkeley) 1/21/94 */ ! /* HISTORY ! * 12-Dec-94 Ian Dall (dall@hfrd.dsto.gov.au) ! * Remove code for old commands in ttioctl(). ttcompat converts old form ! * cmds to new form cmds and calls ttioctl again. ! * ! */ #include "compat_43.h" #include "diagnostic.h" *************** *** 640,645 **** --- 645,651 ---- #endif case TIOCSTI: case TIOCSWINSZ: + #if 0 #if COMPAT_43 || defined(COMPAT_SUNOS) case TIOCLBIC: case TIOCLBIS: *************** *** 649,654 **** --- 655,661 ---- case TIOCSETN: case TIOCSETP: case TIOCSLTC: + #endif #endif while (isbackground(p, tp) && p->p_pgrp->pg_jobc && (p->p_flag & P_PPWAIT) == 0 && *** ../../../hut/src/lites/./server/ns532/server/second_syscalls.s Sun Sep 25 12:31:09 1994 --- ./server/ns532/server/second_syscalls.s Fri Dec 9 21:14:09 1994 *************** *** 64,68 **** kernel_trap(second_read, SYS_read, 3) kernel_trap(second_close, SYS_close, 1) kernel_trap(second_ioctl, SYS_ioctl, 3) ! kernel_trap(second_sigvec, SYS_osigvec, 3) kernel_trap(second__exit, SYS_exit, 1) --- 64,68 ---- kernel_trap(second_read, SYS_read, 3) kernel_trap(second_close, SYS_close, 1) kernel_trap(second_ioctl, SYS_ioctl, 3) ! kernel_trap(second_sigvec, SYS_sigvec, 3) kernel_trap(second__exit, SYS_exit, 1) *** ../../../hut/src/lites/./server/serv/tty_io.c Mon Nov 28 10:56:19 1994 --- ./server/serv/tty_io.c Mon Dec 12 22:49:38 1994 *************** *** 25,30 **** --- 25,34 ---- */ /* * HISTORY + * 12-Dec-94 Ian Dall (dall@hfrd.dsto.gov.au) + * Remove code for old ioctl cmds from tty_ioctl(). There is hair in + * ttioctl to convert from old cmds to new cmds. + * * $Log: tty_io.c,v $ * Revision 2.5 93/03/12 10:55:18 rwd * cdevsw and linesw interfaces have changed slightly! *************** *** 107,112 **** --- 111,118 ---- void tty_write_reply(char *, int, int); void tty_start(struct tty *); + static mach_error_t tty_param(struct tty *tp, struct termios *t); + extern struct tty * cons_tp; /* console TTY */ static long old_baudrates[] = { *************** *** 216,221 **** --- 222,228 ---- } tp->t_oproc = tty_start; + tp->t_param = tty_param; if ((tp->t_state & TS_ISOPEN) == 0) { *************** *** 397,402 **** --- 404,447 ---- #endif } + /* Set the device parameters */ + static mach_error_t tty_param(struct tty *tp, struct termios *t) + { + struct tty_status ttstat; + mach_msg_type_number_t ttstat_count; + mach_error_t error; + + /* + * Get configuration parameters from device, put in tty structure + */ + ttstat_count = TTY_STATUS_COUNT; + (void) device_get_status(tp->t_device_port, + TTY_STATUS, + (int *)&ttstat, + &ttstat_count); + + ttstat.tt_ispeed = baudrate_to_speed(t->c_ispeed); + ttstat.tt_ospeed = baudrate_to_speed(t->c_ospeed); + ttstat.tt_flags &= ~(TF_EVENP | TF_ODDP | TF_ECHO | TF_CRMOD | XTABS); + if (t->c_iflag & INPCK) + if (t->c_cflag & PARODD) + ttstat.tt_flags |= TF_EVENP; + else + ttstat.tt_flags |= TF_ODDP; + if (t->c_lflag & ECHO) + ttstat.tt_flags |= TF_ECHO; + if (t->c_iflag & ICRNL) + ttstat.tt_flags |= TF_CRMOD; + if (t->c_oflag & OXTABS) + ttstat.tt_flags |= TF_XTABS; + + error = device_set_status(tp->t_device_port, + TTY_STATUS, + (int *)&ttstat, + ttstat_count); + return (error); + } + mach_error_t tty_ioctl( dev_t dev, ioctl_cmd_t cmd, *************** *** 420,513 **** error = ttioctl(tp, cmd, data, flag); if (error >= 0) { - if (cmd == TIOCSETP || cmd == TIOCSETN || cmd == TIOCLBIS || - cmd == TIOCLBIC || cmd == TIOCLSET || cmd == TIOCHPCL) { - /* - * set device parameters - */ - ttstat_count = TTY_STATUS_COUNT; - (void) device_get_status(tp->t_device_port, - TTY_STATUS, - (int *)&ttstat, - &ttstat_count); - - switch (cmd) { - case TIOCSETP: - case TIOCSETN: - { - register struct sgttyb *sg = (struct sgttyb *)data; - ttstat.tt_ispeed = baudrate_to_speed(sg->sg_ispeed); - ttstat.tt_ospeed = baudrate_to_speed(sg->sg_ospeed); - if (sg->sg_flags & RAW) { - ttstat.tt_breakc = 0; - ttstat.tt_flags |= TF_LITOUT; - } else { - ttstat.tt_breakc = tp->t_cc[VINTR]; - if (!(tp->t_flags & LITOUT)) - ttstat.tt_flags &= ~TF_LITOUT; - } - if (sg->sg_flags & ODDP) - ttstat.tt_flags |= TF_ODDP; - else - ttstat.tt_flags &= ~TF_ODDP; - if (sg->sg_flags & EVENP) - ttstat.tt_flags |= TF_EVENP; - else - ttstat.tt_flags &= ~TF_EVENP; - - } - case TIOCLBIS: - { - word = *(int *)data; - - if (word & (MDMBUF>>16)) - ttstat.tt_flags |= TF_MDMBUF; - if (word & (LITOUT>>16)) - ttstat.tt_flags |= TF_LITOUT; - if (word & (NOHANG>>16)) - ttstat.tt_flags |= TF_NOHANG; - break; - } - case TIOCLBIC: - { - word = *(int *)data; - - if (word & (MDMBUF>>16)) - ttstat.tt_flags &= ~TF_MDMBUF; - if (word & (LITOUT>>16) && !(tp->t_flags & RAW)) - ttstat.tt_flags &= ~TF_LITOUT; - if (word & (NOHANG>>16)) - ttstat.tt_flags &= ~TF_NOHANG; - break; - } - case TIOCLSET: - { - word = *(int *)data; - - if (word & (MDMBUF>>16)) - ttstat.tt_flags |= TF_MDMBUF; - else - ttstat.tt_flags &= ~TF_MDMBUF; - if (word & (LITOUT>>16)) - ttstat.tt_flags |= TF_LITOUT; - else - if (!(tp->t_flags & RAW)) - ttstat.tt_flags &= ~TF_LITOUT; - if (word & (NOHANG>>16)) - ttstat.tt_flags |= TF_NOHANG; - else - ttstat.tt_flags &= ~TF_NOHANG; - break; - } - case TIOCHPCL: - ttstat.tt_flags |= TF_HUPCLS; - break; - } - (void) device_set_status(tp->t_device_port, - TTY_STATUS, - (int *)&ttstat, - ttstat_count); - } return (error); } /* if command is one meant for device, --- 465,470 ---- From rougeau@ensta.fr Wed Dec 14 23:11:52 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Dec 1994 07:27:43 +0200 From: Patrick Rougeau Date: Thu, 15 Dec 1994 06:27:39 +0100 To: lites@cs.hut.fi Subject: getting lites I have tried on cs.hut.fi it is unreadable where is it available ? I have heard about a netbsd port on mach kernel I would like any information about it , (availability ?) thank you for any answer P.Rougeau From jvh@cs.hut.fi Thu Dec 15 18:30:34 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Dec 1994 03:19:45 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 16 Dec 1994 03:19:27 +0200 Date: Fri, 16 Dec 1994 03:19:27 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 941216 Organization: Helsinki University of Technology, CS Lab. A new snapshot is available as leia.cs.hut.fi:foggy/lites/Lites.941216.tar.gz Many copyrights have been updated and some cleanup has been done. I combined all e_lites_sysent.c files into one, removed the build directory, etc. There are some bugfixes too. This snapshot was made for merging purposes. It has not been properly tested. There is no diff. It would be large and uninteresting. If anyone has contributed code but has not been properly attributed or I've done any other mistake (check doc/FILES2 for details, ask me for explanations) now is a good time to let me know so that it can be fixed. Also if anyone has code that ought to go into the release and could be merged let me know and send me the code asap. If you are doing any testing let me know the results. thanks, Johannes From csc4let@cabell.vcu.edu Fri Dec 16 11:16:57 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Dec 1994 20:09:22 +0200 Date: Fri, 16 Dec 1994 13:08:34 -0500 From: csc4let@cabell.vcu.edu (Louis E. Trumpbour) To: lites@cs.hut.fi, rougeau@ensta.fr Subject: Re: getting lites let me know what you heard about the mach based BSD-lite system. I have been planing on working on the port over but heard that there was one... just can not find it... of course if i do i can put more time into building and work on bugs for us lovers of mach. Cl From jvh@cs.hut.fi Mon Dec 19 18:06:03 1994 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Dec 1994 02:53:39 +0200 (5.65c8/HUTCS-C 1.3 for lites); Tue, 20 Dec 1994 02:13:18 +0200 Date: Tue, 20 Dec 1994 02:13:18 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Lites WWW page Organization: Helsinki University of Technology, CS Lab. A first version of the Lites home page can be viewed through the following URL http://www.cs.hut.fi/lites.html Comments and additions are welcome. Johannes From idall@eleceng.adelaide.edu.au Wed Dec 28 05:31:48 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 28 Dec 1994 14:23:00 +0200 Date: Wed, 28 Dec 1994 22:52:56 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi Subject: No signal delivery port When I run "dump", I get millions of error messages from sendsig() saying signal_notify: (ipc/rpc) failure or some such. I haven't succeeded in tracing this properly and I am not too clear about how signals are handled in lites, but the parent "dump" has two threads and all the child dumps have one. I am wondering if dump sets up the signal catching before forking. If the signal catching thread is launched when the signal catching is set up and the extra threads don't survive a fork, then it would explain what I see. As to the fix, I am clueless at the moment! Ian From jvh@cs.hut.fi Wed Dec 28 07:51:51 1994 (5.65c8/HUTCS-S 1.4 for ); Wed, 28 Dec 1994 16:46:18 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 28 Dec 1994 16:46:01 +0200 Date: Wed, 28 Dec 1994 16:46:01 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Re: No signal delivery port In-Reply-To: <9412281222.AA29665@augean.eleceng.adelaide.edu.au> References: <9412281222.AA29665@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. It is always amazing how convoluted unix signals actually are! Anyways, this time I simply seem to have forgotten to setup enough state in the child after a fork. When sigaction is called for the first time in the parent it creates a new thread for receiving asynchronous signals from the server. This is done by calling e_enable_asynch_signals() from e_sigaction(). After a fork child_init() is called in the child. It reinitializes several other things that are not automatically inherited. It should also do something about signals. A simple solution would be to reset all variables (signal_port, signal_suspend_reply_port) to zero and call e_enable_asynch_signals() again. Whether anything should be done in the first place can be seen from the same variables before zeroing them. If they are already zero then do nothing. All of this could be done by a new function that is called from child_init(). I assume there will be more to do later when the signal code in general is improved. I'll fix this in a few days after I get some other work done unless you do it first. Johannes Ian Dall wrote: > When I run "dump", I get millions of error messages from sendsig() > saying signal_notify: (ipc/rpc) failure or some such. > > I haven't succeeded in tracing this properly and I am not too clear > about how signals are handled in lites, but the parent "dump" has two > threads and all the child dumps have one. I am wondering if dump sets > up the signal catching before forking. If the signal catching thread > is launched when the signal catching is set up and the extra threads > don't survive a fork, then it would explain what I see. As to the > fix, I am clueless at the moment! > > Ian From sjt@epoch.ncsc.mil Thu Dec 29 11:45:55 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 29 Dec 1994 20:36:44 +0200 X-Mailer: exmh version 1.5.1 12/2/94 To: lites@cs.hut.fi Subject: bootstrap confusion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Dec 94 13:29:22 -0500 From: Jeff Turner is the recipe for installation in doc/install.freebsd still valid? i believe i've followed it exactly, but still cannot get even mach to boot, let alone lites. mach, lites, etc. are all installed properly, and i cannot boot directly off of the hard drive, so i try pcboot.MK83 on a floppy (retrieved from the lites ftp site). The very first thing that happens is the message: XXXBSD OS label at sec 1 off 0 BSD Label. Invalid format! i've tried most of the permutations of (ide/scsi, freebsd 2.0/netbsd 1.0, various scsi adapters, ...) and have the same problem on all of them. any suggestions? jeff p.s., the best i've done so far is on a mach platform (bsd 4.3 binaries?) - i get a good way into the lites boot before a panic that was taking a long time to track down. From jvh@cs.hut.fi Thu Dec 29 12:17:00 1994 (5.65c8/HUTCS-S 1.4 for ); Thu, 29 Dec 1994 21:11:41 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 29 Dec 1994 21:11:36 +0200 Date: Thu, 29 Dec 1994 21:11:36 +0200 From: Johannes Helander To: Jeff Turner Cc: lites@cs.hut.fi Subject: bootstrap confusion In-Reply-To: <9412291829.AA11145@gareb.epoch.ncsc.mil> References: <9412291829.AA11145@gareb.epoch.ncsc.mil> Organization: Helsinki University of Technology, CS Lab. > is the recipe for installation in doc/install.freebsd still valid? I hope so. I wrote down what I had to do when I did it myself. You are the first one who has actually tried to use them (or who has told me about it anyways). All corrections are most welcome! A copy of the instructions is also available in the WWW page http://www.cs.hut.fi/lites.html under the notes section. > i believe i've followed it exactly, but still cannot get even > mach to boot, let alone lites. I was using a SCSI disk (AHA1542B card). Maybe the boot program doesn't work with IDE (or whatever)? There should be a newer version of the boot program with MK83a. The one in leia is from MK83. > i've tried most of the permutations of (ide/scsi, freebsd 2.0/netbsd 1.0, > various scsi adapters, ...) and have the same problem on > all of them. Hm, well then it can't be the disk. Anyways, perhaps the MK83a boot program might work better. It is supposed to be compatible with NetBSD. In any case this doesn't sound like a Lites problem but a problem with the boot program and I'm not really the right person to answer questions about that. I hope someone is able to solve this. > p.s., the best i've done so far is on a mach platform (bsd 4.3 binaries?) > - i get a good way into the lites boot before a panic that > was taking a long time to track down. Interesting. Where did it crash? Johannes From wsm@morticia.ssw.com Thu Dec 29 20:02:42 1994 (5.65c8/HUTCS-S 1.4 for ); Fri, 30 Dec 1994 04:57:42 +0200 Date: Thu, 29 Dec 1994 21:58:49 -0500 From: William S. Morgart To: lites@cs.hut.fi Subject: X11R6 and Lites/Mach4/i386 Cc: Reply-To: wsm@morticia.ssw.com My System: NetBSD/i386 1.0 Based, lites 121694, and Mach4. My Problem: I've been attempting to build the xfree86 release of X11R6 for the lites server and I'm having a bit of trouble with the include files from the three different environments. I've configured the xfree build so that no NetBSD include files are picked up but I'm running into clashes with include files from mach4 and lites. For example, time.h from lites and sys_time.h from mach4 both define "time" differently. My Questions: Has anyone succeeded at building xfree86 (x11r6) for lites/mach in any environment other than a mach native one, ie *BSD or linux? If so any insight to a solution would be appreciated. If not any suggestions from anyone as to how to circumvent "My Problem"? Finally, if answers to the above aren't available anybody out there got an X11R6 server for mach/lites on the 386? One terminal window just doesn't cut it anymore .... Bill Morgart From idall@eleceng.adelaide.edu.au Mon Jan 2 05:55:39 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 2 Jan 1995 14:40:02 +0200 Date: Mon, 2 Jan 1995 23:09:32 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi Subject: Missing files The current snapshot is missing server/ns532/ns532/ntoh.s. It used to be in previous snapshots. Also, sys/elf.h is now required in exec_file.h, but it isn't in the distribution. Ian From idall@eleceng.adelaide.edu.au Mon Jan 2 06:51:50 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 2 Jan 1995 15:38:55 +0200 Date: Tue, 3 Jan 1995 00:08:52 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi In-Reply-To: <9501021239.AA13112@augean.eleceng.adelaide.edu.au> Subject: Re: Missing files I wrote: > Also, sys/elf.h is now required in exec_file.h, but it isn't in the > distribution. My mistake, elf.h is there, but the ns532 ntoh.s really is missing. Ian From jmc@telecom.ksu.edu Mon Jan 2 22:43:39 1995 (5.65c8/HUTCS-S 1.4 for ); Tue, 3 Jan 1995 07:38:21 +0200 From: jmc@telecom.ksu.edu (James M. Chacon) Subject: Panic on initial bootup? To: lites@cs.hut.fi Date: Mon, 2 Jan 1995 23:38:14 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 465 I recompiled and reinstalled my mach4 as well as the 1218 lites stuff. Now, the mach stuff appears to boot up just fine and start the server, but the server now dies after the initial 3 lines of copyright info in mutex_try_lock(). It's panic'ing in the assertation on line 74 of server/serv/import_mach.h Any ideas, or this something wrong with my mach4 install? The mach4 stuff has worked flawlessly with every other lites install I've worked on though... James From muzaffer@smixedsignal.com Tue Jan 3 16:35:01 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 4 Jan 1995 01:22:32 +0200 Date: Tue, 3 Jan 95 15:16:11 PST From: muzaffer@smixedsignal.com Subject: beware newbie question To: lites@cs.hut.fi X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII now can someone point me a document which tells me how to build, install etc lites on Linux and MACH 4 ? thanks -------------------------------------------- Muzaffer Kal muzaffer@smixedsignal.com 73423.546@compuserve.com From idall@eleceng.adelaide.edu.au Fri Jan 6 06:37:24 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 6 Jan 1995 15:23:53 +0200 Date: Fri, 6 Jan 1995 23:53:50 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi Subject: Miscellaneous stuff I have implimented the fix Johannes suggested so that signals work properly after a fork. Now dump seems to work for me -- mostly. The remaining problem is that sometimes (but not always) when it gets to the end of a dump, it hangs just before it would print the message "closing /dev/". This might really be a hang in close for some obscure reason, but it might also be a signal related thing. If I make dump output to stdout and pipe it through dd, sofar I haven't seen the problem. So, dump could be trying some tape ioctly which is hanging sometimes and which it doesn't do when writing to stdout. The other problem I have noticed lately, it that tty io doesn't seem to work properly in 7 bit modes. I had to turn off parity in getttab or else the output would be gibberish. I have a dial in host which I can't so easilly change. Maybe the 8th bit isn't being stripped. Ian From jvh@cs.hut.fi Fri Jan 6 18:16:40 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 7 Jan 1995 03:03:05 +0200 (5.65c8/HUTCS-C 1.3 for lites); Sat, 7 Jan 1995 03:03:04 +0200 Date: Sat, 7 Jan 1995 03:03:04 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 950107 Organization: Helsinki University of Technology, CS Lab. A new Lites snapshot is available. leia.cs.hut.fi:foggy/lites/Lites.950107.tar.gz or 941216-950107.udiff.gz i386 binaries (startup.Lites.0.5.STD+WS.gz + emulator.Lites.0.5.gz) are available in the bin subdirectory. The snapshot is primarily one iteration in merging work done by others. The 941218 changes have also been fixed. The snapshot has been tested to boot multiuser on the i386 platform with MK83i. Linux zsh was also tested in order to see that earlier changes didn't break the Linux support. Johannes From sjt@epoch.ncsc.mil Thu Jan 12 14:09:25 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 12 Jan 1995 23:02:24 +0200 X-Mailer: exmh version 1.5.1 12/2/94 To: lites@cs.hut.fi Subject: Building lites based on mk83a Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 95 08:52:51 -0500 From: Jeff Turner i'm trying to figure out how the install/bin and install/lib directories get properly populated if i want to build lites based on mk83a instead of mach4. since i'm not using mach4, the install dir is empty as i start to build lites. however, lites expects a couple of things that only mach4 would have set up properly: lib/mach_crt0.o, bin/mig, and bin/migcom it was easy enough to address (kludge) these problems, but i feel like i'm missing something. jeff From jvh@cs.hut.fi Fri Jan 13 01:30:16 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 10:22:38 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 13 Jan 1995 10:22:34 +0200 Date: Fri, 13 Jan 1995 10:22:34 +0200 From: Johannes Helander To: Jeff Turner Cc: lites@cs.hut.fi Subject: Re: Building lites based on mk83a In-Reply-To: <9501121352.AA01268@gareb.epoch.ncsc.mil> References: <9501121352.AA01268@gareb.epoch.ncsc.mil> Organization: Helsinki University of Technology, CS Lab. > since i'm not using mach4, the install dir is empty as i start to > build lites. however, lites expects a couple of things that only > mach4 would have set up properly: lib/mach_crt0.o, bin/mig, and > bin/migcom I added some code in the make rules (conf/Makerules) to figure out what commands and files to use. Until now you have had to copy the files manually. The changes will appear in the next snapshot. Please test them with your environment. Johannes From kstailey@leidecker.gsfc.nasa.gov Fri Jan 13 10:05:19 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 18:54:44 +0200 Date: Fri, 13 Jan 95 11:54:38 -0500 From: Kenneth Stailey To: lites@cs.hut.fi Subject: please subscribe In the event that this is not an automated service, please either subscribe me to the LITES mailing list or tell me how to do it myself. Thank you From kstailey@leidecker.gsfc.nasa.gov Fri Jan 13 10:06:38 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 18:36:10 +0200 Date: Fri, 13 Jan 95 11:35:48 -0500 From: Kenneth Stailey To: lites@cs.hut.fi Subject: help help From jvh@cs.hut.fi Fri Jan 13 10:15:27 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 19:03:42 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 13 Jan 1995 19:03:41 +0200 Date: Fri, 13 Jan 1995 19:03:41 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Snapshot 940113 Organization: Helsinki University of Technology, CS Lab. A new snapshot is available as leia.cs.hut.fi:foggy/qwerty/Lites.950113.tar.gz Note the location change. I'll explain the changes in more detail in a later message. There are changes to the build system and in the recvmsg/sendmsg implementation. Johannes From kstailey@leidecker.gsfc.nasa.gov Fri Jan 13 11:10:09 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 19:48:04 +0200 Date: Fri, 13 Jan 95 12:47:46 -0500 From: Kenneth Stailey To: lites@cs.hut.fi Subject: FAQ issues Is there an FAQ for this group? I need to know what's involved in getting a system set up. Mach itself may not have an activly maintained FAQ anymore. Here's a little correspondence that I just had. [begin included message] From: fgray@oven.ccds.charlotte.nc.us (Fred Gray) Subject: Re: mach-faq To: kstailey@leidecker.gsfc.nasa.gov (Kenneth Stailey) Date: Wed, 11 Jan 1995 22:17:06 -0500 (EST) In-Reply-To: <9501110425.AA01759@leidecker.gsfc.nasa.gov> from "Kenneth Stailey" at Jan 10, 95 11:25:14 pm X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 656 > > Do you still maintain the FAQ? If so please add: > > There is a project on-going that is a Mach server/emulator based on > 4.4Lite (LITES). It is fairly far along - boots multiuser, runs > NetBSD, FreeBSD, Mach, and Linux binaries (Linux Doom). The mailing > list to get on for this is "lites@cs.hut.fi". > I no longer maintain the FAQ. However, I am interested in LITES as I am working on a free Macintosh port of Mach and I may soon be at the point of needing something to run on top of it. Thanks for your interest and your work. I am not aware of any currently-maintained FAQ for Mach. -- -- Fred Gray -- fgray@oven.ccds.charlotte.nc.us From jvh@cs.hut.fi Fri Jan 13 13:43:43 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 13 Jan 1995 22:19:05 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 13 Jan 1995 22:18:58 +0200 Date: Fri, 13 Jan 1995 22:18:58 +0200 From: Johannes Helander To: Kenneth Stailey Cc: lites@cs.hut.fi Subject: Re: FAQ issues In-Reply-To: <9501131747.AA04650@leidecker.gsfc.nasa.gov> References: <9501131747.AA04650@leidecker.gsfc.nasa.gov> Organization: Helsinki University of Technology, CS Lab. The closest thing to a FAQ is perhaps the WWW page http://www.cs.hut.fi/lites.html It isn't very good yet but more will be added. Johannes From collins@unm.edu Fri Jan 13 17:29:52 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 14 Jan 1995 02:01:36 +0200 (Smail3.1.28.1 #4) id m0rSvvt-000St0C; Fri, 13 Jan 95 17:01 MST Date: Fri, 13 Jan 1995 17:01:27 -0700 (MST) From: Bill Collins To: lites@cs.hut.fi Subject: Boot failure Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm using a Gateway 2000/4DX-33 with an adaptech 1540C. It already has its IDE drive partitioned(MSDOS, FreeBSD, and Mach/US.) I've tried to install lites on the FreeBSD partition with near success. Unfortunately... When I boot the MK83a kernel supplied in on leia, it hangs in autoconfig after it finds aha0. When I boot using MK83 or RT/MK83i, it fails looking for the mach_servers subdirectory: /dev/hd0a/mach_servers: not found Can't open server directory /dev/hd0a/mach_servers :5001 (is the mach label, id=99, confusing the boot?) Whats amiss? Bill Internet: collins@ariel.unm.edu BITnet/CREN: collins@unmb.bitnet From jvh@cs.hut.fi Fri Jan 13 18:10:44 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 14 Jan 1995 02:44:15 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sat, 14 Jan 1995 02:42:59 +0200 Date: Sat, 14 Jan 1995 02:42:59 +0200 From: Johannes Helander To: Bill Collins Cc: lites@cs.hut.fi Subject: Re: Boot failure In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. Bill Collins writes: > I'm using a Gateway 2000/4DX-33 with an adaptech 1540C. It already has > its IDE drive partitioned(MSDOS, FreeBSD, and Mach/US.) I've tried to > install lites on the FreeBSD partition with near success. > Unfortunately... Hm, I should have mentioned this somewhere but forgot it myself: the MK83 kernel at Leia has an older version of the AHA driver because the newer one didn't work with a Buslogic card we have in one machine. The old one does but doesn't in turn work with 1452C (we only happen to have A and B series adaptec cards). So you either need to find another kernel or I can compile a kernel for you with the other driver (rather not). Hm, maybe you could try the MK83i binary we built. I put it in leia.cs.hut.fi:foggy/qwerty/bin/MK83i.boot. > When I boot the MK83a kernel supplied in on leia, it hangs in autoconfig > after it finds aha0. When I boot using MK83 or RT/MK83i, it fails > looking for the mach_servers subdirectory: > > /dev/hd0a/mach_servers: not found > Can't open server directory /dev/hd0a/mach_servers :5001 This is because the directory entries and symlinks are incompatible. I sent a patch to some list sometimes. We also added some patches to make MK83i possible to build on NetBSD 1.0. The patches need to be cleaned up before they can be integrated. Also some modifications to make building Lites with it possible are missing. I or jtp will get to that in a couple of weeks maybe. MK83a needs the dirent and fastlink patch in order to understand 4.4 file systems. > (is the mach label, id=99, confusing the boot?) Whats amiss? No that's fine. Johannes From jvh@cs.hut.fi Sat Jan 14 18:21:18 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 15 Jan 1995 03:09:28 +0200 (5.65c8/HUTCS-C 1.3 for lites); Sun, 15 Jan 1995 03:09:24 +0200 Date: Sun, 15 Jan 1995 03:09:24 +0200 From: Johannes Helander To: Kenneth Stailey Cc: lites@cs.hut.fi Subject: Re: FAQ issues In-Reply-To: <9501131747.AA04650@leidecker.gsfc.nasa.gov> References: <9501131747.AA04650@leidecker.gsfc.nasa.gov> Organization: Helsinki University of Technology, CS Lab. I didn't notice this serious mistake before: > > Do you still maintain the FAQ? If so please add: > > > > There is a project on-going that is a Mach server/emulator based on > > 4.4Lite (LITES). It is fairly far along - boots multiuser, runs > > NetBSD, FreeBSD, Mach, and Linux binaries (Linux Doom). The mailing > > list to get on for this is "lites@cs.hut.fi". Absolutely do NOT put that address in a FAQ. The request address is lites-request@cs.hut.fi We don't want hundreds of stupid "help" or "subscribe" messages to the list! Besides, please don't put the list address in any FAQ at all. Rather add the URL http://www.cs.hut.fi/lites.html It has info on the mailing list. People can find it there. Also, the name is Lites not LITES, the emulator is not based on 4.4 Lite, and mentions of the other ports (parisc, pc532, mips) are missing. Please, if anyone is suggesting FAQ additions in the future check the text with me first. I don't wish to censor anything but just get the facts right. Thanks, Johannes From agl@mac.glasnet.ru Fri Jan 20 02:07:39 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 10:56:16 +0200 id m0rV51T-0009pKC; Fri, 20 Jan 95 01:08 GMT+0300 Date: Fri, 20 Jan 95 01:08 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: What kind of environment lites needs? X-Mailer: GNOS 1.14 Mach4 boots and then lites complains that something went wrong, I wonder does it recognizes the linux's FS structure, device naming scheme, or this issue relates to mach rather then lites? I wonder anybody runs it on the machine without Bsd installed on it? Hmm, I guess I'm on the flakey ground, hmm AGL From jvh@cs.hut.fi Fri Jan 20 02:32:42 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 11:26:27 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 20 Jan 1995 11:26:07 +0200 Date: Fri, 20 Jan 1995 11:26:07 +0200 From: Johannes Helander To: agl@mac.glasnet.ru (Anthony Graphics) Cc: lites@cs.hut.fi Subject: Re: What kind of environment lites needs? In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. On the i386 platform Lites boots at least with NetBSD 1.0 and FreeBSD 2.0. Booting older FreeBSD and NetBSD versions as well as UX (Mach 2.5, 4.3 BSD) requires replacing some programs and in the case of UX converting thr file system with fsck. You can also run binaries from Linux but booting such a system with Lites I have never done. I don't know if it's possible. Let me know if you succeed. > does it recognizes the linux's FS structure, device naming scheme, No. The ext2fs file system is not ready and the device numbers are those of BSD. If anyone has a good idea on how to support several device numbering schemes at once let me know. One idea would be to make the numbering per file system type. Then an ext2 file system would have Linux device numbers and a BSD file system BSD file numbers. Another idea is to create a special /dev file system and perhaps get rid of the device numbers altogether. The latter would probably be better but would require more work. One possibility is to have several /dev directories and use @sys to decide between them. This was one of the main ideas why namei macros were added to Lites. Yet I think it would have been better to interpret the macros only within symlinks (but then they would behave differently from AFS or DFS). Another thing that is missing is virtual consoles. This would require driver support I think. Anyone willing to add VT support to Mach4 + Lites? Johannes From agl@mac.glasnet.ru Fri Jan 20 02:36:31 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 11:32:21 +0200 id m0rVFi9-0006YKC; Fri, 20 Jan 95 12:32 GMT+0300 Date: Fri, 20 Jan 95 12:32 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: Linux executables are supported to which degree: X-Mailer: GNOS 1.14 can I run the NET3 or at least NET2 suite? Hmm, since it doesn't bootstrap from ext2fs I would be able (or had to if you like ;-]) use the BSD net suite I suppose? Not to the faint of heart though... SY, AGL From jvh@cs.hut.fi Fri Jan 20 03:02:13 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 11:53:21 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 20 Jan 1995 11:49:07 +0200 Date: Fri, 20 Jan 1995 11:49:07 +0200 From: Johannes Helander To: agl@mac.glasnet.ru (Anthony Graphics) Cc: lites@cs.hut.fi Subject: Re: Linux executables are supported to which degree: In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. There is no NET3 suite. But I suppose you mean 4.4 BSD Lite. NetBSD 1.0 and FreeBSD 2.0 are examples of this. Basically the issue is just the file system. If the BSD file system works in Linux you can simply use that. In principle you could use any file system as long as you can get Linux installed on it and Lites to read it. If the purpose is to get Lites bootable on a Lites system you could tar your Linux disk and put it somewhere (tape, raw disk, over ethernet to another machine, ...). Then boot FreeBSD/NetBSD/Lites and open the tar into a BSD file system. Then try booting the system and tell the list what breaks. The next step is to fix all the problems. Later when ext2fs is ready you have already done the rest. Johannes From niklas@appli.se Fri Jan 20 03:03:17 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 11:55:05 +0200 id KAA01660; Fri, 20 Jan 1995 10:54:15 +0100 Date: Fri, 20 Jan 1995 04:51:08 -0500 From: Niklas Hallqvist To: jvh@cs.hut.fi Cc: agl@mac.glasnet.ru, lites@cs.hut.fi In-Reply-To: <199501200926.AA25068@glenlivet.cs.hut.fi> (message from Johannes Helander on Fri, 20 Jan 1995 11:26:07 +0200) Subject: Re: What kind of environment lites needs? >>>>> "Johannes" == Johannes Helander writes: Johannes> If anyone has a good idea on how to support several device Johannes> numbering schemes at once let me know. One idea would be to Johannes> make the numbering per file system type. Then an ext2 file Johannes> system would have Linux device numbers and a BSD file system Johannes> BSD file numbers. Bad, at least in the long run. At some point ufs will get written for Linux and people will it use for their root fs. I have no better proposals than the others you presented. I just wanted to bring forward my opinion on the fstype->devno hack. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG WWW: Here Sweden From agl@mac.glasnet.ru Fri Jan 20 03:55:15 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 12:43:54 +0200 id m0rVGow-0006acC; Fri, 20 Jan 95 13:43 GMT+0300 Date: Fri, 20 Jan 95 13:43 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: Booting from Linux, UFS vs ext2fs and the rest of the stuff X-Mailer: GNOS 1.14 I've heard that most ufs implementaions write control information before actual data so I'm getting suspicious about switching to it, as for ufs under linux, actually anybody is doing this and a Of cource sometimes ufs is better (say you're installing OSF/1 and is reading release notes for the version 3.0 "...intensive mmap()ing on the Advanced FS (aka POLYCENTER?) might hang the system ;-[ But what are pros & cons in relation to ext2fs? As I recall ext2fs is implemented correctly in Linux: i.e. data written first. AGL P.S. If you're writing to lites@cs.hut.fi do not Cc: to agl@anything I'm getting two copies for the same account otherwise: ain't good, I'm thinking of gatewaying it to news, but taking in account the anount of usage of our news system you guys might not like it so I'd better not yet, hmm From agl@mac.glasnet.ru Fri Jan 20 04:14:55 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 13:06:28 +0200 id m0rVHBR-0008tTC; Fri, 20 Jan 95 14:07 GMT+0300 Date: Fri, 20 Jan 95 14:07 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: Agh, as for the NET3: X-Mailer: GNOS 1.14 I've meant the Linux's NET tools suites that are mutually incompatible What do you mean there's no such thing as a NET3? I'm running on on the mac.glasnet.ru AGL From agl@mac.glasnet.ru Fri Jan 20 09:52:58 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 18:06:51 +0200 id m0rVLqX-000APmC; Fri, 20 Jan 95 19:05 GMT+0300 Date: Fri, 20 Jan 95 19:05 GMT+0300 From: agl@mac.glasnet.ru (Anthony Graphics) To: lites@cs.hut.fi Subject: While putting my mailbox in danger I want to add this one to the X-Mailer: GNOS 1.14 productive discussion about FS in lites/mach. I wonder whether AdvFS specs are available from Digital? Btw, AdvFS is proprietary DEC's product or it's the OSF/1 standard part now? AGL ------ Start of included message ------ >From step.polymtl.ca!ldd Fri Jan 20 18:57:10 1995 (Smail3.1.29.1 #6) id m0rVLht-000APmC; Fri, 20 Jan 95 18:57 GMT+0300 (5.67a/IDA-1.5 for agl@mac.glasnet.ru); Fri, 20 Jan 1995 10:52:45 -0500 Date: Fri, 20 Jan 1995 10:52:45 -0500 From: "Louis-D. Dubeau" To: agl@mac.glasnet.ru In-Reply-To: (agl@mac.glasnet.ru) Subject: Re: Booting from Linux, UFS vs ext2fs and the rest of the stuff Content-Type: text Content-Length: 1512 >>>>> "AG" == Anthony Graphics writes: AG> I've heard that most ufs implementaions write control AG> information before actual data so I'm getting suspicious about AG> switching to it, as for ufs under linux, actually anybody is AG> doing this and a Of cource sometimes ufs is better (say you're AG> installing OSF/1 and is reading release notes for the version AG> 3.0 "...intensive mmap()ing on the Advanced FS (aka AG> POLYCENTER?) might hang the system ;-[ But what are pros & AG> cons in relation to ext2fs? As I recall ext2fs is implemented AG> correctly in Linux: i.e. data written first. Here is what my personnal experience tells me. This is what usually happens after a fsck on a ufs volume (on Solaris 2.3 and Mach 3.0 + UX42) or an e2fsck on a ext2fs volume (Linux): ufs: Murphy's law is king. If some data has the slightest chance to get corrupted, it will. Every time a power loss occurs, I experience data corruption problems. Even files that were closed ages ago at the time of the power loss can get corrupted (don't ask me why). ext2fs: you can play with the power switch as you like. Most of what can be recovered will get recovered. I have experienced data corruption on a ext2fs file system only once. I don't post this to lites@cs.hut.fi because I don't want to start a fs religion war. ldd -- Louis-Dominique Dubeau == ldd@step.polymtl.ca == hallu@info.polymtl.ca -- -- Linux on Mach project: http://step.polymtl.ca/~ldd/ ------ End of included message ------ From mike@cs Fri Jan 20 12:05:12 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 20:34:10 +0200 Date: Fri, 20 Jan 95 11:34:02 -0700 From: mike@cs (Mike Hibler) To: lites@cs.hut.fi Subject: Re: While putting my mailbox in danger I want to add this one to the > Date: Fri, 20 Jan 1995 10:52:45 -0500 > From: "Louis-D. Dubeau" > To: agl@mac.glasnet.ru > Subject: Re: Booting from Linux, UFS vs ext2fs and the rest of the stuff > > >>>>> "AG" == Anthony Graphics writes: > > AG> I've heard that most ufs implementaions write control > AG> information before actual data so I'm getting suspicious about > AG> switching to it, as for ufs under linux, actually anybody is > AG> doing this and a Of cource sometimes ufs is better (say you're > AG> installing OSF/1 and is reading release notes for the version > AG> 3.0 "...intensive mmap()ing on the Advanced FS (aka > AG> POLYCENTER?) might hang the system ;-[ But what are pros & > AG> cons in relation to ext2fs? As I recall ext2fs is implemented > AG> correctly in Linux: i.e. data written first. > > Here is what my personnal experience tells me. This is what usually > happens after a fsck on a ufs volume (on Solaris 2.3 and Mach 3.0 + > UX42) or an e2fsck on a ext2fs volume (Linux): > > ufs: Murphy's law is king. If some data has the slightest chance to > get corrupted, it will. Every time a power loss occurs, I experience > data corruption problems. Even files that were closed ages ago at the > time of the power loss can get corrupted (don't ask me why). > Counter opinion: >From my experience in the last 10 years or so of using/maintaining hundreds of GBs of FFS filesystems, I have rarely seen problems due to unexpected power failures (i.e. due to the write policies of the software). This includes a current system with a 16MB buffer cache. Most of the problems I have seen have been due to hardware failures or stupidity on my part (an example of murphy's law: if you are going to screw up your arithmetic when laying out disk partitions, you will inevitably do it in such a way that your swap partition overlaps a filesystem :-) However, the problem certainly exists. I know that CSRG would like to incorporate the work of Granger and Patt[1] in 4.4-Lite The Final Chapter, but I don't know if it will happen. Though largely addressing performance, it also makes stronger integrity guarantees. [1] Gregory R. Ganger, Yale N. Patt, "Metadata Update Performance in File Systems", OSDI Proceedings, 1994. From mitchem%sctc.com@spirit.sctc.com Fri Jan 20 14:40:09 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 20 Jan 1995 23:19:45 +0200 20 Jan 95 15:21 CST Date: Fri, 20 Jan 1995 15:18:50 -0600 From: Terrence Mitchem Subject: /mach_servers/mach_init dying under Lites/Mach4/NetBSD-1.0 System To: lites@cs.hut.fi For some reason, mach_init is dying on my system and causing Lites to panic. Here is the setup I am using: Environment: NetBSD-1.0 OS: Lites (950114) Kernel: Mach4 (Uk02p8) On this system, /mach_servers/mach_init is just a link (I've tried symbolic and hard) to /sbin/init. The really weird part is that this used to work. Then I reinstalled NetBSD-1.0 and restored the original system from tape and now it won't work. Recompiles and reinstallations of Mach4 and Lites have not helped. Anyone have any ideas? Any and all help is, as usual, greatly appreciated. thanks, tjm ps: If anyone knows what the top 5 reasons for mach_init dying are, please let me know since it might help me isolate the problem. From mitchem%sctc.com@spirit.sctc.com Sun Jan 22 18:20:49 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 23 Jan 1995 03:13:22 +0200 22 Jan 95 19:15 CST From: Terrence Mitchem Subject: mach_init dying on Mach4/Lites/NetBSD-1.0 To: lites@cs.hut.fi Date: Sun, 22 Jan 1995 19:13:02 -0600 (CST) Cc: mitchem@sctc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1017 If you've already seen this, my apologies. According to my mailer, this message bounced when I sent it to the list the first time. For some reason, mach_init is dying on my system and causing Lites to panic. Here is the setup I am using: Environment: NetBSD-1.0 OS: Lites (950114) Kernel: Mach4 (UK02p8) On this system, /mach_servers/mach_init is just a link (I've tried symbolic and hard) to /sbin/init. Mach4 boots, Lites loads and then panics saying that "init" died. The really weird part is that this setup used to work. Unfortunately, not to long ago, I reinstalled NetBSD-1.0 and restored the original system from tape after playing around with Linux for awhile and now Lites bombs. Recompiles and reinstallations of Mach4 and Lites have not helped. Anyone have any ideas? Any and all help is, as usual, greatly appreciated. thanks, tjm ps: If anyone knows what the top five or so causes for mach_init deaths are, please let me know since it might help me isolate the problem. From jvh@cs.hut.fi Sun Jan 22 23:45:47 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 23 Jan 1995 08:40:47 +0200 (5.65c8/HUTCS-C 1.3 for lites); Mon, 23 Jan 1995 08:40:42 +0200 Date: Mon, 23 Jan 1995 08:40:42 +0200 From: Johannes Helander To: Terrence Mitchem Subject: Re: mach_init dying on Mach4/Lites/NetBSD-1.0 Cc: lites@cs.hut.fi In-Reply-To: <199501230113.TAA04708@shade.sctc.com> References: <199501230113.TAA04708@shade.sctc.com> Organization: Helsinki University of Technology, CS Lab. Check that your emulator is of the same version as the server. Also check that the emulator is in the correct place: /mach_servers/emulator Also you could try picking up mach_init from leia. If that does work then there is some problem in starting init directly. If mach_init doesn't work either then there is some other problem. Check that every critical program is present and has execute rights: /mach_servers/startup, /mach_servers/emulator, /mach_servers/mach_init, /sbin/init, /bin/sh. Also check the console. It should be 0.0 crw------- 2 root wheel 0, 0 Jan 23 08:39 /dev/console Try isolating the problem as far as possible and I'll try to debug it and fix any problems as soon as we know what it is. Johannes From hohmuth@irs.inf.tu-dresden.de Thu Jan 26 00:17:21 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 26 Jan 1995 07:12:24 +0200 (5.67b+/DEC-Ultrix/4.3) id AA21865; Thu, 26 Jan 1995 04:12:43 +0100 Subject: Porting Lites to a different microkernel To: lites@cs.hut.fi Date: Thu, 26 Jan 1995 04:12:43 +0100 (MET) From: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Organization: Dept. of Computer Science, TU Dresden, Germany X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1099 Hi! We are currently considering a port of Lites to a different microkernel. I would appreciate any pointers to documentation, technical reports or other papers about Lites and its ancestor(s). The microkernel we will be using (a free research prototype currently in development, modelled after GMD's L3) is a lot more ``light- weight'' than Mach -- a characteristic I particularly like --, but that also means that some important Mach concepts won't be available. For instance, our kernel doesn't have ports with message queueing but only synchronous messages; however, the concepts of threads/tasks and memory objects/pagers is quite equivalent to Mach. Currently, we are thinking about emulating Mach port semantics in a special libmach_sa. That's why I need to find out which Mach concepts are being used in Lites and how. So far, I have been unsuccessful in trying to dig through the source code in order to understand the Lites implementation; hence my request for documentation. Thanks in advance, Michael -- Email: hohmuth@inf.tu-dresden.de WWW: http://www.inf.tu-dresden.de/~mh1/ From cmaeda@cs.washington.edu Fri Jan 27 14:38:34 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 27 Jan 1995 23:28:48 +0200 To: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Cc: lites@cs.hut.fi Subject: Re: Porting Lites to a different microkernel In-Reply-To: Your message of "Thu, 26 Jan 95 04:12:43 +0100." <199501260312.AA21865@irs.inf.tu-dresden.de> Date: Fri, 27 Jan 95 13:28:17 -0800 From: cmaeda@cs.washington.edu Date: Thu, 26 Jan 95 04:12:43 +0100 To: lites@cs.hut.fi From: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Subject: Porting Lites to a different microkernel We are currently considering a port of Lites to a different microkernel. I would appreciate any pointers to documentation, technical reports or other papers about Lites and its ancestor(s). Have you thought about how you will implement the equivalent of External Pagers? From sjt@epoch.ncsc.mil Fri Jan 27 14:35:23 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 27 Jan 1995 23:19:45 +0200 X-Mailer: exmh version 1.5.1 12/2/94 To: lites@cs.hut.fi Cc: sds@gareb.epoch.ncsc.mil, dep@gareb.epoch.ncsc.mil Subject: Building Lites Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jan 95 16:11:36 -0500 From: Jeff Turner We have now been able to successfully build the Lites 0.6 (950114) server and emulator on a Mach/UX system using odemake (and gcc 2.5.8). However, when we try to install and boot Lites (using a NetBSD 1.0 system), the server encounters an assertion failure while init is executing the /etc/rc* files. The assertion failure is: panic: Assertion '(&p->p_lock)->holder == 0' failed at .../serv/serv_synch.c:120 The traceback is: thread_wakeup_from_timer [serv/serv_synch.c:120] timer_thread [serv/timer.c:212] ux_thread_bootstrap [serv/ux_server_loop.c:110] Has anyone else seen this problem? The binary distribution of the Lites 0.6 server and emulator boot without any problem, so we're presuming that our build of MK83a is fine. From baford@schirf Fri Jan 27 17:58:41 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 28 Jan 1995 02:46:00 +0200 id RAA04243; Fri, 27 Jan 1995 17:46:01 -0700 To: cmaeda@cs.washington.edu Cc: lites@cs.hut.fi Subject: Re: Porting Lites to a different microkernel In-Reply-To: Your message of "Fri, 27 Jan 95 13:28:17 PST." <1221.791242097@hello-kitty.cs.washington.edu> Date: Fri, 27 Jan 95 17:46:01 MST From: Bryan Ford Chris Maeda wrote: > Date: Thu, 26 Jan 95 04:12:43 +0100 > To: lites@cs.hut.fi > From: hohmuth@inf.tu-dresden.de (Michael Hohmuth) > Subject: Porting Lites to a different microkernel > > We are currently considering a port of Lites to a different > microkernel. I would appreciate any pointers to documentation, > technical reports or other papers about Lites and its ancestor(s). > >Have you thought about how you will implement the equivalent >of External Pagers? L3 has external pagers, so if they're using an L3-like design, that shouldn't be a problem except for the nitty-gritty details of the actual pager interface. Bryan From lepreau Thu Feb 2 10:13:24 1995 id KAA10370; Thu, 2 Feb 1995 10:13:19 -0700 (5.65c8/HUTCS-S 1.4 for ); Thu, 2 Feb 1995 18:59:23 +0200 (Smail3.1.28.1 #10) id m0ra4sI-00009tC; Thu, 2 Feb 95 09:59 MST Date: Thu, 2 Feb 1995 09:59:18 -0700 (MST) From: Bill Collins To: lites@cs.hut.fi Subject: MK86 compile on FreeBSD Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone successfully compiled Mach under FreeBSD. I need a Mach kernel that handles the 4.4 file structure *AND* not fall apart probing my adaptech card. Bill Internet: collins@ariel.unm.edu BITnet/CREN: collins@unmb.bitnet From lites-readers-request Mon Feb 13 14:41:35 1995 id OAA11823; Mon, 13 Feb 1995 14:41:29 -0700 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Feb 1995 23:28:37 +0200 (5.65c8/HUTCS-C 1.3 for lites); Mon, 13 Feb 1995 23:28:45 +0200 Date: Mon, 13 Feb 1995 23:28:45 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Lites 0.7 snapshot 950213 available Organization: Helsinki University of Technology, CS Lab. A new Lites snapshot (actually two) is available as leia.cs.hut.fi:/foggy/qwerty/Lites-0.7.950213.tar.gz This snapshot includes a preliminary Alpha port by Jukka Virtanen and me. The port is not complete but involved a huge amount of type cleanup which is now merged into Lites. The i386 port has been compiled (by gcc 2.6.3) and tested (although not extensively). Any further testing, as well as making sure the pc532 and parisc still work, would be important and appreciated. There is an another snapshot Lites.950211.tar.gz that is an intermediate stage of the alpha merging. This may be useful in case everything breaks as it has less changes. Otherwise just ignore it. The bin subdirectory contains i386 binaries: startup.Lites.0.7.LARGE+WS+UNTESTED+DEBUG.gz xstripped gzipped startup.Lites.0.7.LARGE+WS+UNTESTED+DEBUG.unstripped.gz unstripped gzipped emulator.Lites.0.7.gz unstripped gzipped Johannes From lites-readers-request Mon Feb 13 14:49:33 1995 id OAA12158; Mon, 13 Feb 1995 14:49:31 -0700 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Feb 1995 23:40:58 +0200 (5.65c8/HUTCS-C 1.3 for lites); Mon, 13 Feb 1995 23:41:11 +0200 Date: Mon, 13 Feb 1995 23:41:11 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Lites release schedule Organization: Helsinki University of Technology, CS Lab. Assuming the newest snapshot isn't totally broken or something else happens I'm planning on the following schedule: 1995/02/13 Monday today, 64 bit fixes merged 1995/02/18 Saturday freeze, submit any new code before this 1995/02/23 Thursday last minute bugfixes deadline 1995/02/26 Sunday Lites 1.0 public release That leaves this week to submit new code for merging and this week and a few more days next week for final testing. Johannes From tseidmann@simultan.ch Wed Feb 15 00:28:00 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 15 Feb 1995 08:56:38 +0200 15 Feb 95 07:58:32 MET From: "Seidmann Thomas" Organization: Simultan AG To: lites@cs.hut.fi Date: Wed, 15 Feb 1995 07:57:54 MET Subject: Assertion in import_mach.h Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Hi, I have a problem in running a version of Lites 0.6, which I've built myself. I build Lites with Mach4 under Linux. For purposes of running Lites I made an BSD partition an installed FreeBSD 2.0. I've verified the Mach4 build using the test-server AND the pre-built binary version of Lites from leia.cs.hut.fi; I didn't encounter any problem. However running "my own" version of Lites resulted in an assertion failure right after the copyright message of Lites in server/serv/import_mach.h (inline function mutex_try_lock). I've scanned through the mach4-users archive to find out somebody else encountered this problem already. Looking at import_mach.h and comparing the MK83a and Mach4 headers I've an important difference in the behaviour of the mutex_init macro, which wouldn't reset the "holder" member of mutex_t in my configuration (the reason of the assertion failure, I thought). Then I've added a copy of mutex_init to import_mach.h, which would set holder to 0 and recompiled the Lites server. Disappointed I encountered no change. Can anyone of you guys help me? THNX in advance. Regards, Thomas o__ _.>/)_ Thomas Seidmann (tseidmann@SIMULTAN.CH) (_) \(_).... Simultan AG Kantonsstrasse CH-6246 Altishofen Switzerland From csb@ullman.elte.hu Wed Feb 15 07:08:42 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 15 Feb 1995 15:49:27 +0200 1995 14:47:44 +0200 1995 14:48:09 +0100 Date: Wed, 15 Feb 1995 14:48:09 +0100 (NFT) From: Csizmazia Balazs Subject: Re: Assertion in import_mach.h To: Seidmann Thomas Cc: lites@cs.hut.fi In-Reply-To: <150BA0A6E6A@jura.SIMULTAN.CH> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! On Wed, 15 Feb 1995, Seidmann Thomas wrote: > Hi, > > I have a problem in running a version of Lites 0.6, which I've built > myself. I build Lites with Mach4 under Linux. For purposes of running ... > assertion failure, I thought). Then I've added a copy of mutex_init > to import_mach.h, which would set holder to 0 and recompiled the > Lites server. Disappointed I encountered no change. Can anyone of you > guys help me? THNX in advance. > Hello! Dort ist ein #define Zeile, definiert mit dem Makro-Wert 1. Du soolst es veraendern auf 0 (es ist ein Bug in der Mach4's thread package). (Es gibt ein anderer Platz in serv_synch.c (ich kann mich nicht mehr erinnern,wo es ist), dort sollst du es wiederholen ...) > Regards, > > Thomas Tschuss: Csizmazia Balazs csb@ullman.elte.hu From DALL@HFRD.DSTO.GOV.AU Thu Feb 16 17:02:33 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 01:53:22 +0200 10:23:19 +1030 Date: Fri, 17 Feb 95 10:24:26 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: <199502162211.AA10735@glenlivet.cs.hut.fi> References: <199502132141.AA02853@glenlivet.cs.hut.fi> <9502132345.AA20386@hfrd.dsto.gov.au> <199502162211.AA10735@glenlivet.cs.hut.fi> X-Hfrd: 1995021710230707 Johannes Helander writes: >> no major fixes to lites. The main hassles have been incompatable >> include files. > We should try to fix the problems. I don't think most people have > actually built programs with the include files. In fact the whole > system is rather messy with internal stuff, interface definitions, > and user level stuff all mixed together. One thig I ran into was that lack of a cpp definition to indicate "running in a lites environment" There is LITES, but that is used to indicate that the file is part of the lites server its self. I eventually concluded that there is no lites environment and have used #ifdef __NetBSD__ Which works for all the cases I have run into. However, this may not always be sufficient. ie, one may need to have #if defined(__NetBSD__) && defined(__LITES_ENV__) or whatever. I have adopted a convention where pc532-lites is the configuration for gnu packages. In some cases this is just an alias for pc532-netbsd, but in some cases it is slightly different. I have also been making xxx-ux an alias for xxx-mach. In general saying something is running mach, doesn't say much about the programming environment. It is much more relevant to say what server is running (ux, lites, hurd). Dunno if the FSF will like my changes though. There is not a lot of precedent for how mach support should be put into the programming environment. I try and keep all the mach stuff in /usr/mach/{include,lib,bin,man,etc,sbin,etc}. Gcc configured for pc532-lites automatically searches for include files in /usr/mach/include and for libraries in /usr/mach/lib. The /usr/mach/include files aren't in general ansi C and C++ safe, so I arrange for fixinclude to be run on /usr/mach/include. Mostly the lites include files are fairly good because they seem to be taken from 4.4lite and are pretty compatable with NetBSD. I can imagine there might be incompatabilites though if you wanted to use mach/lites include files in the same program as ultrix or linux or something include files. Ian From DALL@HFRD.DSTO.GOV.AU Thu Feb 16 17:13:57 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 02:08:09 +0200 10:38:18 +1030 Date: Fri, 17 Feb 95 10:39:27 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: gdb and lites X-Hfrd: 1995021710380858 I have a problem with gdb and lites. I have no problem attaching to existing processes, but I can't debug an inferior process. I am using gdb 4.13 with some minor fixes by me. The problem seems to be that gdb controls the inferior process initially by intercepting messages between the process and the unix server and counting the number which correspond to exec system calls. Two execs (one for the shell and one for the process its self) have to occur before the desired process is loaded and breakpoints can be set. The problem is that gdb losses control after it forwards the first exec message. This works fine under ux. ux and lites *do* use the same message number for exec (although the semantics may be different). Does the interception of messages necessarilly get inherited after the first exec? (I guess un mach parlance it is the port rights which would have to be inherited). Alternatively, does the lites emulator always send an execve message when execing a process? Finally, even after the second exec, I think that the address space isn't populated until an after_exec message. So should gdb wait for that? Does anyone have gdb debugging an inferior process (ie started with "run") under lites? If so, what is the secret? Ian From jvh@cs.hut.fi Thu Feb 16 17:47:23 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 02:41:49 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 17 Feb 1995 02:41:41 +0200 Date: Fri, 17 Feb 1995 02:41:41 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: gdb and lites In-Reply-To: <9502170009.AA11343@hfrd.dsto.gov.au> References: <9502170009.AA11343@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > The problem is that gdb losses control after it forwards the first > exec message. This works fine under ux. ux and lites *do* use the same > message number for exec (although the semantics may be different). The numbers are the same just because of gdb. > Does the interception of messages necessarilly get inherited after the > first exec? (I guess un mach parlance it is the port rights which No. If the server decides the program is 'security sensitive' it will kill the original task (and its associated ports) and create a new one. This happens if the program is set uid, set gid, or execute only (not readable). Otherwise the task will be reused and should be debuggable. The decision could be more selective. > would have to be inherited). Alternatively, does the lites emulator > always send an execve message when execing a process? Yes, except when execing the first progam (mach_init). > Finally, even after the second exec, I think that the address space > isn't populated until an after_exec message. So should gdb wait for > that? It will be populated later. When after_exec is called and the initial thread is resumed, only the emulator will be mapped along with a stack. Between after_exec and jumping to the application's entry point memory is mapped accordingly to the binary (text, data, bss or some sections in case of elf). Between the entry point and main() some shared libraries are often mapped. Thus the address space will be fully populated rather late and I don't see how gdb could know about it. Memory is mapped through bsd_vm_map RPC calls. You could spy on them and see when the region you wanted to insert break points into got mapped. If gcc is going to interpret RPC calls it should use MiG generated stubs. I guess server prefixes are needed (do_...) Another alternative is to wait for bsd_set_atexpansion(). This might provide some useful info also for the purpose of debugging. The way this would work is that the call would be moved after emul_exec_load. At this point the application binary is fully mapped and it will very soon be jumped into. The only missing thing is shared libraries that can't be deduced from the binary. > Does anyone have gdb debugging an inferior process (ie started with > "run") under lites? If so, what is the secret? Hm, I think I got it to work a long time ago but broke it since. Perhaps the best way would really be to trace memory mappings as then you could insert break points into shared libraries even if they are loaded later. bsd_vm_map is used for all file mappings except for the emulator itself (which is mapped by the server). mmap is translated into bsd_vm_map. So is Linux's uselib and mapping of executable files. Anonymous memory is msotly mapped through vm_map or vm_allocate, however. Johannes From jvh@cs.hut.fi Thu Feb 16 18:12:58 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 03:06:26 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 17 Feb 1995 03:06:18 +0200 Date: Fri, 17 Feb 1995 03:06:18 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: <9502162354.AA11173@hfrd.dsto.gov.au> References: <199502132141.AA02853@glenlivet.cs.hut.fi> <9502132345.AA20386@hfrd.dsto.gov.au> <199502162211.AA10735@glenlivet.cs.hut.fi> <9502162354.AA11173@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > One thig I ran into was that lack of a cpp definition to indicate > "running in a lites environment" There is LITES, but that is used to Perhaps it would be better to have LITES_SYSTEM mean server or emulator, LITES_SERVER mean just the server, etc. Then __Lites__ might be a proper user level definition. > indicate that the file is part of the lites server its self. I > eventually concluded that there is no lites environment and have used > #ifdef __NetBSD__ Which works for all the cases I have run into. > However, this may not always be sufficient. ie, one may need to have > #if defined(__NetBSD__) && defined(__LITES_ENV__) or whatever. This is pretty much what I had in mind. Lites doesn't have its own binaries but runs those of others'. But it is true that some things are Lites specific, this might include gdb, ps, top, ... > I have adopted a convention where pc532-lites is the configuration for > gnu packages. In some cases this is just an alias for pc532-netbsd, > but in some cases it is slightly different. I have also been making > xxx-ux an alias for xxx-mach. In general saying something is running > mach, doesn't say much about the programming environment. It is much > more relevant to say what server is running (ux, lites, hurd). Dunno > if the FSF will like my changes though. True, but rms made a decision that he is not going to change anything only a few months ago so there should be pretty good reasons and consensus to get him to change his mind. Besides there should be consensus in any case. > There is not a lot of precedent for how mach support should be put > into the programming environment. I try and keep all the mach stuff in > /usr/mach/{include,lib,bin,man,etc,sbin,etc}. There is also /mach_servers/. I was thinking of moving the emulator and mach_init to /sbin and make Lites independent of /mach_servers/. Some programs need to be on the root partition. mach_init and emulator are mandatory (ok. mach_init can be /sbin/init but then there is no service server). cored (the core dumping daemon) should probably go on the root as well as soon as someone writes it. But yes it could go in /usr/sbin/ or /usr/mach/sbin too. migcom should then go into /usr/mach/libexec/; machid, snames, etc. into /usr/mach/sbin/; ms, pinfo, etc. into /usr/mach/bin/. ps, top, w should probably go into /bin. I guess what we need is a complete list of all the programs and a decision where to put them. The main issue is anyways should the programs be separated (--> /usr/mach/sbin etc) or not (--> /usr/sbin etc). > Gcc configured for > pc532-lites automatically searches for include files in > /usr/mach/include and for libraries in /usr/mach/lib. The > /usr/mach/include files aren't in general ansi C and C++ safe, so I > arrange for fixinclude to be run on /usr/mach/include. If any Lites includes are broken, please point them out and I'll fix them (assuming I can figure out what to do about them). > Mostly the lites include files are fairly good because they seem to be > taken from 4.4lite and are pretty compatable with NetBSD. I can > imagine there might be incompatabilites though if you wanted to use > mach/lites include files in the same program as ultrix or linux or > something include files. Sounds scary. Johannes From jkh@freefall.cdrom.com Thu Feb 16 20:37:34 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 05:32:33 +0200 Fri, 17 Feb 1995 05:05:26 +0200 by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id TAA11801; Thu, 16 Feb 1995 19:05:15 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Ian Dall Cc: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: Your message of "Fri, 17 Feb 1995 10:24:26 +1030." <9502162354.AA11173@hfrd.dsto.gov.au> Date: Thu, 16 Feb 1995 19:05:14 -0800 From: "Jordan K. Hubbard" > indicate that the file is part of the lites server its self. I > eventually concluded that there is no lites environment and have used > #ifdef __NetBSD__ Which works for all the cases I have run into. This is evil. What about the other platforms that run over LITES? While we in the FreeBSD group really haven't made much noise about LITES yet (and for this, I must apologise to Johannes) I don't think that this state of affairs will necessarily continue forever, nor will our users necessarily stay ignorant of LITES. The ball we have our eye on exclusively, and have for the last 5 months, is FreeBSD 2.1. Once that's out the door, I think we shall be allowing our eyes to wander a bit more to the stuff we actually think is really *interesting* and not just vital! :-) So with that in mind, I would encourage anyone working with LITES to at least not try to be too NetBSD-centric in their programming practices. No slam against NetBSD intended, but I think our user base is a little larger at this point.. :-) Jordan From DALL@HFRD.DSTO.GOV.AU Fri Feb 17 00:52:13 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 09:43:40 +0200 15:16:58 +1030 Date: Fri, 17 Feb 95 15:17:56 +1030 From: Ian Dall To: jkh@freefall.cdrom.com Cc: dall@hfrd.dsto.gov.au, jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: <11799.792990314@freefall.cdrom.com> References: <9502162354.AA11173@hfrd.dsto.gov.au> <11799.792990314@freefall.cdrom.com> X-Hfrd: 1995021715164299 "Jordan K. Hubbard" writes: >> indicate that the file is part of the lites server its self. I >> eventually concluded that there is no lites environment and have >> used #ifdef __NetBSD__ Which works for all the cases I have run >> into. > This is evil. What about the other platforms that run over LITES? Well, not actually *evil* :-) There are several things one might want executeables in include files to be conditional apon. Lites aims to look like a native kernel to whatever executeable is running. So if I am compiling under lites to generate NetBSD executeables, then #ifdef __NetBSD__ is the thing to do. On the other hand, if I am generating FreeBSD executeables then I might make code conditional on __FreeBSD__ or whatever. I agree it would be evil to use #ifdef __NetBSD__ to indicate running under a Lites server, but it should be rare that it is necessary to *know* you are running under a Lites server. The one exception I can see currently might be gdb and that can be covered with configuration files. Note that none of this is relevant to the lites code its self, but for building other packages under lites, including maybe some utility and auxilliary programs in the mk and user collections which were somewhat 4.3BSD oriented. I've made some of that #ifdef __NetBSD__ when maybe it should be #if defined(__FreeBSD__) || defined(__NetBSD__) but since I don't have free bsd, I don't know and can't check. If the NetBSD and FreeBSD people are talking, maybe we could just have #ifdef __BSD44__ :-). > So with that in mind, I would encourage anyone working with LITES > to at least not try to be too NetBSD-centric in their programming > practices. When I say "Which works for all the cases I have run into." I mean and is appropriate. This is not say there aren't tricky issues. If I want to generate a 4.3 executeable (or linux or freebsd or whatever) to run under lites, I had better make sure that all the right include files and libraries are used and that the right cpp symbols are defined, not just for the package but for any linked libraries as well and make sure the executeable is generated with the right executeable format. All in all, supporting compilation in multiple formats is as painful as crosscompiling for a different achitecture. The ability to run already built executeables is pretty handy as a transition aid though, and for commercial architectures it is nice to be able to run commercial software. > No slam against NetBSD intended, but I think our user > base is a little larger at this point.. :-) So how are the ns532, mips, sparc, sun3 etc ports going? The choice for me was easy. I could just untar the pc532 NetBSD executeables. There was no such choice for FreeBSD. I'm not interested in getting into a holy war, my choice of which to support is entirely pragmatic. Ian From jkh@freefall.cdrom.com Fri Feb 17 01:38:40 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 10:31:20 +0200 Fri, 17 Feb 1995 10:31:25 +0200 by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id AAA00460; Fri, 17 Feb 1995 00:31:00 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Ian Dall Cc: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: Your message of "Fri, 17 Feb 1995 15:17:56 +1030." <9502170447.AA12697@hfrd.dsto.gov.au> Date: Fri, 17 Feb 1995 00:31:00 -0800 From: "Jordan K. Hubbard" > I agree it would be evil to use #ifdef __NetBSD__ to indicate running > under a Lites server, but it should be rare that it is necessary to > *know* you are running under a Lites server. The one exception I can see > currently might be gdb and that can be covered with configuration > files. Sorry, I thought that was exactly what you were doing. Apologies if it was only for something truly NetBSD specific, like some hack to gdb.. I should probably read my mail more slowly, but that's difficult with >400 messages a day sometimes! :-) > So how are the ns532, mips, sparc, sun3 etc ports going? Sorry again. Like I said, I wasn't meaning to slam NetBSD with my comment, I simply wished to make a plea for what I saw as potentially (or currently, for all I know) `the bigger side' of LITES. To be sure, NetBSD offers a lot more platforms than we do and we've always given then their due there, no question about it. But the Intel platform is a pretty serious one, and we're becoming fairly major players there now (given that it's our one and only focus), so I would just like to put in my request in advance that a reasonable amount of attention be devoted to that part of LITES's user base. I also realize that for someone with something like a PC532 (though it must also be said that only a *complete idiot* would own one of those :-), the choice is absolutely clear - NetBSD. I don't argue that at all. It's just that I would really hate to see LITES become another SPRITE. Back when Sprite was being developed, Prof. John Ousterhout was firmly of the opinion that PCs were toys, nobody would want to run on one, and that the only platforms worth porting to or focusing on were the DECSTATIONS, SPARCs and other various workstation hardware they had lying around UCB. Had John perhaps been a little less short-sighted, we might be in a very different situation today. Sprite had a good 5 year lead on a lot of the operating systems coming out for the lucrative PC market today, it offered features people are only now coming around to understanding the benefits of, much less implementing, and they threw it all right down the toilet. Sprite is dead and for all practical purposes forgotten. Shit! Let's not make the same mistake twice, that's all I ask! :-) Jordan P.S. For the humor impaired: I also own a PC532! From mike@cs Fri Feb 17 10:44:50 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 19:16:18 +0200 Date: Fri, 17 Feb 95 10:16:16 -0700 From: mike@cs (Mike Hibler) To: dall@hfrd.dsto.gov.au, jvh@cs.hut.fi Subject: Re: Lites release schedule Cc: lites@cs.hut.fi > Date: Fri, 17 Feb 1995 03:06:18 +0200 > From: Johannes Helander > To: Ian Dall > Cc: lites@cs.hut.fi > Subject: Re: Lites release schedule > > ... > There is also /mach_servers/. I was thinking of moving the emulator > and mach_init to /sbin and make Lites independent of /mach_servers/. I'm not sure what you mean by "independent", the emulator is intimately tied to the server in /mach_servers, I think they belong together. > I guess what we need is a complete list of all the programs and a > decision where to put them. The main issue is anyways should the > programs be separated (--> /usr/mach/sbin etc) or not (--> /usr/sbin etc). I vote for keeping the binaries separate. I don't want Mach-ish binaries in a standard tree that our (non-Lites) BSD cannot execute. You can do this transparently to shells by using the @sys hack. On our BSD/Lites PA machines I have: /bin -> @sys/bin /etc -> @sys/etc etc. and then have /parisc_hpbsd and /parisc_lites directories with hierarchies under them. Since we don't have @sys under our BSD I also have: /@sys -> parisc_hpbsd This can lead to a lot of replication of binaries for common things, but that isn't anything that a few symlinks can't solve :-) W.r.t. another comment by Jordan: I am more worried about Lites becoming x86-centric than I am about it becoming BSD-centric. You can certainly argue that 99% of all BSD users are on "PC"s so that is the way it should be, but by the same argument you can say that 99.9% of all computer users could care less about BSD so why are we all wasting our time anyway :-) From blackbob@wwa.com Fri Feb 17 10:48:55 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 17 Feb 1995 19:40:08 +0200 id m0rfWhc-000bmMC; Fri, 17 Feb 95 11:42 CST From: blackbob@wwa.com (Johnny B. Goode) Subject: Linux in Lites To: lites@cs.hut.fi Date: Fri, 17 Feb 1995 11:42:47 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 645 I just got Lites 0.7 up and running on my NetBSD 1.0 sytem. I also run Linux; can Lites actually run Linux binaries? How do I use them? Do I need to install the Linux shared libraries? Most importantly, can Lites talk to any of the Linux filesystems? If so, do I need to set up a disklabel on the Linux disk? Also, is there a bug list for Lites? I can't really tell how far along it is. Can it compile itself yet? I noticed a few strange things, for example, when I use kermit to call another sysem, it says "Login incorrect" under Lites but works fine elsewhere. I'm wondering if this is peculiar to my system. Cheers, Terry Murphy From jkh@freefall.cdrom.com Fri Feb 17 18:24:00 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 18 Feb 1995 03:07:38 +0200 Sat, 18 Feb 1995 02:41:49 +0200 by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA28166; Fri, 17 Feb 1995 16:39:07 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: mike@cs (Mike Hibler) Cc: dall@hfrd.dsto.gov.au, jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: Your message of "Fri, 17 Feb 1995 10:16:16 MST." <9502171716.AA27566@cs.utah.edu> Date: Fri, 17 Feb 1995 16:39:07 -0800 From: "Jordan K. Hubbard" > W.r.t. another comment by Jordan: I am more worried about Lites becoming > x86-centric than I am about it becoming BSD-centric. You can certainly > argue that 99% of all BSD users are on "PC"s so that is the way it should be, > but by the same argument you can say that 99.9% of all computer users could > care less about BSD so why are we all wasting our time anyway :-) Johannes, just shoot me when you think this conversation has veered too far from the practical aspects of LITES.. :-) Kindly permit me to rephrase my earlier point: LITES is an interesting and potentially useful (if it isn't already for a number of people) technology. For a useful and innovative technology to succeed, it requires exposure. Wide exposure means targeting those machines which are out there in the greatest quantity (and will run your product reasonably well - I'm not advocating a TRS-80 port here! :-). Right now, this is Intel. If (oh please oh please) Intel's fortunes should change tomorrow and the PowerPC climbs to the top of the heap, then I'll revise my stance accordingly. The point is that it doesn't matter what those PC users are running currently - our job is to win them over to A Better Way, no matter how hopeless a battle it may seem sometimes, and by winning them gain numbers and people who are willing to work on it. It's not just a numbers game - getting more people involved means more potential workers out there and a greater ability to advance the cause. Already we're getting contributions of things like ISDN code, IPX drivers, on-demand PPP, all the things we've always wanted ourselves but had no hope of actually finding the time to write. As we get bigger, we're finding (to our great joy) that people are starting to write it for us! If you hide your light under a bushel, this doesn't happen. This is why I'm very defensive against the workstation snobs (who tend to inhabit universities in large quantities :-) who insist that substabtial work go into platforms that are certainly superior but exist in far, far smaller numbers. This is not to say that you don't occasionally win here too - as the NetBSD people are fond of saying, a lot of people who have ALPHAS at home are also pretty intelligent people who often do the work of any 10 lesser programmers, but I can't count on always reaching those people. So I chose to simply use a much bigger net! :-) Just my two cents. I suppose I should really try to bring LITES up for myself one of these days, but time is always so limited.. How are things going WRT the build environment and hosting it under BSD? Are things GNU make'd to the point where I can now just unpack mach4 or something and type `gmake' on my favorite FreeBSD box to get a microkernel? I should probably go RTFM since I'm sure that this is all documented someplace.. I did try Johannes's "how to bootstrap LITES" on the WWW page, but it didn't work for me - I was unable to get past building Mach4 (with admittedly only 30 minutes invested). Jordan From DALL@HFRD.DSTO.GOV.AU Sun Feb 19 17:50:00 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 20 Feb 1995 02:40:12 +0200 11:10:35 +1030 Date: Mon, 20 Feb 95 11:11:50 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: more on gdb X-Hfrd: 1995022011102519 Gdb defininitely starts inferiors with an exec of sh with the arguments -c exec hello-world, so gdb should definitely see two exec messages, one for the shell and one for the process its self. Gdb definitely sees nothing after the first exec. I put a task_suspend in the hello-world, and it is still the same mid as the original forked gdb child. I notice there is a comment in gdb about a potential bug when it grabs the send port right from the inferior. The bug would occur if the process had multiple send port rights. Certainly pinfo reports that the suspended hello world process has send rights for more than one port. So... Is it a bug that the sub process has multiple send rights? Maybe after an exec, a process starts communicating with the server using a new port. That would certainly explain why gdb loses control! This is all speculation of course. Ian From jvh@cs.hut.fi Sun Feb 19 18:06:02 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 20 Feb 1995 03:00:30 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 20 Feb 1995 03:00:43 +0200 Date: Mon, 20 Feb 1995 03:00:43 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: more on gdb In-Reply-To: <9502200041.AA22809@hfrd.dsto.gov.au> References: <9502200041.AA22809@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. >So... Is it a bug that the sub process has multiple send rights? Maybe >after an exec, a process starts communicating with the server using a >new port. That would certainly explain why gdb loses control! This is >all speculation of course. server_exec_create_new_task sets a new bootstrap port (like newproc). server_exec_cleanup_task does not. The former is used for zapping security sensitive ('dangerous' in the code) tasks and the latter for reusing normal tasks. This means that if the task is not zapped it will keep the old bootstrap port which will stay the same. The bootstrap port is called process_self(), it represents the client to the server. Besides newproc and server_exec_create_new_task Lites does not set the bootstrap port. Johannes From jvh@cs.hut.fi Sun Feb 19 18:36:29 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 20 Feb 1995 03:31:09 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 20 Feb 1995 03:31:31 +0200 Date: Mon, 20 Feb 1995 03:31:31 +0200 From: Johannes Helander To: mike@cs (Mike Hibler) Cc: lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: <9502171716.AA27566@cs.utah.edu> References: <9502171716.AA27566@cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Mike Hibler writes: > > There is also /mach_servers/. I was thinking of moving the emulator > > and mach_init to /sbin and make Lites independent of /mach_servers/. > > I'm not sure what you mean by "independent", the emulator is intimately > tied to the server in /mach_servers, I think they belong together. The server doesn't know it was loaded from /mach_servers and it doesn't care. It could as well be loaded with the kernel or whatever. Certainly the server and emulator are closely related as you could see already with Lites 0.7 which emulator is incompatible with Lites 0.6 (reason: MiG did handle some alignments wrong on the Alpha so it was easier to change the order of the parameters than to fix MiG itself). But let's say on a boot floppy it would make sense to first load the kernel and server from one floppy and then have the emulator and some programs on the second. The emulator is a specialized shared library and not a server or alternatively it could be viewed as a shell interpreter of binaries. So it kind of belongs in /lib, kind of /sbin, and kind of /mach_servers. Doesn't really matter except in the floppy case and in the case where /mach_servers has been totally deleted or if the server isn't there. Consider replacing the default pager with Lites and packaging it with the kernel. In this case only emulator and mach_init would be in /mach_servers and if so, it'd make more sense to move them to /sbin and getting rid of /mach_servers. > You can do this transparently to shells by using the @sys hack. On our > BSD/Lites PA machines I have: Even if I implemented @sys in Lites (together with Juki) I don't really like it. It would be better to just interpret symlinks and even so I think it is a hack and the programs should have a real place. Something like ps, w, and top @sys seems solves well though. > W.r.t. another comment by Jordan: I am more worried about Lites becoming > x86-centric than I am about it becoming BSD-centric. You can certainly As Lites is relatively easy to port to any machine running Mach it seems more like a worry that the Mach kernel becomes too 386 centric. As for now the most active Lites collaborators are running pc532s, snakes, and alphas. Doesn't seem very peecee centric to me :-). > argue that 99% of all BSD users are on "PC"s so that is the way it should be, > but by the same argument you can say that 99.9% of all computer users could > care less about BSD so why are we all wasting our time anyway :-) Good question 1/2-). One of the goals in Lites has been that you could run any unix binary without needing to care where it came from. But there are still many things to do. More file systems are needed, more emulation personalities are needed (SVR3, SVR4), a clean way to cope with different /dev directories is needed, support for different mouse and frame buffer interfaces (for X) etc are needed. Johannes From jvh@cs.hut.fi Sun Feb 19 19:02:15 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 20 Feb 1995 03:55:46 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 20 Feb 1995 03:56:06 +0200 Date: Mon, 20 Feb 1995 03:56:06 +0200 From: Johannes Helander To: blackbob@wwa.com (Johnny B. Goode) Cc: lites@cs.hut.fi Subject: Re: Linux in Lites In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. Johnny B. Goode writes: > I just got Lites 0.7 up and running on my NetBSD 1.0 sytem. > I also run Linux; can Lites actually run Linux binaries? How do I Yes, I've tried emacs with and witout X, tcsh, zsh, and doom. > use them? Do I need to install the Linux shared libraries? Yes, in the standard Linux place (/lib). However, redirecting the int80 trap is very slow and MK83 leaks ports in the process which makes the kernel crash very quickly. To solve the problem I made a shared libc that doesn't do the int80 but instead a subroutine call. I need to make that library available and convince the libc maintainer to pick up the patch (it is a small change that can be turned on with an ifdef). OSF and Utah may have fixed the port leak in their kernels but for speed you will want to use the modified libc anyways. > Most importantly, can Lites talk to any of the Linux filesystems? There is a preliminary minixfs and ext2fs is being ported. But as it right now stands it is too early to say yes. > If so, do I need to set up a disklabel on the Linux disk? That depends on the Mach kernel you are using. Mach is interpreting disk labels at the moment. > Also, is there a bug list for Lites? I can't really tell how > far along it is. Can it compile itself yet? I noticed a few I've compiled it under a NetBSD 1.0 environment running Lites. I believe it has been built under Lites running in a FreeBSD 2.0 environment as well. In addition to the i386 the pc532 and PA-RISC ports are self-hosting or very close to it. The mips and Alpha ports need more work before they can be used. > strange things, for example, when I use kermit to call another > sysem, it says "Login incorrect" under Lites but works fine > elsewhere. I'm wondering if this is peculiar to my system. Well, we need a bug list. I've never tried kermit under Lites and I'm not aware of anyone else doing it before you either. Ian sent me some fixes to the tty code so you could try again soon. Thanks for the report, Johannes From jvh@cs.hut.fi Sun Feb 19 19:48:37 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 20 Feb 1995 04:43:50 +0200 (5.65c8/HUTCS-C 1.3 for lites); Mon, 20 Feb 1995 04:43:59 +0200 Date: Mon, 20 Feb 1995 04:43:59 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Lites release schedule In-Reply-To: <9502200208.AA23468@hfrd.dsto.gov.au> References: <9502171716.AA27566@cs.utah.edu> <199502200131.AA16432@glenlivet.cs.hut.fi> <9502200208.AA23468@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > Mike> I'm not sure what you mean by "independent", the emulator is > Mike> intimately tied to the server in /mach_servers, I think they > Mike> belong together. > > I once made the mistake of trying to replace emulator on a running system. > I immediately realized that there is a difference between the way you treat > emulator and startup ;-( I do it all the time. You just need to be aware that the disk image is mapped to all running programs and trashing it is a bad idea. You also need to be aware that in order to run *any* binary you need to have a working emulator. How to replace it then? 1) copy the new emulator into your machine or compile it. Do NOT overwrite the old one. 2) test the new emulator. e.g. like this: ./emulator.new /sbin/sh if the shell appears to work then it is probably ok. Test it more if you wish. 3) rm -f /mach_servers/emulator.old 4) mv /mach_servers/emulator /mach_servers/emulator.old 5) mv emulator.new /mach_servers/emulator You will get a diagnostics message on the console that /mach_servers/emulator was not found when executiong the second mv (5). That doesn't matter, /mach_servers/emulator.old is used instead. Don't trash /mach_servers/emulator.old. It is still being used by many programs. It is ok to rm it. The disk space will be freed when the image is unmapped, i.e. usually never because /sbin/init uses it. The final umount in halt should take care of the unreferred disk images. Unfortunately Lites doesn't currently umount the root properly (should be fixed). Thus fsck will scavenge the image after reboot. > Hmm. I set my path based on the exit status of /usr/mach/bin/mach3 if > it exists. This is not quite so transparent as the @ hack but is quite > useable. Of course this doesn't solve the problem if you want to > support multiple servers on the one machine. You could use /usr/mach/bin/mach3 in /etc/rc to decide how to mount. You could union_mount a directory with mach stuff on top of the normal directories. Just an idea, not a very good one I admit. If you need to distinguish between Lites and whatever it should be easy to modify /usr/mach/bin/mach3 to check not only for mach3 but also Lites (e.g. do an bsd_after_exec RPC (101001) and see that it returns LITES_EALREADY. That'll hardly happen anywhere else :-). > Yep. I think multiple ports (up to a point) help shake down both the > design and the implimentation. The need to support multiple ports > is an incentive to keep things well modularized and other ports can > help expose latent bugs. This has very much been the case. Doing several ports at a rather early stage minimized machine dependencies quite efficiently. Several bugs have been found this way. Of course I haven't made life easy to you and Mike by changing the interfaces all the time. One port is easy to do by just copying code. But when there are five it becomes important to identify common code and join the branches back together. Johannes From jvh@cs.hut.fi Thu Feb 23 19:47:27 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Feb 1995 04:32:47 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 24 Feb 1995 04:33:26 +0200 Date: Fri, 24 Feb 1995 04:33:26 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: Lites 0.8 available Organization: Helsinki University of Technology, CS Lab. There is a new Lites snapshot available leia.cs.hut.fi:foggy/qwerty/Lites-0.8.950223.tar.gz It fixes various bugs and inconveniences. There is a new (read only) Minix File System from Csizmazia Balazs. There are i386 STD+WS binaries in the bin/ subdirectory. This is supposed to be pretty much final. I will do some more testing and hope others will too. Thanks, Johannes From cmaeda@cs.washington.edu Fri Feb 24 01:19:51 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Feb 1995 09:35:05 +0200 X-Mailer: exmh version 1.5.3 12/28/94 To: lites@cs.hut.fi Subject: buildable user collection? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Feb 1995 23:35:42 PST From: Chris Maeda Has anyone converted the user collection (snames, mach_init, etc) to the new build environment yet? From DALL@HFRD.DSTO.GOV.AU Fri Feb 24 06:47:14 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Feb 1995 15:37:01 +0200 11:12:15 +1030 Date: Fri, 24 Feb 95 11:13:28 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: Where are we at? X-Hfrd: 1995022411115614 I haven't had time to try the last tar, but assuming it is just a version with the patches applied, it should be pretty OK. I have been working a bit more on tty_io.c. I was just arranging for the lites default tty settings to be applied at tty open time, this actually triggered a bug in the mk com driver for the pc532 which is why I haven't sent in the fix straight away. This is not worth holding up the release for. The worst that can happen is that stty reports different settings than are actually in effect, and that is only until the first time they are changed. IMO the significant outstanding problems from a useability view point are: o Shutdown. If I do a shutdown -h or shutdown -r, the processes all seem to get killed (thes system hangs), but I rarely get the syncing disks message. This is a problem which has come and gone a bit. At one point, this was fairly reliable (but never 100%). I'm not 100% sure if it is the halt/reboot which is failing, or whether something goes wrong before that in killing the processes. (It wouldn't be hard to check -- just do a shutdown followed by halt or reboot). I haven't had time to really follow this up, but it is annoying in practice due to the damage it can do to the filesystem. In practice, I limit the damage by remmebering to do a sync, just before a shutdown. o gdb. We have discussed the gdb problems before, and I am no closer to a solution. However, the ability to debug is fairly important! True, debugging using attach works (and is very useful for debugging lites its self), but for many programs, the ability to debug an inferior is important. I guess the gdb one is not a show stopper. How about the shutdown problem? Is anyone else seeing this? Ian From jvh@cs.hut.fi Fri Feb 24 18:15:36 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 25 Feb 1995 03:07:46 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sat, 25 Feb 1995 03:08:19 +0200 Date: Sat, 25 Feb 1995 03:08:19 +0200 From: Johannes Helander To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: Where are we at? In-Reply-To: <9502240043.AA15414@hfrd.dsto.gov.au> References: <9502240043.AA15414@hfrd.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. There will be a 1.1 release later. Right now we should try to see that nothing fatal has broken such as Lites not booting on some platform. Ian Dall writes: > o Shutdown. If I do a shutdown -h or shutdown -r, the processes all > seem to get killed (thes system hangs), but I rarely get the > syncing disks message. This is a problem which has come and gone I haven't seen problems on the i386 platform lately. But if any thread servicing any process is stuck some processes won't die. Of course no thread should ever get stuck but there are bugs (e.g. printf calling selwakeup might cause a deadlock if locks needed by selwakeup were held when calling printf). > o gdb. We have discussed the gdb problems before, and I am no closer Yes, a well working gdb is important. But that can't be done in a couple of days. > I guess the gdb one is not a show stopper. How about the shutdown problem? > Is anyone else seeing this? I can't repeat it so I can't fix it. Johannes From jjg@elsegundoca.attgis.com Fri Feb 24 19:06:35 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 25 Feb 1995 04:01:02 +0200 Date: Fri, 24 Feb 95 18:00:42 PST From: James Goss To: lites@cs.hut.fi Subject: FAQ for Lites Cc: jjg@elsegundoca.attgis.com Where is the FAQ for Lites? Thanks, Jay Goss From DALL@HFRD.DSTO.GOV.AU Sun Feb 26 16:17:14 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 27 Feb 1995 01:09:01 +0200 09:38:32 +1030 Date: Mon, 27 Feb 95 09:39:50 +1030 From: Ian Dall To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Subject: Where are we at + new problems... In-Reply-To: <199502250048.AA02094@glenlivet.cs.hut.fi> References: <9502240043.AA15414@hfrd.dsto.gov.au> <199502250048.AA02094@glenlivet.cs.hut.fi> X-Hfrd: 1995022709381212 Johannes Helander writes: > You could try to enable this code in kern_exit.c. It might cause > some of your shutdown delay. halt works fine on the i386 for me > though. Ah. I haven't tried this code yet, but if I do kill -9 2; shutdown -h now it works fine, so I guess that mach_init not dying is the problem. The thing is, I don't mind a 30 second wait, but if I don't kill pid 2 first, it is still waiting after 10 minutes or so. Maybe the timeout code in init isn't working (could be an init bug, or something wrong with setitimer or the delivery of signals). If no one else sees the problem, I guess it could be the netbsd532 init its self. I have noticed two new problems: One is that tty input strips the 8th bit. tty output is fine. At first I thought that it might be the duart not being set properly, but I stuck some code in the mk com driver to print out characters with the 8th bit set on input. They definitely get that far! Also, the problem seems to occur when using pseudo ttys as well (where the characters never go though the mk tty interface). Since you have an interest in 8 bit characters, I'm surprised this hasn't been noticed. I first noticed this with kermit. I could transfer binary files one way, but not the other! Try in emacs shell mode (which will allow you to insert an 8 bit character): stty cs8 -istrip tr '\341' '@' C-q 341 and see if it echos "a" (which it will do if the 8th bit got stripped) or "@". Another minor wart is that pseudo ttys have the baud rate set to 13 or 15 or so. It looks like that pseudo tty code thinks it is dealing with old fashioned way of specifying baud rate. This doesn't cause much of a problem except that emacs might do odd screen update optimization. The other problem is I can't *set* the system time (date) ;-(. On the plus side, I had little problem building lites-0.8. I ran into a small problem with using the wrong ld, but changing my path fixed that. Would it cause anyone any problem to use: "gcc -nostdlib" instead of "ld"? Ian From jvh@cs.hut.fi Mon Feb 27 23:48:24 1995 (5.65c8/HUTCS-S 1.4 for ); Tue, 28 Feb 1995 08:40:37 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 28 Feb 1995 08:41:01 +0200 Date: Tue, 28 Feb 1995 08:41:01 +0200 From: Johannes Helander To: lites@cs.hut.fi, mach3@cs.cmu.edu, mach4-users@cs Reply-To: jvh@cs.hut.fi Subject: Lites 1.0 available Organization: Helsinki University of Technology, CS Lab. Lites 1.0 is now available. The primary purpose of this release is to make the source available to interested parties. No installation kit is included. Lites is a 4.4 BSD Lite based server and an emulation library that provide free unix functionality to a Mach based system. Lites provides binary compatibility with 4.4 BSD, NetBSD (0.8, 0.9, and 1.0), FreeBSD (1.1.5 and 2.0), 386BSD, UX (4.3BSD) and Linux on the i386 platform. It has also been ported to the pc532, PA-RISC, and preliminarily to the R3000 and Alpha. Lites works with Mach 3.0, Mach 4, and RTMach. The recommended user platforms are NetBSD 1.0 and FreeBSD 2.0. Linux file system support is not included in this release. Lites was written by Johannes Helander at Helsinki University of Technology based on 4.4 BSD Lite from University of California and code written by the CMU Mach group. Several people have contributed to the effort, including Ian Dall, Mike Hibler, Jeff Law, Bryan Ford, Jukka Virtanen, Mary Thompson, Sampo Kellomaki, John Dyson, Csizmazia Balazs, Chris Maeda, and Timo Rinne. Special care has been put into keeping the code legally clean. Each piece of code that has been added to Lites has been carefully examined. There is no Net2 or 4.3 BSD code in Lites. Lites consists of a multithreaded single server that handles multiple system calls from any process, file paging, etc. and an emulation library that provides applications with an environment that looks like the system the application expects. The emulator is a completely new implementation and removes most of the security problems associated with earlier emulators (protection against resource attacks requires kernel support). Lites has been self hosting for several months. Its current performance is 6% lower than that of NetBSD 1.0 as measured by building gcc within the exact same machine and environment. Many obvious optimizations especially in the field of i/o have not yet been made. Lites is available from the following locations: Europe: ftp://ftp.funet.fi/pub/mach/lites/ USA: ftp://mach.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/src/lites/ For more information refer to the Lites home page http://www.cs.hut.fi/lites.html I have also made my Master's thesis available in postscript form under the same URL. It covers some aspects of Lites. Johannes From collins@unm.edu Wed Mar 1 13:40:09 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 1 Mar 1995 22:28:29 +0200 (Smail3.1.28.1 #10) id m0rjv1F-0000QxC; Wed, 1 Mar 95 13:29 MST Date: Wed, 1 Mar 1995 13:29:12 -0700 (MST) From: Bill Collins To: lites@cs.hut.fi Subject: NFS failure Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am running MK83i/Lites0.8. When I try to mount an NFS partition served by an AIX host, I get the following: progname: bad net address aroch with the following fstab entry: aroch:/nfs/u18 /nfs/u18 nfs rw 0 0 Any ideas? Bill Internet: collins@unm.edu Phone(wk): (505) 277-8090 From kstailey@leidecker.gsfc.nasa.gov Wed Mar 1 15:29:39 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 2 Mar 1995 00:22:20 +0200 Date: Wed, 1 Mar 95 17:22:09 -0500 From: Kenneth Stailey To: collins@unm.edu Cc: lites@cs.hut.fi In-Reply-To: (message from Bill Collins on Wed, 1 Mar 1995 13:29:12 -0700 (MST)) Subject: Re: NFS failure Try switching from hostnames to numeric ip addresses in the /etc/exports file and see what happens. From schimkat@cs.washington.edu Wed Mar 1 22:23:52 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 2 Mar 1995 07:11:18 +0200 Date: Wed, 1 Mar 1995 21:12:09 -0800 (PST) From: Schimkat Ralf-Dieter Sender: Schimkat Ralf-Dieter Reply-To: Schimkat Ralf-Dieter Subject: mach4/lites time daemon To: cmaeda@cs.washington.edu Cc: lites@cs.hut.fi Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII hi, after loading the emulator and startup-server lites complains about that the emulator and startup-server has " No Valid Symbol Table Header For Unix" though it compiled. Nevertheless it goes on until the time daemon gets invoked. it reports an error like "e_mapped_time_init failed". do you have any ideas ? ralf schimkat From DALL@HFRD.DSTO.GOV.AU Thu Mar 2 16:55:34 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 3 Mar 1995 01:42:51 +0200 10:13:20 +1030 Date: Fri, 3 Mar 95 10:14:34 +1030 From: Ian Dall To: lites@cs.hut.fi Subject: Making tty 8 bit clean X-Hfrd: 1995030310124787 I have cleaned up some of the tty code to make it 8 bit clean on input. Most of the problems resulted from promoting char's to int's. On a machine where char's were unsigned the old code may have worked. I removed the bit in termios.h which prevented the baud rates being defined in the new way. This does require that tty_status.h from the MK sources have the old style baud rates definition put inside of #ifndef LITES ... #endif. lites now sets the terminal defaults on open -- before it only attempted (ineffectually) to set its internal idea of the tty state from the mk tty status. I still notice that kermit doesn't work for transfers to the lites machine with large blocksize. This seems to be due to TTYHOG being exceeded in tty.c. It just throws away data (or maybe gives you a ^G) if TTYHOG is exceeded. I notice in the equivalent UX code there is a comment form Alessandro about "arbitrarilly increasing TTHIWAT by a factor of 10", so the problem has been seen before. The UX solution is not especially good of course. Particularly if you are using CTS/RTS flow control. The CTS/RTS flow control happens either in the duart its self or in the MK chario code. Either way, if data is being tranferred out of MK and flushed as fast as it arrives, the CTS/RTS flow control never comes into effect even though data is being lost. I think this is a feature of the BSD code. Better would be to stop the transfer of data from mk when TTYHOG or TTYHIWAT is reached. Then data would bank up in MK and the hardware flow control would come into effect. Then it raises the question of whether imaxbel should be imlimented in MK. (Generally a bad idea I think to have OS server specific stuff in MK but on the other hand, one wants to be able to do POSIX ttys). Anyway, with the proviso about the tty input overflow problem being unsolved, here are the patches. They are against lites 0.8 instead of lites 1.0, but there is negligible difference between the two. I notice that lites 1.0 still has the 0.8 version number even! The only non tty patch here is to make TARGET_OPTIMIZE_CFLAGS get set conditionally. Due to the order that things get included it was overriding the value in the server configuration (notably with the noopt option). Ian *** ../../../hut/src/lites-0.8/./conf/Makerules Fri Feb 17 10:19:22 1995 --- ./conf/Makerules Sun Feb 26 20:55:52 1995 *************** *** 86,92 **** HOST_CPPFLAGS += $(ALL_CPPFLAGS) TARGET_CPPFLAGS += $(ALL_CPPFLAGS) -nostdinc HOST_CFLAGS += $(HOST_CPPFLAGS) $(ALL_CFLAGS) -O -W ! TARGET_OPTIMIZE_CFLAGS = -O2 TARGET_CFLAGS += $(TARGET_CPPFLAGS) $(ALL_CFLAGS) $(TARGET_OPTIMIZE_CFLAGS) -W ${CXXX} # -Wswitch -Wreturn-type -Wcomment -Wuninitialized --- 86,94 ---- HOST_CPPFLAGS += $(ALL_CPPFLAGS) TARGET_CPPFLAGS += $(ALL_CPPFLAGS) -nostdinc HOST_CFLAGS += $(HOST_CPPFLAGS) $(ALL_CFLAGS) -O -W ! ifndef TARGET_OPTIMIZE_CFLAGS ! TARGET_OPTIMIZE_CFLAGS = -O2 ! endif TARGET_CFLAGS += $(TARGET_CPPFLAGS) $(ALL_CFLAGS) $(TARGET_OPTIMIZE_CFLAGS) -W ${CXXX} # -Wswitch -Wreturn-type -Wcomment -Wuninitialized *** ../../../hut/src/lites-0.8/./include/sys/termios.h Sun Jan 29 05:44:44 1995 --- ./include/sys/termios.h Mon Feb 27 06:57:35 1995 *************** *** 195,201 **** #define TCSASOFT 0x10 /* flag - don't alter h.w. state */ #endif - #ifndef LITES /* XXX for now. Fix Mach kernel */ /* * Standard speeds */ --- 195,200 ---- *************** *** 226,232 **** #define EXTA 19200 #define EXTB 38400 #endif /* !_POSIX_SOURCE */ - #endif /* LITES */ #ifndef KERNEL --- 225,230 ---- *** ../../../hut/src/lites-0.8/./server/conf/MASTER.local Thu Dec 15 17:22:47 1994 --- ./server/conf/MASTER.local Fri Feb 24 19:16:35 1995 *************** *** 1 **** ! makeoptions LOCAL_DEFINES="-DTIMEZONE=-120 -DDST=DST_EET" --- 1 ---- ! makeoptions LOCAL_DEFINES="-DTIMEZONE=570 -DDST=DST_AUST" *** ../../../hut/src/lites-0.8/./server/kern/kern_exit.c Thu Dec 15 08:52:34 1994 --- ./server/kern/kern_exit.c Sun Feb 26 20:20:31 1995 *************** *** 467,473 **** error = 0; return (error); } ! #if defined(LITES) && defined(parisc) /* * XXX major hack for BSD init compatibility. * --- 467,473 ---- error = 0; return (error); } ! #if defined(LITES) && (defined(parisc) || defined(ns532)) /* * XXX major hack for BSD init compatibility. * *** ../../../hut/src/lites-0.8/./server/kern/tty_subr.c Sun Jan 29 05:12:42 1995 --- ./server/kern/tty_subr.c Wed Mar 1 06:35:13 1995 *************** *** 103,109 **** */ getc(struct clist *clp) { ! char c; int s; s = spltty(); --- 103,109 ---- */ getc(struct clist *clp) { ! int c; int s; s = spltty(); *************** *** 112,118 **** splx(s); return -1; } ! c = *(clp->c_cf++); clp->c_cc--; clcheck(clp); splx(s); --- 112,118 ---- splx(s); return -1; } ! c = *(clp->c_cf++) & 0xff; clp->c_cc--; clcheck(clp); splx(s); *************** *** 299,305 **** if (clp->c_cc && cp++ != clp->c_cl) { if (((integer_t)cp & CROUND) == 0) cp = dtocbp(cp-1)->c_next->c_info; ! *c = *cp; return (cp); } return 0; --- 299,305 ---- if (clp->c_cc && cp++ != clp->c_cl) { if (((integer_t)cp & CROUND) == 0) cp = dtocbp(cp-1)->c_next->c_info; ! *c = *cp & 0xff; return (cp); } return 0; *************** *** 334,340 **** } else clp->c_cl -= 1; splx(s); ! return c; } /* --- 334,340 ---- } else clp->c_cl -= 1; splx(s); ! return c & 0xff; } /* *************** *** 342,348 **** */ void catq(struct clist *from, struct clist *to) { ! char c; while ((c = getc(from)) >= 0) putc(c, to); --- 342,348 ---- */ void catq(struct clist *from, struct clist *to) { ! int c; while ((c = getc(from)) >= 0) putc(c, to); *** ../../../hut/src/lites-0.8/./server/serv/tty_io.c Mon Feb 20 11:06:56 1995 --- ./server/serv/tty_io.c Tue Feb 28 06:32:33 1995 *************** *** 228,265 **** struct tty_status ttstat; mach_msg_type_number_t ttstat_count; /* * Set initial characters */ ttychars(tp); tp->t_iflag = TTYDEF_IFLAG; tp->t_oflag = TTYDEF_OFLAG; tp->t_lflag = TTYDEF_LFLAG; tp->t_cflag = CS8|CREAD; ! /* ! * Get configuration parameters from device, put in tty structure ! */ ! ttstat_count = TTY_STATUS_COUNT; ! (void) device_get_status(tp->t_device_port, ! TTY_STATUS, ! (int *)&ttstat, ! &ttstat_count); ! ! tp->t_ispeed = speed_to_baudrate( ttstat.tt_ispeed ); ! tp->t_ospeed = speed_to_baudrate( ttstat.tt_ospeed ); ! if (ttstat.tt_flags & TF_EVENP) ! tp->t_flags |= EVENP; ! if (ttstat.tt_flags & TF_ODDP) ! tp->t_flags |= ODDP; ! if (ttstat.tt_flags & TF_ECHO) ! tp->t_flags |= ECHO; ! if (ttstat.tt_flags & TF_CRMOD) ! tp->t_flags |= CRMOD; ! if (ttstat.tt_flags & XTABS) ! tp->t_flags |= XTABS; ttsetwater(tp); --- 228,253 ---- struct tty_status ttstat; mach_msg_type_number_t ttstat_count; + kern_return_t rc; /* * Set initial characters */ ttychars(tp); + tp->t_ospeed = tp->t_ispeed = TTYDEF_SPEED; tp->t_iflag = TTYDEF_IFLAG; tp->t_oflag = TTYDEF_OFLAG; tp->t_lflag = TTYDEF_LFLAG; + #if 0 + tp->t_cflag = TTYDEF_CFLAG; /* was CS8|CREAD;*/ + #else tp->t_cflag = CS8|CREAD; + #endif ! rc = tty_param(tp, &tp->t_termios); ! if (rc != D_SUCCESS) ! return(rc); ttsetwater(tp); *************** *** 605,611 **** if (!error && data_count > 0) { interrupt_enter(SPLTTY); for (i = 0; i < data_count; i++) ! (*linesw[tp->t_line].l_rint)(data[i], tp); interrupt_exit(SPLTTY); } else if (error) { printf("tty_read_reply: error = %x\n",error); --- 593,599 ---- if (!error && data_count > 0) { interrupt_enter(SPLTTY); for (i = 0; i < data_count; i++) ! (*linesw[tp->t_line].l_rint)(data[i] & 0xff, tp); interrupt_exit(SPLTTY); } else if (error) { printf("tty_read_reply: error = %x\n",error); From DALL@HFRD.DSTO.GOV.AU Thu Mar 2 19:31:15 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 3 Mar 1995 04:22:13 +0200 12:51:08 +1030 Date: Fri, 3 Mar 95 12:52:25 +1030 From: Ian Dall To: tri@pooh.tky.hut.fi, lites@cs.hut.fi, machns32k@cs.hut.fi, port-pc532@netbsd.org Subject: Lites binaries available for pc532 X-Hfrd: 1995030312504001 I have made a "binary release" of lites, mk and ancilliary programs. It is available for ftp from: augean.eleceng.adelaide.edu.au:pub/mach/pc532 Also there are source patches for mk, user, buildtools and even lites its self. The diffs may be of interest for other achitectures as well. The binary release is intended to go on top of a NetBSD release and allow you to use either. I haven't done a comparison with NetBSD on the pc532. I suspect the mk device drivers may be better than NetBSD's but for some things at least, lites is significantly slower. Whether it is slower overall in practice, depends on what you are doing! Lites is quite robust now in so far as it has been self hosting for quite a while, but there are undoubtedly still both bugs and deficiencies. I would not be surprised if NetBSD is more stable (though I don't know that) so this is probably still primarilly of interest to those who are interested in hacking operating systems. However, at least it is easy to get going relatively easilly now. Ian From kstailey@leidecker.gsfc.nasa.gov Fri Mar 3 13:55:18 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 3 Mar 1995 22:45:14 +0200 Date: Fri, 3 Mar 95 15:45:46 -0500 From: Kenneth Stailey To: lites@cs.hut.fi Subject: Lites and NetBSD 1.0A Can the Lites emulator run NetBSD 1.0A binaries? The system call gate was changed to a trap gate for purposes of efficiency. Now NetBSD 1.0A binaries will not run on a NetBSD 1.0 kernel. From braam@robson.stcatz.ox.ac.uk Sun Mar 5 11:51:54 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 5 Mar 1995 20:36:08 +0200 Date: Sun, 5 Mar 1995 18:32:16 +0100 From: "Peter J. Braam" Subject: Lites 1.0: starting/booting etc To: lites@cs.hut.fi In-Reply-To: <199502250108.AA02100@glenlivet.cs.hut.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I suppose I am not the only one with a few problems: Cross building Linux ---> i386-mach. Using UKpl8 Mach4 from Utah a) My make fell over due to an include directory that was missing: is was disk.h which was found in mach4-i386/kernel/at... Seems a minor issue, but I though I should mention it. Regarding the binary release: b) The install instructions mention mach_init? ----> where do we find mach_init ? ----> where do we find pcboot.??? ----> does that work with Mach4 c) There is the eternal confusion/discussion over partition tables: My FreeBSD partition resides in /dev/hda2 (from a Linux or DOS perspective). That PC partition itself contains a BSD type partition table and boot block. I have a Mach4 BSD bootable in /dev/hda1, which lilo sees as an image and loads; however, that Mach4 doesn't seem to see the /dev/hda2 partition, nor any partitions stored in there. ----> Can pcboot.MK ?? find a Mach4 kernel and servers directory in this situation? ----> How can I help to fix this? Thanks. Peter From kstailey@leidecker.gsfc.nasa.gov Tue Mar 7 11:37:48 1995 (5.65c8/HUTCS-S 1.4 for ); Tue, 7 Mar 1995 20:21:58 +0200 Date: Tue, 7 Mar 95 13:21:39 -0500 From: Kenneth Stailey To: lites@cs.hut.fi Subject: BusLogic BT-445C support? I don't seem to see any support for my SCSI card, the VLB BusLogic BT-445C, in either mach4 or lites 1.0. Does anyone have support for this card working with Lites? From cchen@angel.et.ntit.edu.tw Wed Mar 8 02:22:12 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 8 Mar 1995 11:09:27 +0200 Date: Wed, 8 Mar 1995 17:10:41 +0800 From: cchen@angel.et.ntit.edu.tw (Chyouhwa Chen) To: lites@cs.hut.fi Subject: building lites1.0 on freebsd2.0R I'm trying to build lites 1.0 with mach4 enabled. I'm seeing this message. Does anyone know which configuration option or other thing I didn't do right? gcc -pipe -c -MD -DKERNEL -DMACH -DLITES -Di386 -I- -I. -I/usr/src/lites-1.0\ /include -I/usr/obj/lites-1.0/include -I/usr/local/include -I/usr/src/lites-1.0\ /server -I/usr/local/include/mach -nostdinc -O2 -W /usr/src/lites-1.0/server\ /serv/bsd_server_side.c /usr/src/lites-1.0/server/serv/bsd_server_side.c: In function `bsd_write_short'\ : /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: `SYS_write' undeclared (fi\ rst use this function) /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: (Each undeclared identifie\ r is reported only once /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: for each function it appea\ rs in.) /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: warning: statement with no\ effect /usr/src/lites-1.0/server/serv/bsd_server_side.c:74: warning: statement with no\ effect and lots of others for this same file. Thanks for any help. -Chyouhwa From jvh@cs.hut.fi Sun Mar 12 11:18:03 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 20:05:22 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sun, 12 Mar 1995 20:05:16 +0200 Date: Sun, 12 Mar 1995 20:05:16 +0200 From: Johannes Helander To: "Peter J. Braam" Cc: lites@cs.hut.fi Subject: Re: Lites 1.0: starting/booting etc In-Reply-To: References: <199502250108.AA02100@glenlivet.cs.hut.fi> Organization: Helsinki University of Technology, CS Lab. Hi everybody. I'm back from France and trying to get through my mail box. Johannes Peter J. Braam writes: > > Hi, > > I suppose I am not the only one with a few problems: > Cross building Linux ---> i386-mach. > Using UKpl8 Mach4 from Utah > > > a) My make fell over due to an include directory that was missing: > is was disk.h which was found in mach4-i386/kernel/at... > > Seems a minor issue, but I though I should mention it. If you give the option --enable-mach4 to configure that problem should go away. Of course it'd be nicer not having to give so many options. > Regarding the binary release: > b) The install instructions mention mach_init? > > ----> where do we find mach_init ? > ----> where do we find pcboot.??? They are available from leia.cs.hut.fi:foggy/qwerty/bin/. A better distribution of the USER collection would be nice but someone else will have to do that. > ----> does that work with Mach4 I don't know. In general it would be nice to get rid of the boot loader problems. But this is more a kernel issue so I hope someone else will solve it. > c) There is the eternal confusion/discussion over partition tables: Yes. Lites currently reads the partition table from the kernel and does nothing itself to try to solve (or further complicate) the partitioning questions. > My FreeBSD partition resides in /dev/hda2 (from a Linux or DOS > perspective). That PC partition itself contains a BSD type partition table > and boot block. > > I have a Mach4 BSD bootable in /dev/hda1, which lilo sees as an image and > loads; however, that Mach4 doesn't seem to see the /dev/hda2 partition, > nor any partitions stored in there. > > ----> Can pcboot.MK ?? find a Mach4 kernel and servers directory in this > situation? I have no idea. You just have to try. > ----> How can I help to fix this? > Thanks. > > Peter > From jvh@cs.hut.fi Sun Mar 12 11:22:39 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 20:14:06 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sun, 12 Mar 1995 20:12:47 +0200 Date: Sun, 12 Mar 1995 20:12:47 +0200 From: Johannes Helander To: cchen@angel.et.ntit.edu.tw (Chyouhwa Chen) Cc: lites@cs.hut.fi Subject: Re: building lites1.0 on freebsd2.0R In-Reply-To: <199503080910.RAA17832@angel.et.ntit.edu.tw> References: <199503080910.RAA17832@angel.et.ntit.edu.tw> Organization: Helsinki University of Technology, CS Lab. Chyouhwa Chen writes: > > I'm trying to build lites 1.0 with mach4 enabled. I'm > seeing this message. Does anyone know which configuration > option or other thing I didn't do right? I don't know what configuration options you gave but it looks like something is going wrong with syscall.h. Try looking in the dependency file (*.d depend) in the object directory where syscall.h came from and why it was not properly generated. I don't know why /usr/local/include is in the path. It seems that comes from configure. Does anyone know how to get rid of it? Hm, giving an --prefix=somenicedirectory might do that. But of course if you installed the Mach headers in /usr/local/include then it is ok. Johannes > gcc -pipe -c -MD -DKERNEL -DMACH -DLITES -Di386 -I- -I. -I/usr/src/lites-1.0\ > /include -I/usr/obj/lites-1.0/include -I/usr/local/include -I/usr/src/lites-1.0\ > /server -I/usr/local/include/mach -nostdinc -O2 -W /usr/src/lites-1.0/server\ > /serv/bsd_server_side.c > /usr/src/lites-1.0/server/serv/bsd_server_side.c: In function `bsd_write_short'\ > : > /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: `SYS_write' undeclared (fi\ > rst use this function) > /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: (Each undeclared identifie\ > r is reported only once > /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: for each function it appea\ > rs in.) > /usr/src/lites-1.0/server/serv/bsd_server_side.c:67: warning: statement with no\ > effect > /usr/src/lites-1.0/server/serv/bsd_server_side.c:74: warning: statement with no\ > effect > > > and lots of others for this same file. > > Thanks for any help. > > -Chyouhwa > From jvh@cs.hut.fi Sun Mar 12 11:34:59 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 20:26:05 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sun, 12 Mar 1995 20:25:59 +0200 Date: Sun, 12 Mar 1995 20:25:59 +0200 From: Johannes Helander To: Bill Collins Cc: lites@cs.hut.fi Subject: Re: NFS failure In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. Does NFS to AIX work with FreeBSD or NetBSD? In that case it would most likely help to integrate the NFS fixes from those into Lites. It would be a good thing to do in any case as it would most likely fix some problems at least. NFS served by Alphas didn't work with either Lites or NetBSD last time someone here tried it. Johannes Bill Collins writes: > > I am running MK83i/Lites0.8. When I try to mount an NFS partition served > by an AIX host, I get the following: > > progname: bad net address aroch > > with the following fstab entry: > > aroch:/nfs/u18 /nfs/u18 nfs rw 0 0 > > Any ideas? > > Bill > > Internet: collins@unm.edu > Phone(wk): (505) 277-8090 > > From jvh@cs.hut.fi Sun Mar 12 12:00:39 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 20:56:01 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sun, 12 Mar 1995 20:55:51 +0200 Date: Sun, 12 Mar 1995 20:55:51 +0200 From: Johannes Helander To: Kenneth Stailey Cc: lites@cs.hut.fi Subject: Re: Lites and NetBSD 1.0A In-Reply-To: <9503032045.AA08928@leidecker.gsfc.nasa.gov> References: <9503032045.AA08928@leidecker.gsfc.nasa.gov> Organization: Helsinki University of Technology, CS Lab. Kenneth Stailey writes: > Can the Lites emulator run NetBSD 1.0A binaries? I haven't tried but probably not just like that. I presume the change affects only the i386 platform? > The system call gate was changed to a trap gate for purposes of > efficiency. Now NetBSD 1.0A binaries will not run on a NetBSD 1.0 > kernel. I guess the change will just make the binaries substantially slower. Is the interface like that in Linux (int 0x80) or do we get more random interfaces? It might be a good idea to implement the trap forwarding in the Mach kernel as is done for call gates. One disadvantage with the trap compared to call gates is that a CALL instruction doesn't fit into the trap but it does into the call gate (call gates 6 bytes, subroutine calls 5 bytes, and traps 2 bytes). A little NOP padding would be nice. Or even (much!) better getting the library to do subroutine calls voluntarily when run on a Lites platform. Johannes From hasty@netcom.com Sun Mar 12 14:04:51 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 22:59:28 +0200 id MAA26942; Sun, 12 Mar 1995 12:58:29 -0800 Date: Sun, 12 Mar 1995 12:58:29 -0800 From: hasty@netcom.com (Amancio Hasty Jr) To: lites@cs.hut.fi Subject: mdos? Has anyone ported or started to port mdos? I am using Mach4/Lites-1.0/FreeBSD-2.x :) Also, I would like to know if anyone has implemented the linux iopl system call (I really would like to run sdoom :) ) ? Last but not least has anyone gotten X to run with Lites? Tnks, Amancio From tri@pooh.tky.hut.fi Sun Mar 12 14:43:30 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 12 Mar 1995 23:36:42 +0200 Date: Sun, 12 Mar 1995 23:36:38 +0200 From: "Timo J. Rinne" To: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: mdos? In-Reply-To: <199503122058.MAA26942@netcom14.netcom.com> References: <199503122058.MAA26942@netcom14.netcom.com> Reply-To: Timo.Rinne@hut.fi Cc: lites@cs.hut.fi Organization: Helsinki University of Technology Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit You wrote: > Has anyone ported or started to port mdos? Dosemu for Linux is based on mdos and is far more complete than mdos. I think that it would be a best choice if one likes to port it for Lites. The main problem in {Net,Free}BSD port is that they don't support virtual-86 mode. Linux and Mach do. I've looked into Dosemu a bit but haven't really had time to do anything to it. > Also, I would like to know if anyone has implemented the linux iopl > system call (I really would like to run sdoom :) ) ? Nope, but that's not very difficult. > Last but not least has anyone gotten X to run with Lites? We have run the Mach binaries. At least they used to work a-ok. X-version of Linux doom works, but is quite slow. -- Timo J. Rinne, E-mail: Timo.Rinne@hut.fi or tri@cirion.fi WWW : http://www.cs.hut.fi/~tri/ Hi! I am a .signature virus. Copy me into your .signature to join in! *** PGP 2.3 public key available *** From hasty@netcom.com Sun Mar 12 15:29:36 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Mar 1995 00:21:07 +0200 id OAA06410; Sun, 12 Mar 1995 14:20:03 -0800 Date: Sun, 12 Mar 1995 14:20:03 -0800 From: hasty@netcom.com (Amancio Hasty Jr) To: Timo.Rinne@hut.fi, hasty@netcom.com Subject: Re: mdos? Cc: lites@cs.hut.fi >support virtual-86 mode. Linux and Mach do. Well, NetBSD does now support virtual-86 mode as well as linux binaries. As for virtual-86 NetBSD just got support for virtual-86 mode and I have the code so I am going to port it to FreeBSD. Tnks, Amancio From tri@pooh.tky.hut.fi Sun Mar 12 15:49:26 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Mar 1995 00:40:49 +0200 Date: Mon, 13 Mar 1995 00:40:46 +0200 From: "Timo J. Rinne" To: hasty@netcom.com (Amancio Hasty Jr) Cc: lites@cs.hut.fi Subject: Re: mdos? In-Reply-To: <199503122220.OAA06410@netcom14.netcom.com> References: <199503122220.OAA06410@netcom14.netcom.com> Reply-To: Timo.Rinne@hut.fi Organization: Helsinki University of Technology Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit You wrote: > Well, NetBSD does now support virtual-86 mode as well as linux binaries. > As for virtual-86 NetBSD just got support for virtual-86 mode and I have > the code so I am going to port it to FreeBSD. Well you do that. After that Dosemu port should be a piece of cake. -- Timo J. Rinne, E-mail: Timo.Rinne@hut.fi or tri@cirion.fi WWW : http://www.cs.hut.fi/~tri/ Hi! I am a .signature virus. Copy me into your .signature to join in! *** PGP 2.3 public key available *** From kstailey@leidecker.gsfc.nasa.gov Sun Mar 12 16:16:12 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Mar 1995 01:11:30 +0200 Date: Sun, 12 Mar 95 18:11:07 -0500 From: Kenneth Stailey To: Timo.Rinne@hut.fi Cc: hasty@netcom.com, lites@cs.hut.fi In-Reply-To: <199503122136.XAA00340@pooh.tky.hut.fi> (tri@pooh.tky.hut.fi) Subject: Re: mdos? > The main problem in {Net,Free}BSD port is that they don't support > virtual-86 mode. Linux and Mach do. I don't think that's still true for NetBSD. From collins@unm.edu Mon Mar 13 10:11:57 1995 (5.65c8/HUTCS-S 1.4 for ); Mon, 13 Mar 1995 19:02:53 +0200 (Smail3.1.28.1 #10) id m0roDW4-0000PYC; Mon, 13 Mar 95 10:02 MST Date: Mon, 13 Mar 1995 10:02:48 -0700 (MST) From: Bill Collins To: lites@cs.hut.fi Subject: Re: NFS failure In-Reply-To: <199503121825.AA04758@glenlivet.cs.hut.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 12 Mar 1995, Johannes Helander wrote: > Does NFS to AIX work with FreeBSD or NetBSD? In that case it would > most likely help to integrate the NFS fixes from those into Lites. It > would be a good thing to do in any case as it would most likely fix > some problems at least. When I bring the same host up using FreeBSD, I have no problem. The problem occurs between lites and AIX, so it would appear. (I don't have a huge base to test NFS mounts with.) Sorry I don't have more *meaningful* problem description. Time permitting, etc. > > NFS served by Alphas didn't work with either Lites or NetBSD last time > someone here tried it. > Same error message? Bill Internet: collins@unm.edu Phone(wk): (505) 277-8090 From jvh@cs.hut.fi Wed Mar 15 18:59:14 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 16 Mar 1995 03:50:09 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 16 Mar 1995 03:50:08 +0200 Date: Thu, 16 Mar 1995 03:50:08 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: A new Lites snapshot (lites-1.0.950316) Organization: Helsinki University of Technology, CS Lab. I've made a new Lites snapshot available as leia.cs.hut.fi:foggy/qwerty/lites-1.0.950316.tar.gz I plan to release a Lites 1.1 version in a few days and this snapshot is supposedly close to that. I know it is not long ago since the 1.0 release but there are lots of changes and I won't have time to do much in a while after about right now. The snapshot has been quickly tested on the i386 and alpha. More testing is most welcome. Bugfixes and other changes are welcome too as long as I don't have to spend much time on them. Note that the emulator - server interface is incompatible with earlier versions and thus the emulator must be upgraded together with the server. Johannes From hasty@netcom.com Wed Mar 15 21:21:11 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 16 Mar 1995 06:13:27 +0200 id TAA03267; Wed, 15 Mar 1995 19:57:38 -0800 Date: Wed, 15 Mar 1995 19:57:38 -0800 From: hasty@netcom.com (Amancio Hasty Jr) To: jvh@cs.hut.fi, lites@cs.hut.fi Subject: Re: A new Lites snapshot (lites-1.0.950316) Hi, I tried downloading the latest snapshot and this is that I got: lites-1.0.950316/server/netiso/xebec/test.trans lites-1.0.950316/server/netiso/xebec/test/ lites-1.0.950316/server/netiso/xebec/xebec.bnf gzip: lites-1.0.950316/server/netns/ lites-1.0.950316/server/netns/idp.h lites-1.0.950316/server/netns/spp_var.h stdin: unexpected end of file gtar: Unexpected EOF on archive file Tnks, Amancio From jvh@cs.hut.fi Thu Mar 16 06:32:10 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 16 Mar 1995 15:16:58 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 16 Mar 1995 15:16:27 +0200 Date: Thu, 16 Mar 1995 15:16:27 +0200 From: Johannes Helander To: hasty@netcom.com (Amancio Hasty Jr) Cc: lites@cs.hut.fi Subject: Re: A new Lites snapshot (lites-1.0.950316) In-Reply-To: <199503160357.TAA03267@netcom14.netcom.com> References: <199503160357.TAA03267@netcom14.netcom.com> Organization: Helsinki University of Technology, CS Lab. > I tried downloading the latest snapshot and this is that I got: > > stdin: unexpected end of file > gtar: Unexpected EOF on archive file Sorry about that. I copied the file to the ftp area again. Now the size is 1.8 MB as before. Johannes From idall@eleceng.adelaide.edu.au Sat Mar 18 00:52:17 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 18 Mar 1995 09:36:38 +0200 Date: Sat, 18 Mar 1995 18:06:25 +1030 From: idall@eleceng.adelaide.edu.au (Ian Dall) To: lites@cs.hut.fi, jvh@cs.hut.fi Subject: Lites 950316 hangs unexpectedly The 950316 snapshot hangs for me at indeterminate points. This happens sufficiently often that with several tries I couldn't configure and build a lites. The server becomes completely unresponsive at the hang and I have to reboot. I don't know whether there where any MD changes I need to incorporate. I notice there were quite a lot of i386 changes, but I assume they are mostly to support the new way of doing system calls. (And hence would be irrelevant to the pc532). Ian From jvh@cs.hut.fi Sat Mar 18 14:52:07 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 18 Mar 1995 23:44:28 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sat, 18 Mar 1995 23:43:53 +0200 Date: Sat, 18 Mar 1995 23:43:53 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Re: Patches against 950316 snapshot In-Reply-To: <9503180514.AA03027@augean.eleceng.adelaide.edu.au> References: <9503180514.AA03027@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. > I merged in my changes and tried the 950316 snapshot. One Thanks. And sorry I didn't explain the changes at all before. The basic changes were: - support for the OSF Mach kernel. This is preliminary. I'll summarize the situation in the 1.1 announcement. - Cleanup of the interface. There were unused parameters passed in the RPCs and as the interface became incompatible anyways I used the opportunity to clean it up. - Slight improvement in alpha support (ioctl seems like the next thing to do. Anyone interested?) The OSF support is currently i386 only so most changes were there. One troublesome thing was the emul_generic interface that used a mixture of out of line and inline memory. The way we did it was to support inline memory only. The main interface using bigger transfers was read. The old read code was difficult to understandf and to change so I wrote a simple code using the (new) bsd_read_short and bsd_read_long interfaces. The old code did in some cases use a shared memory buffer to transfer data. The new code doesn't ever do it. To make the performance drop less significant I increased the maximum inline size to 8 kB from 4 kB. I didn't actually measure the effect of the size change (you can make it smaller simply by changing bsd_types_gen.sym SMALL_ARRAY_LIMIT (I'm not looking at the code so the names might be wrong)). Re-enabling the mapped memory window should be beneficial. It would be best to do it in such a way that both read and socket receives can use the same interface. e_readwrite and emul_mapped contain CMU code that does these kiinds of things but the code is currently not in use. So I figured it is better to first write a simple code that works in all cases and then extend it with optimizations. I just didn't have time to do the optimizations. An even better solution than mapping a static window (separating data transfer from IPC) would be to map the files directly (or parts of files). This would require the ability to get and push back file state (including attributes). This way no RPC would be needed unless there are several users of a file, syncing is needed, or the file window needs to be changed. Plus the overhead of moving file descriptor state around in forks etc. > curiosity: IO appears to have *slowed*. A simple dd if=/dev/rsd0a > of=/dev/null bs=32k has gome from about 1.2 MB/s to about .8MB/s. > Any idea why that would be? There is a much smaller, but measurable > slow down in the speed of fsck. > First, there is a trivial diff for tty_status in the mk distribution. > It gets rid of the old style definitions of B0 -- B38400 which clash > with the new style definitions in termios.h. I notice that termios.h > now has B0 -- B38400 defined if it is OSFMACH3. Really, I think these > new definitions should really be defined always. Anything which > includes termios.h is going to get a surprise if attemting to set a > baud rate of 9600 results in a baud rate of 13! There is very little > in MK, and nothing in lites, which needs the old definition. Most > places use conversion tables rather than symbolic definitions of these > Bnnn. The only problem is a name clash between tty_status.h and termios.h > which can best be handled by not making the tty_status.h definitions > if LITES is defined. So what you are saying is that Lites will still work with old kernels? If so the change should of course be done. If it requires changing the kernels I'm more hesitant. Oh yes, and another change I did was that I added some more spl stuff in the exit code. This was because I suspect there is some kind of race condition that sometimes results in wait4 not returning ECHILD even if there are no children, thus hanging indefinitely and sometimes resulting in chproccnt failing. It seems the proc_died and wait4 codes are not well enough serialized or something like that. I tried to fix this a little but didn't get any improvement. It happens seldom enough that it is hard to repeat deterministically. Johannes From jvh@cs.hut.fi Sat Mar 18 14:58:08 1995 (5.65c8/HUTCS-S 1.4 for ); Sat, 18 Mar 1995 23:51:44 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Sat, 18 Mar 1995 23:51:31 +0200 Date: Sat, 18 Mar 1995 23:51:31 +0200 From: Johannes Helander To: idall@eleceng.adelaide.edu.au (Ian Dall) Cc: lites@cs.hut.fi Subject: Re: Lites 950316 hangs unexpectedly In-Reply-To: <9503180736.AA05645@augean.eleceng.adelaide.edu.au> References: <9503180736.AA05645@augean.eleceng.adelaide.edu.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > The 950316 snapshot hangs for me at indeterminate points. > This happens sufficiently often that with several tries > I couldn't configure and build a lites. The server becomes > completely unresponsive at the hang and I have to reboot. I might have caused a deadlock in the wait4/proc_died changes. I haven't seen them though. The best way to see what is happening is to use gdb with the lock printing code and get the problem happening while running under gdb. You could also try undoing those changes (not very convenient I admit). > I don't know whether there where any MD changes I need to > incorporate. I notice there were quite a lot of i386 changes, but I > assume they are mostly to support the new way of doing system calls. > (And hence would be irrelevant to the pc532). There isn't support for the new NetBSD way of doing things on the i386. It should be similar to the Linux thing though and not too hard. Might be best to make the kernel syscall trampoline code recognize the Linux/NetBSD trap and do the same thing as for call gates. But the OSF MK changes are there yes. I tried to make the interface changes that affect all architectures to all architectures. However, it is not impossible I missed something. As I said before, only Aplha and i386 were tested. Johannes From mitchem@sctc.com Wed Mar 22 10:35:12 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 22 Mar 1995 19:01:32 +0200 22 Mar 95 10:56 CST 22 Mar 95 10:55 CST X-Authentication-Warning: t-bone.sctc.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.1 12/2/94 To: lites@cs.hut.fi Subject: Lites instead of UX? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Mar 1995 10:55:38 -0600 From: Terrence Mitchem Can Lites be used as a replacement for UX? I have been running it and MK83a in a NetBSD environment with no trouble but I have yet to get it to go on a regular Mach machine. It keeps reporting that mach_init died and then panics. I have been able to determine that the mach_init task starts and then forks itself so I know that two tasks after Lites are getting started. Unfortunately, that's all I've been able to figure out. Does anyone have any suggestions? Any and all help is appreciated. thanks, tjm From jvh@cs.hut.fi Wed Mar 22 11:08:31 1995 (5.65c8/HUTCS-S 1.4 for ); Wed, 22 Mar 1995 20:02:29 +0200 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Wed, 22 Mar 1995 20:02:08 +0200 Date: Wed, 22 Mar 1995 20:02:08 +0200 From: Johannes Helander To: Terrence Mitchem Cc: lites@cs.hut.fi Subject: Re: Lites instead of UX? In-Reply-To: <199503221655.KAA09850@t-bone.sctc.com> References: <199503221655.KAA09850@t-bone.sctc.com> Organization: Helsinki University of Technology, CS Lab. Terrence Mitchem writes: > Can Lites be used as a replacement for UX? I have been running it and MK83a Most UX binaries should work. There are some incompatibilities, however. The following come to mind: - device numbers - mount (the system call arguments are not translated, could be done) - route (the routing protocol has changed) - mount_nfs, mount_kernfs > in a NetBSD environment with no trouble but I have yet to get it to go on a > regular Mach machine. It keeps reporting that mach_init died and then panics. Some of the paths are different too. mach_init should first be searching for /sbin/init and then for /etc/init. > I have been able to determine that the mach_init task starts and then forks > itself so I know that two tasks after Lites are getting started. Perhaps the problem is the device numbering? There might be more problems too but this might help you get further. Johannes From jvh@cs.hut.fi Wed Mar 22 17:52:49 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 23 Mar 1995 01:24:16 +0200 (5.65c8/HUTCS-C 1.3 for lites); Thu, 23 Mar 1995 01:24:15 +0200 Date: Thu, 23 Mar 1995 01:24:15 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: New snapshot available (final before 1.1) Organization: Helsinki University of Technology, CS Lab. Lites-1.0.950323.tar.gz is available from leia.cs.hut.fi:foggy/qwerty/ It is slightly smaller because there isn't a TAGS file this time (there will be one in the release). The hanging problem has been fixed. It was really a simple bug and not a race condition or anything like that. The problem was that for shutdown I had added a test that would avoid panicing when init is finally killed. The test wasn't selective enough and inhibited normal process termination in some cases. There is still a problem with chgproccnt in case of some combination of programs playing around with user ids such as Xterm combined with reboot. Maybe I should just change the warning_panic into a printf :-). I have integrated all patches that have been sent to me as well as my own fixes. This is the final snapshot after a Lites 1.1 release. If something serious comes up either the release will be delayed or it will have to be fixed later. If necessary, I can make small fixes tomorrow. Johannes From lites-readers-request Thu Mar 23 13:53:22 1995 id NAA04358; Thu, 23 Mar 1995 13:53:18 -0700 (5.65c8/HUTCS-S 1.4 for ); Thu, 23 Mar 1995 20:17:30 +0200 23 Mar 95 12:17 CST 23 Mar 95 12:17 CST X-Authentication-Warning: t-bone.sctc.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.1 12/2/94 To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: Lites instead of UX? In-Reply-To: Your message of "Thu, 23 Mar 1995 09:54:58 CST." <199503231555.JAA11661@t-bone.sctc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 12:17:00 -0600 From: Terrence Mitchem Johannes Helander writes: > Most UX binaries should work. There are some incompatibilities, > however. The following come to mind: > - device numbers > - mount (the system call arguments are not translated, could be done) > - route (the routing protocol has changed) > - mount_nfs, mount_kernfs > > Some of the paths are different too. mach_init should first be > searching for /sbin/init and then for /etc/init. > > > Perhaps the problem is the device numbering? > > There might be more problems too but this might help you get further. > > Johannes Here is what I found with a little experimentation: After /mach_servers/mach_init forks itself, the parent fails the execve("/etc/init") call. When I traced the call into the emulator, I found that e_execve() calls e_access() and it's the e_access() call that eventually receives the error code c002 (fs_no_entry or something like that) from the server. Is this a case of Lites not being able to deal with the Mach 4.3 filesystem? I would definitely be willing to work on this if someone can start me off in the right direction. thanks, tjm From lites-readers-request Thu Mar 23 15:08:08 1995 id PAA27325; Thu, 23 Mar 1995 15:08:05 -0700 (5.65c8/HUTCS-S 1.4 for ); Thu, 23 Mar 1995 22:34:06 +0200 23 Mar 95 14:33 CST 23 Mar 95 14:33 CST X-Authentication-Warning: t-bone.sctc.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.1 12/2/94 To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Mar 1995 14:33:14 -0600 From: Terrence Mitchem Johannes Helander writes: > Most UX binaries should work. There are some incompatibilities, > however. The following come to mind: > - device numbers > - mount (the system call arguments are not translated, could be done) > - route (the routing protocol has changed) > - mount_nfs, mount_kernfs > > Some of the paths are different too. mach_init should first be > searching for /sbin/init and then for /etc/init. > > > Perhaps the problem is the device numbering? > > There might be more problems too but this might help you get further. > > Johannes Here is what I found with a little experimentation: After /mach_servers/mach_init forks itself, the parent fails the execve("/etc/init") call. When I traced the call into the emulator, I found that e_execve() calls e_access() and it's the e_access() call that eventually receives the error code c002 (fs_no_entry or something like that) from the server. Is this a case of Lites not being able to deal with the Mach 4.3 filesystem? I would definitely be willing to work on this if someone can start me off in the right direction. thanks, tjm From lites-readers-request Thu Mar 23 16:09:07 1995 id QAA02301; Thu, 23 Mar 1995 16:09:04 -0700 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Mar 1995 00:57:56 +0200 (5.65c+/10jsm) id AA00842; Thu, 23 Mar 1995 17:57:31 -0500 Date: Thu, 23 Mar 1995 17:57:30 -0500 (EST) From: Terrence Mitchem Subject: Re: Lites instead of UX? To: jvh@cs.hut.fi Cc: lites@cs.hut.fi Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Johannes Helander writes: > Most UX binaries should work. There are some incompatibilities, > however. The following come to mind: > - device numbers > - mount (the system call arguments are not translated, could be done) > - route (the routing protocol has changed) > - mount_nfs, mount_kernfs > > Some of the paths are different too. mach_init should first be > searching for /sbin/init and then for /etc/init. > > > Perhaps the problem is the device numbering? > > There might be more problems too but this might help you get further. > > Johannes Here is what I found with a little experimentation: After /mach_servers/mach_init forks itself, the parent fails the execve("/etc/init") call. When I traced the call into the emulator, I found that e_execve() calls e_access() and it's the e_access() call that eventually receives the error code c002 (fs_no_entry or something like that) from the server. Is this a case of Lites not being able to deal with the Mach 4.3 filesystem? I would definitely be willing to work on this if someone can start me off in the right direction. thanks, tjm From jvh@cs.hut.fi Fri Mar 24 10:02:13 1995 id IAA00690; Fri, 24 Mar 1995 08:26:54 -0700 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Mar 1995 17:06:21 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 24 Mar 1995 17:02:36 +0200 Date: Fri, 24 Mar 1995 17:02:36 +0200 From: Johannes Helander To: lites@cs.hut.fi, mach3@cs.cmu.edu, mach4-users@cs.utah.edu, osf1-mk@gr.osf.org Reply-To: jvh@cs.hut.fi Subject: Lites 1.1 available Organization: Helsinki University of Technology, CS Lab. Lites 1.1 is now available. Compared to the Lites 1.0 release, this release provides preliminary support for the OSF Microkernel, fixes a number of bugs, and includes a read only Minix file system. The OSF support is expected to work with the next version of the OSF kernel (due in April). The OSF/1 MK support was done by Johannes Helander and Jukka Virtanen with expertise provided by OSF Research Institute staff in Grenoble, in particular Francois Barbou des Places. The Minix file system was written by Csizmazia Balazs. Ian Dall provided fixes to make 8 bit TTY i/o work properly. Remy Card wrote up to date instructions on how to build and install Lites on a FreeBSD 2.0 machine (see doc/lites-on-freebsd). The emulator server interface has been cleaned up and is incompatible with earlier interfaces. This means that the Lites emulator needs to be upgraded together with the Lites server. Refer to doc/emulator-upgrading for details. Lites is available from the following locations: Europe: ftp://ftp.funet.fi/pub/mach/lites/ USA: ftp://mach.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/src/lites/ The Lites 1.0 announcement is included below for reference. ------------------------------------------------------------------ Lites 1.0 is now available. The primary purpose of this release is to make the source available to interested parties. No installation kit is included. Lites is a 4.4 BSD Lite based server and an emulation library that provide free unix functionality to a Mach based system. Lites provides binary compatibility with 4.4 BSD, NetBSD (0.8, 0.9, and 1.0), FreeBSD (1.1.5 and 2.0), 386BSD, UX (4.3BSD) and Linux on the i386 platform. It has also been ported to the pc532, PA-RISC, and preliminarily to the R3000 and Alpha. Lites works with Mach 3.0, Mach 4, and RTMach. The recommended user platforms are NetBSD 1.0 and FreeBSD 2.0. Linux file system support is not included in this release. Lites was written by Johannes Helander at Helsinki University of Technology based on 4.4 BSD Lite from University of California and code written by the CMU Mach group. Several people have contributed to the effort, including Ian Dall, Mike Hibler, Jeff Law, Bryan Ford, Jukka Virtanen, Mary Thompson, Sampo Kellomaki, John Dyson, Csizmazia Balazs, Chris Maeda, and Timo Rinne. Special care has been put into keeping the code legally clean. Each piece of code that has been added to Lites has been carefully examined. There is no Net2 or 4.3 BSD code in Lites. Lites consists of a multithreaded single server that handles multiple system calls from any process, file paging, etc. and an emulation library that provides applications with an environment that looks like the system the application expects. The emulator is a completely new implementation and removes most of the security problems associated with earlier emulators (protection against resource attacks requires kernel support). Lites has been self hosting for several months. Its current performance is 6% lower than that of NetBSD 1.0 as measured by building gcc within the exact same machine and environment. Many obvious optimizations especially in the field of i/o have not yet been made. Lites is available from the following locations: Europe: ftp://ftp.funet.fi/pub/mach/lites/ USA: ftp://mach.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/src/lites/ For more information refer to the Lites home page http://www.cs.hut.fi/lites.html I have also made my Master's thesis available in postscript form under the same URL. It covers some aspects of Lites. Johannes ------------------------------------------------------------------ From lites-readers-request Fri Mar 24 16:07:04 1995 id QAA02328; Fri, 24 Mar 1995 16:07:01 -0700 (5.65c8/HUTCS-S 1.4 for ); Fri, 24 Mar 1995 16:27:11 +0200 (5.65c8/HUTCS-C 1.3 for lites); Fri, 24 Mar 1995 16:27:10 +0200 Date: Fri, 24 Mar 1995 16:27:10 +0200 From: Johannes Helander To: lites@cs.hut.fi Subject: chgproccnt Organization: Helsinki University of Technology, CS Lab. Thanks to Jukka Partanen who fixed the chgproccnt bug. Forks in setuid programs used the wrong uid in chgproccnt. Small bug big irritation. Johannes From lites-readers-request Mon Apr 3 21:27:13 1995 id VAA23893; Mon, 3 Apr 1995 21:27:11 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Apr 1995 06:16:41 +0300 Date: Mon, 3 Apr 1995 23:09:39 -0400 From: "William S. Morgart" To: jvh@cs.hut.fi Subject: File Size Strangeness Cc: lites@cs.hut.fi Reply-To: wsm@morticia.ssw.com System Particulars ------------------ 486 dx2/66 with 16mb ram and 420mb + 340mb ide disk drives Lites 1.1 and mach-4 NetBSD 1.0 base system Problem ------- I've found that file writes can produce files that have a peculiar file size (-1 or 4294967295) but the block count for the file appears to be correct for the actual data in the file plus the number of all indirect blocks. This behavior occurs with the lpr command, ie. cf and df files are both of -1 size, emacs on a write file but not on a save file, tar on an extract, and the ld command. An example of this is: Before emacs write file is used - 2 -rw-r--r-- 1 wsm wheel 68 Apr 3 18:04 lites-write-test.3.~1~ And After emacs write file is used - 64 -rw-r--r-- 1 wsm wheel 4294967295 Apr 3 18:04 lites-write-test.3 Question -------- Since others are using Lites to build and debug Lites I'm wondering if anyone else has seen this behavior and if so they have a thought as to what may be happening. >From the behavior I'm seeing I think there may be some incompatability between the NetBSD 1.0 (at least for the 386) libraries and utilities and Lites/Mach when file writes occur. Any Thoughts or Comments, Bill Morgart wsm@morticia.ssw.com From lites-readers-request Tue Apr 4 11:53:27 1995 id LAA05740; Tue, 4 Apr 1995 11:53:26 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Apr 1995 20:31:39 +0300 id LAA05215; Tue, 4 Apr 1995 11:31:16 -0600 id LAA05418; Tue, 4 Apr 1995 11:31:14 -0600 Date: Tue, 4 Apr 1995 11:31:14 -0600 From: mike@cs.utah.edu (Mike Hibler) To: wsm@morticia.ssw.com Subject: Re: File Size Strangeness Cc: lites@cs.hut.fi My knee-jerk reaction (though I have not seen this particular problem before) is that it is a compatibility problem between the old 32-bit off_t and the new 64-bit off_t. In particular, lseek() might be returning a 32-bit -1 to indicate an error but the new application code is looking at the return as 64-bit, the top-half which might be 0 thus not appearing as an error. If that "-1" is then used as an offset in a truncate call (or another lseek followed by a write?) you could wind up with a file as you see (truncate, when growing a file, only allocates the last block leaving a "hole" for all the intermediate space). Of course, there is an inconsistency here in that truncate would have to be treating the offset as 64-bits to get a file like that where the earlier assumption was that lseek was treating it as 32-bits. But my best guess is still that you are feeding a 32-bit error code (-1) to a 64-bit truncate. From lites-readers-request Tue Apr 4 23:41:22 1995 id XAA20312; Tue, 4 Apr 1995 23:41:15 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 5 Apr 1995 08:30:50 +0300 From: hyh82@cs.ccu.edu.tw (Han Yi-Huang) Subject: Can't compile Lites 1.x on FreeBSD !! To: lites@cs.hut.fi Date: Wed, 5 Apr 1995 11:20:50 +0800 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2724 Dear Sir: I install FreeBSD 2.0-950322-SNAP on my machine(AMD 486 DX2-80). Everything is OK. I want to run mach on the machine. I can compile Mach4 correctly!! When I compile lites, I got stuck!! Here are error messages. gmake[1]: Entering directory `/usr/obj/lites-1.0/server' /bin/sh /usr/src/lites-1.0/conf/newvers.sh /usr/src/lites-1.0/conf/copyright Lit es Lites.0.8 STD+WS+mach4 gcc -pipe -c -MD -DKERNEL -DMACH -DLITES -Di386 -I- -I. -I/usr/src/lites-1.0/ include -I/usr/obj/lites-1.0/include -I/usr/local/include -I/usr/src/lites-1.0/s erver -I/usr/local/include/mach -nostdinc -O2 -W vers.c ld -o startup.Lites.0.8.STD+WS+mach4.unstripped.out -e __start -L/usr/obj/lites -1.0/liblites -L/usr/local/lib \ /usr/local/lib/mach_crt0.o vers.o ... _traps.o -llites -lthreads -lmach_sa /usr/lib/libgcc.a && \ mv startup.Lites.0.8.STD+WS+mach4.unstripped.out startup.Lites.0.8.STD+WS+mach4. unstripped kernfs_vnops.o: Undefined symbol `___divdi3' referenced from text segment nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment nfs_nqlease.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment spec_vnops.o: Undefined symbol `___divdi3' referenced from text segment spec_vnops.o: Undefined symbol `___moddi3' referenced from text segment spec_vnops.o: Undefined symbol `___divdi3' referenced from text segment spec_vnops.o: Undefined symbol `___moddi3' referenced from text segment ufs_lookup.o: More undefined symbol ___udivdi3 refs follow gmake[1]: *** [startup.Lites.0.8.STD+WS+mach4.unstripped] Error 1 gmake[1]: Leaving directory `/usr/obj/lites-1.0/server' gmake: *** [all] Error 1 ====end of error messages Can anyone solve this problem for me? Many thanks!! ======================================================================= Yi-Huang Han Dept. of Computer Science & Information Engineering National Chung Cheng Univ. Chiayi 621, Taiwan, R.O.C. e-mail: hyh82@cs.ccu.edu.tw eddy@hntp2.hinet.net From lites-readers-request Wed Apr 5 19:11:06 1995 id TAA09165; Wed, 5 Apr 1995 19:11:05 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 6 Apr 1995 03:55:15 +0300 10:24:08 +1030 Date: Thu, 6 Apr 95 10:24:31 +1030 From: Ian Dall To: mach3@cs.cmu.edu, lites@cs.hut.fi Subject: Null dereference in vm_map_copyin causes deadlock X-Hfrd: 1995040610234342 I was chasing the cause of the lites server occasionally hanging, and the problem turned out to be in MK. Basically, vm_map_copyin takes out a lock on a map, then there is a page fault when the null pointer gets dereferenced. The pagefault causes a vm_map_lookup which attempts to lock the same map. The effects of this may vary slightly from architecture to architecture if the MD trap handler does something different, but the null pointer dereference is surely a bug always. This is for mk83a, so it is possible it has been fixed. A patch follows although I am a bit unsure if it is correct since I can't guess why the original test was so convoluted. Ian *** ../../../cmu/src/mk/kernel/vm/vm_map.c Sat Aug 20 01:42:09 1994 --- kernel/vm/vm_map.c Thu Apr 6 01:42:39 1995 *************** *** 3696,3704 **** * Attempt non-blocking copy-on-write optimizations. */ ! if (src_destroy && ! (src_object == VM_OBJECT_NULL || src_object->temporary) && ! !src_object->use_shared_copy) { /* * If we are destroying the source, and the object --- 3696,3703 ---- * Attempt non-blocking copy-on-write optimizations. */ ! if (src_destroy && src_object != VM_OBJECT_NULL && ! src_object->temporary && !src_object->use_shared_copy) { /* * If we are destroying the source, and the object From lites-readers-request Wed Apr 5 22:40:33 1995 id WAA12370; Wed, 5 Apr 1995 22:40:32 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 6 Apr 1995 07:25:15 +0300 From: David Black Date: Thu, 6 Apr 95 00:21:12 -0400 To: dall@hfrd.dsto.gov.au, lites@cs.hut.fi, mach3@cs.cmu.edu Subject: Re: Null dereference in vm_map_copyin causes deadlock Looks to me as if the original test is parenthesized wrong. Correct parenthesization is: * Attempt non-blocking copy-on-write optimizations. */ if (src_destroy && (src_object == VM_OBJECT_NULL || (src_object->temporary && !src_object->use_shared_copy)) { /* * If we are destroying the source, and the object --David From lites-readers-request Thu Apr 6 05:51:09 1995 id FAA16161; Thu, 6 Apr 1995 05:51:05 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 6 Apr 1995 14:35:35 +0300 id HAA16487; Thu, 6 Apr 1995 07:34:57 -0400 To: David Black Cc: dall@hfrd.dsto.gov.au, lites@cs.hut.fi, mach3@cs.cmu.edu, dejan@osf.org Subject: Re: Null dereference in vm_map_copyin causes deadlock Date: Thu, 06 Apr 1995 07:34:56 -0400 From: Dejan Milojicic > Looks to me as if the original test is parenthesized wrong. Correct > parenthesization is: You are missing one at the end. Besides, I believe that Ian suggests something different from the original. In his case, condition would not be fulfilled if src_object == VM_OBJECT_NULL, whereas in David's it will (and aside of lapsus linea, it seems to be correct). It is a little bit misleading that you can reference NULL object, (further down the code) but macro takes care of it. Dejan. > * Attempt non-blocking copy-on-write optimizations. > */ > > if (src_destroy && > (src_object == VM_OBJECT_NULL || (src_object->temporary && > !src_object->use_shared_copy)) > { > /* > * If we are destroying the source, and the object > > --David From lites-readers-request Thu Apr 6 19:05:28 1995 id TAA00632; Thu, 6 Apr 1995 19:05:26 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 7 Apr 1995 03:54:02 +0300 10:22:12 +1030 Date: Fri, 7 Apr 95 10:22:37 +1030 From: Ian Dall To: dejan@osf.org, mach3@cs.cmu.edu, lites@cs.hut.fi Subject: Re: Null dereference in vm_map_copyin causes deadlock In-Reply-To: <199504061134.HAA16487@postman.osf.org> References: <199504061134.HAA16487@postman.osf.org> X-Hfrd: 1995040710214890 Dejan Milojicic writes: >> Looks to me as if the original test is parenthesized wrong. >> Correct parenthesization is: > You are missing one at the end. Besides, I believe that Ian > suggests something different from the original. In his case, > condition would not be fulfilled if src_object == VM_OBJECT_NULL, > whereas in David's it will (and aside of lapsus linea, it seems to > be correct). Yes, I think that David's is correct although it a bit discomforting to see a potentially null pointer being passed to vm_object_reference. However, that function tests for VM_OBJECT_NULL and apparently does the right thing. Ian From lites-readers-request Thu Apr 20 20:32:49 1995 id UAA09676; Thu, 20 Apr 1995 20:32:46 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 21 Apr 1995 05:15:19 +0300 Date: Thu, 20 Apr 1995 19:14:50 -0700 (PDT) From: Schimkat Ralf-Dieter Subject: server in mach4 To: lites@cs.hut.fi In-Reply-To: <199503080910.RAA17832@angel.et.ntit.edu.tw> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi there, I am currently running NetBSD1.0/mach4/lites1.1 . during booting of mach/lites I get a message like : (bootstrap): loading unix symbols from /dev/sd0a/mach_servers/startup no valid symbol table header present for unix I guess that is why I can not use the vi for instance due to wrong file format, right ? does anybody have an idea what's wrong ? thanks ralf ralf schimkat comp. sc. uni. of wash., seattle From lites-readers-request Sun Apr 30 00:19:03 1995 (5.65c8/HUTCS-S 1.4 for ); Sun, 30 Apr 1995 09:05:46 +0300 Date: Sun, 30 Apr 1995 10:04:13 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: lites@cs.hut.fi Subject: Where's the EFL_USER_SET is supposed to be defined? Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII it's used in emulator/i386/s_exception.c server/i386/serv_machdep.c but I see it being defined nowhere :-( Thanx! AGL From lites-readers-request Sun Apr 30 14:41:40 1995 id OAA28866; Sun, 30 Apr 1995 14:41:39 -0600 (5.65c8/HUTCS-S 1.4 for ); Sun, 30 Apr 1995 23:32:09 +0300 Date: Sun, 30 Apr 1995 13:31:50 -0700 (PDT) From: Schimkat Ralf-Dieter Subject: ethernet card To: lites Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi , lites does not configure my ethernet card (3c503 Etherlink). Configuration: 486/DX mach4/lites-1.1/NetBSD1.0 under NetBSD everything works fine (at port 0x250 and iomem 0xd8000 and it autoconfigs as ed1) but when I boot mach it can't find the card (No such interface). Since the device configuration mechanism in mach4 is not the simplest one I am wondering if somebody had similar problems. I am not sure whether that is the appropiate mailinglist for it but maybe somebody can give me some hints though. thanks a lot Ralf-Dieter Schimkat From lites-readers-request Mon May 1 06:14:10 1995 id GAA08196; Mon, 1 May 1995 06:14:02 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 1 May 1995 15:00:58 +0300 Date: Mon, 1 May 1995 15:57:51 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: Shawn Hsiao Cc: lites@cs.hut.fi Subject: Re: Where's the EFL_USER_SET is supposed to be defined? In-Reply-To: <199505010401.MAA02191@alpha.svd.fju.edu.tw> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 1 May 1995, Shawn Hsiao wrote: > Date: Mon, 1 May 1995 12:01:42 +0800 (CST) > From: Shawn Hsiao > To: Anthony Graphics > Subject: Re: Where's the EFL_USER_SET is supposed to be defined? > > > > > it's used in > > emulator/i386/s_exception.c > > server/i386/serv_machdep.c > > but I see it being defined nowhere :-( > > Thanx! > > AGL > > > > With Mach4-UK02pl13, the definition for EFL_USER_SET is disappeared. > It's defined as EFL_FI in Mach4-UK02pl9, if my memory right. > > Okay, I've manually "fixed" eflags.h in /usr/local/include/mach/machine/ and now I'm getting '___udivdi3' unresolved from various places. What cures this? AGL From lites-readers-request Mon May 1 09:09:17 1995 id JAA09899; Mon, 1 May 1995 09:09:15 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 1 May 1995 17:59:50 +0300 id IAA09759; Mon, 1 May 1995 08:59:39 -0600 id JAA28897; Mon, 1 May 1995 09:05:42 -0600 To: Anthony Graphics Cc: lites@cs.hut.fi Subject: Re: Where's the EFL_USER_SET is supposed to be defined? In-Reply-To: Your message of "Sun, 30 Apr 95 10:04:13 +0400." Date: Mon, 01 May 95 09:05:41 MDT From: Bryan Ford >it's used in >emulator/i386/s_exception.c >server/i386/serv_machdep.c >but I see it being defined nowhere :-( EFL_USER_SET and EFL_USER_CLEAR are a private aspect of Mach's kernel implementation - why is Lites using them at all? Bryan From lites-readers-request Mon May 1 19:58:56 1995 id TAA22355; Mon, 1 May 1995 19:58:54 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 2 May 1995 04:48:50 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 2 May 1995 04:48:06 +0300 Date: Tue, 2 May 1995 04:48:06 +0300 From: Johannes Helander To: Bryan Ford Cc: lites@cs.hut.fi Subject: Re: Where's the EFL_USER_SET is supposed to be defined? In-Reply-To: <199505011505.JAA28897@schirf.cs.utah.edu> References: <199505011505.JAA28897@schirf.cs.utah.edu> Organization: Helsinki University of Technology, CS Lab. Bryan Ford writes: > >it's used in > >emulator/i386/s_exception.c > >server/i386/serv_machdep.c > >but I see it being defined nowhere :-( > > EFL_USER_SET and EFL_USER_CLEAR are a private aspect of Mach's > kernel implementation - why is Lites using them at all? > > Bryan If I remember correctly, zero was not a good default for a thread. What Lites sets is really only the user settable byte of the flags register. Since there was a convenient macro available I used it. Go ahead and change it to whatever you want. However, I'm not planning on making new Lites releases in a while so you might want to delay the Mach4 change for a while in order to keep it easy to build. Why should the macros be private anyways? The reason I'm not planning on making new releases soon is that I've been busy with other things and as far as I know noone else has made changes that are waiting for releasing. Johannes From lites-readers-request Mon May 1 19:59:47 1995 id TAA22362; Mon, 1 May 1995 19:59:45 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 2 May 1995 04:50:16 +0300 (5.65c8/HUTCS-C 1.3 for lites ); Tue, 2 May 1995 04:50:09 +0300 Date: Tue, 2 May 1995 04:50:09 +0300 From: Johannes Helander To: Schimkat Ralf-Dieter Cc: lites Subject: ethernet card In-Reply-To: References: Organization: Helsinki University of Technology, CS Lab. Schimkat Ralf-Dieter writes: > lites does not configure my ethernet card (3c503 Etherlink). Lites does not translate ethernet device names. You need to give the name Mach expects. Look at the boot messages to figure it out. Johannes From lites-readers-request Tue May 2 18:43:49 1995 id SAA13309; Tue, 2 May 1995 18:43:25 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 3 May 1995 03:29:06 +0300 id SAA13104; Tue, 2 May 1995 18:28:49 -0600 id SAA10539; Tue, 2 May 1995 18:34:58 -0600 To: Johannes Helander Cc: lites@cs.hut.fi Subject: Re: Where's the EFL_USER_SET is supposed to be defined? In-Reply-To: Your message of "Tue, 02 May 95 04:48:06 +0300." <199505020148.AA10080@glenlivet.cs.hut.fi> Date: Tue, 02 May 95 18:34:57 MDT From: Bryan Ford > > >it's used in > > >emulator/i386/s_exception.c > > >server/i386/serv_machdep.c > > >but I see it being defined nowhere :-( > > > > EFL_USER_SET and EFL_USER_CLEAR are a private aspect of Mach's > > kernel implementation - why is Lites using them at all? > > > > Bryan > >If I remember correctly, zero was not a good default for a thread. >What Lites sets is really only the user settable byte of the flags >register. Since there was a convenient macro available I used it. EFL_USER_SET and EFL_USER_CLEAR together specify the flags that the Mach kernel doesn't allow user processes any control over; I don't see how the behavior of Lites or other user-level programs can possibly be affected depending on whether EFL_USER_SET or 0 is specified in a thread_set_state request from user mode. If it is, sounds like a bug in Mach... :-) >Go ahead and change it to whatever you want. However, I'm not >planning on making new Lites releases in a while so you might want to >delay the Mach4 change for a while in order to keep it easy to build. OK, will do. Anyone trying to compile Lites against Mach4, just insert the following two lines in mach4-i386/include/mach/machine/eflags.h: #define EFL_USER_SET (EFL_IF) #define EFL_USER_CLEAR (EFL_IOPL|EFL_NT|EFL_RF) >Why should the macros be private anyways? Because they are (or at least should be :-) ) irrelevant to the functioning of user-level processes - they're internal kernel implementation details. They might change from one kernel variant to another (e.g. I can imagine a stripped-down kernel with minimal protection that gives IOPL to all user-level processes, or one that allows user processes to perform task switches, or...). Doesn't matter a whole lot for now though. >The reason I'm not planning on making new releases soon is that I've >been busy with other things and as far as I know noone else has >made changes that are waiting for releasing. No problem - I know how that goes. ;-) Thanks! Bryan From lites-readers-request Wed May 3 04:38:51 1995 id EAA20995; Wed, 3 May 1995 04:38:48 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 3 May 1995 13:28:32 +0300 Date: Wed, 3 May 1995 14:26:58 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: lites@cs.hut.fi Cc: mach4-users@cs.utah.edu Subject: [lites-1.1]: can't mount root on 950412-SNAP Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII now, finally!, I've compiled lites-1.1 under FreeBSD SNAP-950412 and mach4-p13 So, lites panicks as follows: panic: cannot mount root x9c6 /os/device no such file panic: Debugger invoked but there isn't one So, how can I specify the root is on /dev/sd0a ? (btw, how can I tell mach4 that mach_servers is in the /dev/sd0a/mach_servers so it would stop me to ask it every time the system boots?) And the last question: someone mentioned the wrapper for the linux drivers to compile 'em in mach4, I would like to get the AST4 driver from linux: the question is: where's the source lies? (Alpha or Beta or pre-alpha is ok ;-) Thank you guys! At least lites compiles now ;-) AGL From lites-readers-request Wed May 3 09:58:34 1995 id JAA25177; Wed, 3 May 1995 09:58:32 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 3 May 1995 18:49:19 +0300 Date: Wed, 3 May 1995 08:48:27 -0700 (PDT) From: Schimkat Ralf-Dieter Subject: Re: [lites-1.1]: can't mount root on 950412-SNAP To: Anthony Graphics Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > So, how can I specify the root is on /dev/sd0a ? > (btw, how can I tell mach4 that mach_servers is in the /dev/sd0a/mach_servers > so it would stop me to ask it every time the system boots?) > currently the root device in mach4 is more or less hardcoded that means you have to modify the entry in /mach4-i386/???/setroot.c . ralf schimkat From lites-readers-request Wed May 3 17:19:05 1995 id RAA04704; Wed, 3 May 1995 17:19:02 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 4 May 1995 00:32:02 +0300 Date: Wed, 3 May 1995 14:31:52 -0700 (PDT) From: Schimkat Ralf-Dieter Sender: Schimkat Ralf-Dieter Reply-To: Schimkat Ralf-Dieter Subject: mach4/lites1.1 + 3com503 (etherlink) To: lites@cs.hut.fi Cc: mach4-users@cs.utah.edu In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII hi Anyone got the 3com503 (etherlink) network card working with mach4/lites1.1/netbsd1.0 ? thanks ralf schimkat From lites-readers-request Thu May 4 00:15:41 1995 (5.65c8/HUTCS-S 1.4 for ); Thu, 4 May 1995 08:58:40 +0300 Date: Thu, 4 May 1995 09:57:10 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: lites@cs.hut.fi Subject: Re: Cross-compilation tool binaries available In-Reply-To: <199505031604.KAA18904@schirf.cs.utah.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 3 May 1995, Bryan Ford wrote: Well, I've /var/src/mach4/lites-1.1/configure --target=i386-gnu --enable-mach4 but lites build environment used gcc for compileation and linking rather than i386-gnu-gcc, is it a "feature" or the normal behaiviour? looks like /usr/local/bin/gmake CC=i386-gnu-gcc resolved the problem but I wonder is it normal? SY, AGL > Date: Wed, 03 May 95 10:04:18 MDT > From: Bryan Ford > To: mach4-announce@schirf.cs.utah.edu > Subject: Cross-compilation tool binaries available > > To make it easier to compile Mach, we've placed a number of > pre-configured, pre-built cross-compiler tools in > jaguar.cs.utah.edu:/flexmach/binaries/*/tools.tar.gz. > There are versions for NetBSD 1.0, FreeBSD 2.0, and Linux. > All of them contain binaries for GCC 2.6.2 and gas-950428 > configured as cross-tools for target i386-mach. The > NetBSD and FreeBSD archives also contain a few other tools > needed to build Mach, such as GNU make. > > To install these archives, just extract the appropriate tar > file into your root directory, and they'll automatically be > installed in the appropriate places under /usr/local. > Note that the cross-compilation tools will not conflict with > your native development tools, because they are all prefixed > with 'i386-mach-'. > > With these tools installed, you should be able to build Mach > with the following configure line: > > ../mach4-386/configure --with-mach4=../mach4 --target=i386-mach > > Bryan > --- > Bryan Ford baford@cs.utah.edu University of Utah, CSS > `finger baford@schirf.cs.utah.edu' for PGP key and other info. > From lites-readers-request Thu May 4 03:13:58 1995 id DAA11037; Thu, 4 May 1995 03:13:56 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 4 May 1995 11:55:17 +0300 Date: Thu, 4 May 1995 12:53:47 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: Schimkat Ralf-Dieter Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu Subject: Re: [lites-1.1]: can't mount root on 950412-SNAP In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 3 May 1995, Schimkat Ralf-Dieter wrote: > Date: Wed, 3 May 1995 08:48:27 -0700 (PDT) > From: Schimkat Ralf-Dieter > To: Anthony Graphics > Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu > Subject: Re: [lites-1.1]: can't mount root on 950412-SNAP > > > > > So, how can I specify the root is on /dev/sd0a ? > > (btw, how can I tell mach4 that mach_servers is in the /dev/sd0a/mach_servers > > so it would stop me to ask it every time the system boots?) > > > > currently the root device in mach4 is more or less hardcoded that means you > have to modify the entry in /mach4-i386/???/setroot.c . > > ralf schimkat > Helped. Thanx. I wonder how it managed to load startup from /mach_servers/ before mounting root... I thought it's a lites's bug then. Thank you very much anyway. AGL > > > From lites-readers-request Thu May 4 15:02:19 1995 id PAA23290; Thu, 4 May 1995 15:02:15 -0600 From: cmaeda@cs.washington.edu (5.65c8/HUTCS-S 1.4 for ); Thu, 4 May 1995 23:50:04 +0300 Date: Thu, 4 May 1995 13:49:56 -0700 To: lites@cs.hut.fi, mach4-users@cs.utah.edu Cc: cmaeda@cs.washington.edu Subject: looking for a networking project in Lites? I'm looking for someone that's interested in doing a development project in Lites. This is something I've been meaning to do for over a year, but it looks like it will be another year before I'll even be able to think about it. This might be a good project for someone getting a BS or MS in computer science that has to do some sort of thesis project, or anyone that is looking for an interesting OS project. In the CMU Mach system, I developed a TCP/IP implementation that is a library linked with each application. It provides compatibility with sockets through a "proxy sockets" package linked with the OS server, and was able to match the performance of in-kernel TCP/IP implementations like Mach 2.5 and Ultrix. (This is a big deal for Mach 3.0 systems that historically have had dismal networking performance.) Convex Computer is using this basic design for the networking subsystem on their multicomputers, though they're doing a from-scratch implementation. I have two implementations; one runs in the CMU MK/UX system, and the other runs in a DEC Unix compatible OSF microkernel system we have here at UWashington. I'm looking for someone that is interested in porting it to Lites. It should be a straightforward port. The trickiest part will probably be integrating the proxy sockets package with the Lites server. There are some unexplored issues as well, like putting the TCP/IP library in the Lites emulator or a Lites-specific shared libc, and making it possible for applications to customize the library. This work was presented at the 1993 SOSP. The paper is online:
  • Protocol Service Decomposition for High Performance Networking. Maeda and Bershad. 14th SOSP. 1993. Let me know if you're interested. I'm currently a grad student finishing up my PhD so I'm not in a position to offer any resources like money or equipment. However, I can give you code and lots of advice and guidance. If you're working on a thesis, I can also serve as some sort of outside advisor on your thesis project. Best regards, Chris Maeda From lites-readers-request Thu May 11 04:41:53 1995 id EAA06091; Thu, 11 May 1995 04:40:50 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 11 May 1995 13:27:45 +0300 on Thu, 11 May 1995 13:04:37 +0300 (EET DST); with id AA02071 From: Marios Chrysopoulos Organization: Date: Thu, 11 May 1995 13:05:21 +0300 To: lites@cs.hut.fi Subject: Lites On Alpha's Hi, i'm trying to make Lites work on a DEC AXP 3000/300 model and i'm facing some problems, so i was wandering if you could help a bit... When the server tries to load mach_init, it instead loads the emulator (reasonable since mach_init is not a native Lites program), but the emulator crashes shortly after starting. I found out that it creates a segmentation violation when trying to run mach_init_routine(). If i comment out this, the emulator hangs; the task seems to be running but doesn't do anything and after some time i get the message panic: vm_object_pager_create: Allocate pager port. Note that i can't see any thread being destroyed by this. I don't know what this mach_init_routine is (the only place i found it - the pointer to it actually - is the system's crt0.o) and i can't find its address either as i can't print anything from this point (i even tried e_emulator_error but to no avail). (BTW, shouldn't mach_init_routine be declared in ecrt0.c as 'extern'?) Any help would be appreciated! Thanks a lot, Marios From lites-readers-request Thu May 11 19:13:15 1995 id TAA17478; Thu, 11 May 1995 19:13:09 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 12 May 1995 03:53:16 +0300 (5.65c8/HUTCS-C 1.3 for lites); Fri, 12 May 1995 03:52:53 +0300 Date: Fri, 12 May 1995 03:52:53 +0300 From: Johannes Helander To: Marios Chrysopoulos Cc: lites@cs.hut.fi Subject: Re: Lites On Alpha's In-Reply-To: <9505101507.AA07084@pleiades.csi.forth.gr> References: <9505101507.AA07084@pleiades.csi.forth.gr> Organization: Helsinki University of Technology, CS Lab. mach_init_routine is supposed to be a pointer to the init routine of libmach. It is necessary in the emulator. You could call mach_init() directly from ecrt0 instead of going through the pointer. Make sure you are linking with the correct libmach. OSF's libmach initializes _mach_init_routine instead of mach_init_routine. This is another good reason to call mach_init() directly. Then if that doesn't work you'll at least get a link error instead of just randomly crashing. Johannes From lites-readers-request Mon May 15 16:53:10 1995 id QAA17821; Mon, 15 May 1995 16:53:05 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 16 May 1995 01:40:09 +0300 (5.65c8/HUTCS-C 1.3 for lites); Tue, 16 May 1995 01:37:26 +0300 Date: Tue, 16 May 1995 01:37:26 +0300 From: Johannes Helander To: andrea@inf.ufrgs.br (Andrea Schwertner Charao) Cc: lites@cs.hut.fi Subject: Re: mount problems? In-Reply-To: <9505152120.AA29464@inf.ufrgs.br> References: <9505152120.AA29464@inf.ufrgs.br> Organization: Helsinki University of Technology, CS Lab. Andrea Schwertner Charao writes: > > Johannes, > I'm using Lites1.1 (binary version from lites ftp-server) on Mach4+NetBSD1.0, and > everything works fine when I'm logged on as root. When I try to log as a non-priviledged > user, I got the following messages: > > server_exec_open: emulator "/mach_servers/emulator" not found: 49165 This translates to 'access denied'. Most likely there are no execute permissions on the emulator. VOP_ACCESS is used to check execute permissions and for root it always succeeds. Thus on Lites root may execute programs that don't have any X-bits but normal users can't. So the simple answer is to chmod a+x /mach_servers/emulator when you are root. Yes, the error message could print out the number as a mach_error_string. > server_exec_open: emulator "/mach_servers/emulator.old" not found: 49154 > server_exec_open: emulator "/sbin/emulator" not found: 49154 > server_exec: unable to exec any emulator > /bin/csh: Unknown error: 49154 This looks like an actual bug. Execve seemingly doesn't translate the error code in case of failure. That should be easy to fix (emul_exec.c I think). > I don't know if I'm missing something, but maybe it is a mount problem. > also, when the system boots up, Lites allways prints that some partition > has not been properly dismounted. I have picked up some binaries (mount_nfs, fsck,...) > from leia, but there is no mount there. > ... This is because of two things: - Lites checks the clean bit in the file system but only FreeBSD;s fsck sets it. - Lites doesn't umount disks at shutdown, it only syncs them and thus the clean bit isn't set. If you explicitely umount your disks there will be no complaints. Fix: use ffs_fsck from FreeBSD and add code to Lites to umount all disks at shutdown. This has nothing to do with the emulator though. Johannes From lites-readers-request Wed May 17 04:48:22 1995 id EAA24310; Wed, 17 May 1995 04:48:10 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 17 May 1995 13:27:01 +0300 on Wed, 17 May 1995 13:25:46 +0300 (EET DST); with id AA12397 From: Marios Chrysopoulos Organization: Date: Wed, 17 May 1995 13:26:31 +0300 To: jvh@cs.hut.fi Subject: Re: Lites On Alpha's In-Reply-To: Mail from 'Johannes Helander ' dated: Fri, 12 May 1995 03:52:53 +0300 Cc: lites@cs.hut.fi >mach_init_routine is supposed to be a pointer to the init routine of >libmach. It is necessary in the emulator. You could call mach_init() >directly from ecrt0 instead of going through the pointer. Make sure >you are linking with the correct libmach. OSF's libmach initializes >_mach_init_routine instead of mach_init_routine. This is another good >reason to call mach_init() directly. Then if that doesn't work you'll >at least get a link error instead of just randomly crashing. Figures...i did so, and init still crashes...after tracing through the code i found out that it crashed just after returning from mach_task_self, and since putting a while (1) after the call to mach_task_self didn't affect anything, the only logical conclusion is that the return sequence from the trap caused the crash. This could only have been caused due to improper register handling, and since you're doing some stuff with registers in __start(), i was wandering if something bad happens there... Any other ideas? Thanks a lot, Marios From lites-readers-request Tue Jun 13 07:37:26 1995 id HAA00829; Tue, 13 Jun 1995 07:37:25 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 13 Jun 1995 16:17:49 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 13 Jun 1995 16:17:48 +0300 Date: Tue, 13 Jun 1995 16:17:48 +0300 From: Jukka Partanen To: lites@cs.hut.fi Subject: PPP I just added PPP to Lites 1.1, is anybody interested? Currently I'm using NetBSD to build Lites, and bootstrap needs to be modified to be able to load it. If someone wants it, I'll build it on leia. jtp I think I am an overnight sensation right now!! From lites-readers-request Wed Jun 14 16:22:08 1995 id QAA29552; Wed, 14 Jun 1995 16:21:59 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 14 Jun 1995 23:10:49 +0300 Date: Wed, 14 Jun 95 16:19:19 EST From: andrea@inf.ufrgs.br (Andrea Schwertner Charao) To: lites@cs.hut.fi I'm using gettimeofday() function on Lites, and I have observed that the tv_usec field never holds a value lower than 10000 microseconds. Is this an usual behavior of such function on Lites? Any comments will be very much appreciated. Andrea Schwertner Charao (andrea@inf.ufrgs.br) From lites-readers-request Wed Jun 14 16:49:08 1995 id QAA29961; Wed, 14 Jun 1995 16:49:05 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 01:38:32 +0300 id QAA29781; Wed, 14 Jun 1995 16:38:23 -0600 id QAA19649; Wed, 14 Jun 1995 16:38:21 -0600 Date: Wed, 14 Jun 1995 16:38:21 -0600 From: mike@cs.utah.edu (Mike Hibler) To: andrea@inf.ufrgs.br, lites@cs.hut.fi Subject: gettimeofday > Date: Wed, 14 Jun 95 16:19:19 EST > From: andrea@inf.ufrgs.br (Andrea Schwertner Charao) > To: lites@cs.hut.fi > > I'm using gettimeofday() function on Lites, and I have observed that > the tv_usec field never holds a value lower than 10000 microseconds. > Is this an usual behavior of such function on Lites? > Any comments will be very much appreciated. > 10000 microseconds is probably the resolution of your clock (at least as Mach uses it) so I would expect to see only values: 0, 10000, 20000, ..., 990000 but you should occasionally see 0. Note that if you are trying to do something like use the low digits as a random value (e.g. usec % 1000) it isn't going to work very well :-) From lites-readers-request Wed Jun 14 19:17:08 1995 id TAA02087; Wed, 14 Jun 1995 19:17:00 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 02:43:33 +0300 id RAA00757; Wed, 14 Jun 1995 17:43:29 -0600 id RAA20496; Wed, 14 Jun 1995 17:43:27 -0600 Date: Wed, 14 Jun 1995 17:43:27 -0600 From: mike@cs.utah.edu (Mike Hibler) To: andrea@inf.ufrgs.br, lites@cs.hut.fi, mike@cs.utah.edu Subject: Re: gettimeofday > Date: Wed, 14 Jun 95 20:08:39 EST > From: andrea@inf.ufrgs.br (Andrea Schwertner Charao) > To: mike@cs, lites@cs.hut.fi > Subject: Re: gettimeofday > > Actually I'm using gettimeofday to measure the time spent in processing > some instructions in a program, so it's useful to get the low digits... > I have tested gettimeofday on the same machine (i486), but using NetBSD instead > of Mach+Lites, and it clearly have higher resolution. > I don't know how Mach deals with the clock, but such resolution is very limited :-( > Does anyone have seen the same behavior of gettimeofday on such > system configuration (Mach4+Lites1.1 on i486)? > Timers is an area of Mach I haven't dealt with, but... The hardware should certainly do better than 10000 usec. For example, the HP PA-RISC has a 32-bit cycle counter register which you could read to get resolution in the 10's of nsec. The HP 68k clock chip could be configured to free run a timer and give a 32-bit value with 4 usec resolution. In BSD we had an interface to map the clock HW into the user's address space so they could read that directly. However, I am not sure if Mach exports (either directly or through Lites) an interface to do something similar for the x86. Someone else out there is bound to know. What Mach does to keep track of time-of-day is to increment a software time value by a fixed amount at every clock interrupt. With 100 ints/sec you get the 10000 usec steps. This is the machine-independent timer that it exports and that gettimeofday() uses. From lites-readers-request Wed Jun 14 19:20:53 1995 id TAA02119; Wed, 14 Jun 1995 19:20:50 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 04:12:09 +0300 Date: Wed, 14 Jun 95 18:11:13 PDT From: James Goss To: lites@cs.hut.fi Subject: unsubscribe Cc: jjg@elsegundoca.attgis.com unsubscribe jjg@ElSegundoCA.ATTGIS.COM From lites-readers-request Wed Jun 14 19:40:46 1995 id TAA02310; Wed, 14 Jun 1995 19:40:42 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 03:06:14 +0300 Date: Wed, 14 Jun 95 20:08:39 EST From: andrea@inf.ufrgs.br (Andrea Schwertner Charao) To: mike@cs.utah.edu, lites@cs.hut.fi Subject: Re: gettimeofday > 10000 microseconds is probably the resolution of your clock (at least as > Mach uses it) so I would expect to see only values: > > 0, 10000, 20000, ..., 990000 > > but you should occasionally see 0. Note that if you are trying to do > something like use the low digits as a random value (e.g. usec % 1000) > it isn't going to work very well :-) > Actually I'm using gettimeofday to measure the time spent in processing some instructions in a program, so it's useful to get the low digits... I have tested gettimeofday on the same machine (i486), but using NetBSD instead of Mach+Lites, and it clearly have higher resolution. I don't know how Mach deals with the clock, but such resolution is very limited :-( Does anyone have seen the same behavior of gettimeofday on such system configuration (Mach4+Lites1.1 on i486)? Andrea S. Charao From lites-readers-request Thu Jun 15 02:51:48 1995 id CAA06317; Thu, 15 Jun 1995 02:51:46 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 11:40:13 +0300 Date: Thu, 15 Jun 1995 12:34:57 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: Jukka Partanen Cc: lites@cs.hut.fi Subject: Re: PPP In-Reply-To: <199506131317.AA14680@glenlivet.cs.hut.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Jun 1995, Jukka Partanen wrote: > Date: Tue, 13 Jun 1995 16:17:48 +0300 > From: Jukka Partanen > To: lites@cs.hut.fi > Subject: PPP > > > I just added PPP to Lites 1.1, is anybody interested? > Currently I'm using NetBSD to build Lites, and bootstrap needs > to be modified to be able to load it. If someone wants it, > I'll build it on leia. > > jtp > > I think I am an overnight sensation right now!! > It's exciting. Is it pppd-2.1.2[d] based? Anyway: GREAT! SY, AGL From lites-readers-request Thu Jun 15 07:13:55 1995 id HAA08824; Thu, 15 Jun 1995 07:13:25 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 15 Jun 1995 15:58:28 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 15 Jun 1995 15:43:41 +0300 Date: Thu, 15 Jun 1995 15:43:41 +0300 From: Jukka Partanen To: Anthony Graphics Cc: lites@cs.hut.fi Subject: Re: PPP In-Reply-To: References: <199506131317.AA14680@glenlivet.cs.hut.fi> Anthony Graphics writes: > It's exciting. Is it pppd-2.1.2[d] based? Anyway: GREAT! > SY, Well, I pulled ppp-2.1.2.tar.gz from dcssoft.anu.edu.au, I don't know about whether it's d or not. The binaries are available from ftp.funet.fi in /pub/mach/lites/i386-bin/startup.Lites.1.1.STD+WS+ppp*. I will post diffs soon. Ian Dall suggested that there might be some problems with Lites tty IO and high speeds, but I haven't experienced any problems with 19.2k (x86, but not a PC). jtp .. I see TOILET SEATS... From lites-readers-request Thu Jun 15 18:51:21 1995 id SAA19768; Thu, 15 Jun 1995 18:51:18 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 03:42:58 +0300 Date: Thu, 15 Jun 95 17:20:18 MST From: ronf@phx.sectel.mot.com (Ron Feigen) To: lites@cs.hut.fi Subject: lites H/W support Hi, I am trying to install desperately to get MACH running on an Intel platform. Will lites support my IDE controller? Somebody thought it was SCSI only? Is there any good info on building lites on Linux? I can try to install NetBSD or FreeBSD but I would rather not have to. Actually I tried FreeBSD last night and it when fine until I needed to reboot (after building my disk). The reboot hung my system (wierd)! Any help will be greatly appreciated, Thanks, Ron From lites-readers-request Thu Jun 15 20:25:48 1995 id UAA20709; Thu, 15 Jun 1995 20:25:46 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 03:55:22 +0300 To: ronf@phx.sectel.mot.com (Ron Feigen) Cc: lites@cs.hut.fi Subject: Re: lites H/W support In-Reply-To: Your message of "Thu, 15 Jun 95 17:20:18 MST." <9506160020.AA22068@ phx.sectel.mot.com> From: David Greenman Reply-To: davidg@root.com Date: Thu, 15 Jun 1995 17:55:14 -0700 Sender: root@corbin.Root.COM >try to install NetBSD or FreeBSD but I would rather not >have to. Actually I tried FreeBSD last night and it when fine >until I needed to reboot (after building my disk). The reboot >hung my system (wierd)! Actually, it doesn't reboot after the install, it just halts and the message that it has done this is output on the wrong virtual console. If you had simply pressed "enter", the system would have rebooted. It's a known bug and will be fixed eventually. -DG From lites-readers-request Thu Jun 15 20:30:45 1995 id UAA20755; Thu, 15 Jun 1995 20:30:39 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 03:35:19 +0300 Date: Thu, 15 Jun 95 17:03:54 MST From: ronf@phx.sectel.mot.com (Ron Feigen) To: lites@cs.hut.fi Subject: subscribe please subscribe me From lites-readers-request Fri Jun 16 00:07:33 1995 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 08:59:25 +0300 Subject: unsuscribe From: Gertraud Unterreitmeier To: lites@cs.hut.fi Date: Fri, 16 Jun 1995 07:58:49 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 12 unsuscribe From lites-readers-request Fri Jun 16 01:57:27 1995 id BAA23449; Fri, 16 Jun 1995 01:57:19 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 10:47:19 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 16 Jun 1995 10:47:09 +0300 Date: Fri, 16 Jun 1995 10:47:09 +0300 From: Johannes Helander To: ronf@phx.sectel.mot.com (Ron Feigen) Cc: lites@cs.hut.fi Subject: Re: lites H/W support In-Reply-To: <9506160020.AA22068@ phx.sectel.mot.com> References: <9506160020.AA22068@ phx.sectel.mot.com> Organization: Helsinki University of Technology, CS Lab. Ron Feigen writes: > Will lites support my IDE controller? Somebody thought > it was SCSI only? Lites itself doesn't care whether something is IDE or SCSI. The only limitation is taht it needs to know how to map device numbers to Mach device names. I think the situation is that you can have one IDE disk but the Mach3 driver didn't work for two. But there might be a newer driver? > Is there any good info on building lites on Linux? I can I think I made it work with the Linux linker that should be the only problem. When linking the emulator -qmagic is used. I tried that in October but not since so it might have broken. Let us know how it went if you try. Johannes PS everybody: use lites-request@cs.hut.fi for subscriptions and unsubscriptions. Thanks. From lites-readers-request Fri Jun 16 02:09:56 1995 id CAA23589; Fri, 16 Jun 1995 02:09:54 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 11:00:09 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Fri, 16 Jun 1995 10:58:56 +0300 Date: Fri, 16 Jun 1995 10:58:56 +0300 From: Johannes Helander To: andrea@inf.ufrgs.br (Andrea Schwertner Charao) Cc: lites@cs.hut.fi Subject: Re: gettimeofday In-Reply-To: <9506142308.AA05214@inf.ufrgs.br> References: <9506142308.AA05214@inf.ufrgs.br> Organization: Helsinki University of Technology, CS Lab. Andrea Schwertner Charao writes: > > 10000 microseconds is probably the resolution of your clock (at least as > > Mach uses it) so I would expect to see only values: > > > > 0, 10000, 20000, ..., 990000 > > > > but you should occasionally see 0. Note that if you are trying to do If you never see zero there is probably a bug somewhere. But yes the time you see is maintained by the clock interrupts and changes only every 10 ms. > I don't know how Mach deals with the clock, but such resolution is very limited :-( > Does anyone have seen the same behavior of gettimeofday on such > system configuration (Mach4+Lites1.1 on i486)? RTMach should have better clock facilities. But Lites doesn't use them even if you are running on RTMach. This could be fixed. In theory you should be able to get about 1 us resolution from the peecees toy chip. But sincfe the chip isn't very nice I don't think you can expect to read it from applications. The Lites gettimeofday code was written in mind of a free running counter like some DEC boxes have. But peecees don't unfortunately. Johannes From lites-readers-request Fri Jun 16 02:33:07 1995 id CAA23761; Fri, 16 Jun 1995 02:32:16 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 11:19:52 +0300 Date: Fri, 16 Jun 1995 12:16:50 +0400 (GMT+0400) From: Anthony Graphics X-Sender: agl@mail.redline.ru To: Jukka Partanen Cc: lites@cs.hut.fi Subject: Re: PPP In-Reply-To: <199506151243.AA19357@glenlivet.cs.hut.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jun 1995, Jukka Partanen wrote: > Anthony Graphics writes: > > It's exciting. Is it pppd-2.1.2[d] based? Anyway: GREAT! > > SY, > > Well, I pulled ppp-2.1.2.tar.gz from dcssoft.anu.edu.au, I > don't know about whether it's d or not. The binaries are > available from ftp.funet.fi in > /pub/mach/lites/i386-bin/startup.Lites.1.1.STD+WS+ppp*. I will > post diffs soon. 2.1.2d is on ftp://sunsite.unc.edu./pub/Linux/system/Network/....don't exaclty remember then... 2.1.2 ain't compiling on my FreeBSD box however, but it fixes some bugs that are related to _all_ 2.1.2 platforms, not just Linux. You can try to generate the diff between bare 2.1.2 and 2.1.2d to see whether changes are worth being incorporated in your port I suppose. Still bare bones 2.1.2 worked for me just fine under freebsd... I suppose the bug in the common code was triggered only in Linux for some reason... AGL > > Ian Dall suggested that there might be some problems with > Lites tty IO and high speeds, but I haven't experienced any > problems with 19.2k (x86, but not a PC). > > jtp > > .. I see TOILET SEATS... > From lites-readers-request Fri Jun 16 08:42:26 1995 id IAA27266; Fri, 16 Jun 1995 08:42:15 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 17:29:38 +0300 id HAA16159; Fri, 16 Jun 1995 07:28:47 -0700 Date: Fri, 16 Jun 1995 07:28:47 -0700 From: ronf1@ix.netcom.com (Ron Feigen) Subject: please subscribe To: lites@cs.hut.fi subscribe ronf1@ix.netcom.com From lites-readers-request Fri Jun 16 11:18:44 1995 id LAA29949; Fri, 16 Jun 1995 11:18:37 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 16 Jun 1995 17:33:04 +0300 id HAA16527; Fri, 16 Jun 1995 07:32:19 -0700 Date: Fri, 16 Jun 1995 07:32:19 -0700 From: ronf1@ix.netcom.com (Ron Feigen) Subject: Lites H/W support To: lites@cs.hut.fi Can anybody point me to a lites how to? Does lites support E-IDE? How about IDE CDROMS? I am attempting to build Lites using Linux. Is this a bad idea? Would NetBSD or FreeBSD be better? Which is best? Actaully I couldn't get FreeBSD to install (it hung my system) but I am willing to try harder if it is the best O/S to build Mach4 and Lites. Any assistance will be greatly appreciated Ron Feigen From lites-readers-request Mon Jun 19 16:16:19 1995 id QAA15145; Mon, 19 Jun 1995 16:16:01 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Jun 1995 00:51:57 +0300 (5.67b+/DEC-Ultrix/4.3) id AA14665; Mon, 19 Jun 1995 23:51:52 +0200 Date: Mon, 19 Jun 1995 23:51:52 +0200 From: sr1@irz301.inf.tu-dresden.de (Sven Rudolph) To: lites@cs.hut.fi Subject: Problems booting Lites 1.1 We built Lites 1.1 on FreeBSD 2.0.5 (with mach4-UK02pl13, gas-950606, gcc-2.6.2, everything configured for i386-mach4). I applied the EFL_USER_SET changes. (The Mach kernel seems to be correct, at least it boots the current Hurd binary snapshot.) /mach_servers containes only startup, emulator and the binary-provided mach_init. When Mach is booted, it starts startup and claims that it cannot find the symbol table, though i386-mach4-nm showed it. Is this supposed to happen? Is there a way to get useful traces from the Mach kernel debugger? When Lites is compiled with --enable-debug, it panics after displaying the Lites copyright messages: panic: Assertion `m->holder == 0' failed at .../lites-1.1/server/serv/insert_mach.h:81 Without --enable-debug, it panics after displaying the "The Time is set to" message: panic: init died (This happens with either mach_init or FreeBSD's /sbin/init.) Is this a known problem? Any solutions? Sven -- Sven Rudolph (sr1@inf.tu-dresden.de); WWW : http://www.sax.de/~sr1/ From lites-readers-request Mon Jun 19 23:24:01 1995 id XAA20614; Mon, 19 Jun 1995 23:18:51 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Jun 1995 07:49:50 +0300 id HAA19893; Tue, 20 Jun 1995 07:49:35 +0300 X-Mailer: exmh version 1.6.1 5/23/95 From: Pekka.Nikander@nixu.fi To: sr1@irz301.inf.tu-dresden.de (Sven Rudolph) Cc: lites@cs.hut.fi Subject: Re: Problems booting Lites 1.1 In-Reply-To: Your message of Mon, 19 Jun 1995 23:51:52 +0200. <199506192151.AA14665@irz301.inf.tu-dresden.de> Organization: Nixu Oy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 1995 06:52:16 +0200 Sender: pnr@tequila.nixu.fi > We built Lites 1.1 on FreeBSD 2.0.5 (with mach4-UK02pl13, gas-950606, > gcc-2.6.2, everything configured for i386-mach4). I applied the I was using NetBSD 1.0, mach4-UK2pl13, gcc, gas and gld supplied by Utah (don't remember versions), and got exactly the same results. > When Lites is compiled with --enable-debug, it panics after displaying > the Lites copyright messages: > > panic: Assertion `m->holder == 0' failed at .../lites-1.1/server/serv/insert_mach.h:81 I got this too. Disabling mutex checking removed these messages. Johannes thought that maybe the mach thread library is different or compiled differently. > Without --enable-debug, it panics after displaying the "The Time is > set to" message: > > panic: init died I got this too. According to my experiments this is due to Lites emulator dying immediately, i.e. while Lites server (startup) tries to exec it. I didn't find out why; I suspect linking problems. Finally I fetched the ready compiled emulator binary from HUT and got the thing running with it. I am still unable to properly compile/link the emulator. --pekka Nikander From lites-readers-request Tue Jun 20 02:09:43 1995 id CAA22414; Tue, 20 Jun 1995 02:09:37 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 20 Jun 1995 09:18:30 +0300 From: sclawson@schnapps.cs.utah.edu (steve clawson) Subject: Re: Problems booting Lites 1.1 (fwd) To: lites@cs.hut.fi Date: Tue, 20 Jun 1995 00:18:13 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3577 I forgot to send this to the list too. Oops. steve sclawson uttered: > From sclawson Mon Jun 19 17:49:21 1995 > Subject: Re: Problems booting Lites 1.1 > To: sr1@irz301.inf.tu-dresden.de (Sven Rudolph) > Date: Mon, 19 Jun 1995 17:49:21 -0600 (MDT) > In-Reply-To: <199506192151.AA14665@irz301.inf.tu-dresden.de> from "Sven Rudolph" at Jun 19, 95 11:51:52 pm > X-Mailer: ELM [version 2.4 PL23] > Content-Type: text > Content-Length: 2862 > > Sven Rudolph uttered: > > When Mach is booted, it starts startup and claims that it cannot find > > the symbol table, though i386-mach4-nm showed it. Is this supposed to > > happen? Is there a way to get useful traces from the Mach kernel > > debugger? > > The symbol handling in the mach4 kernel is still somewhat broken > and is currently turned off. Yet another thing that needs to be > fixed. =) > > > Without --enable-debug, it panics after displaying the "The Time is > > set to" message: > > > > panic: init died > > > > (This happens with either mach_init or FreeBSD's /sbin/init.) > > > > Is this a known problem? Any solutions? > > I'm not sure if it's a known problem, but I've run into it while > cross-compiling lites. It turns out that the native UX linker does > some funky stuff with the text start address. It turns out that the > a.out header is mapped at 0x1000 (I believe) in a UX binary, so the > native linker adds the 0x20 to jump over it. However, the gnu linker > _dosen't_ add the magic 0x20, so you have to modify this little > program: > > .../lites-1.1/emulator/programs/emulator_base.c > > (It's gross and disgusting and needs to be replaced, but...) > > Basically you want to take the 'linux' ifdef and change the > "EMULATOR_BASE + 0x1000" to "EMULATOR_BASE + 0x1020", and make sure > that it gets compiled in for the cross compiler. Needless to say I'm > not sure how you would 'portably' do this sort of thing. It seems > that this sort of thing should be in a configuration file set up by > configure... Anyway, here's how I changed it, hopefully it'll work > for you. > > steve > > > > > *** emulator_base.c Thu May 25 17:57:16 1995 > --- /u/sclawson/orig/lites-1.1/emulator/programs/emulator_base.c Mon Mar > 6 10:15:34 1995 > *************** > *** 31,42 **** > #if defined(TARGET_i386) || defined(TARGET_I386) > main() { > /* XXX this is really linker dependent, not system dependent. */ > ! printf("-e __start -qmagic -Ttext 0x%x\n", > ! EMULATOR_BASE + 0x1020); > ! return 0; > } > ! #endif > ! #if defined(TARGET_mips) > main() { > printf("-e __start -T %x -D %x\n", > EMULATOR_BASE, > --- 31,48 ---- > #if defined(TARGET_i386) || defined(TARGET_I386) > main() { > /* XXX this is really linker dependent, not system dependent. */ > ! # ifdef linux > ! printf("-e __start -qmagic -static -Ttext 0x%x\n", > ! EMULATOR_BASE + 0x1000); > ! # elif OSF1 > ! printf("-e _start -Ttext %x\n", EMULATOR_BASE + 0x1000); > ! # else > ! /* No 0x here as the old linker makes the address zero! */ > ! printf("-e __start -T %x\n", EMULATOR_BASE + 0x1000); > ! # endif > ! return 0; > } > ! #elif defined(TARGET_mips) > main() { > printf("-e __start -T %x -D %x\n", > EMULATOR_BASE, > > > -- > // stephen clawson sclawson@schnapps.cs.utah.edu > // university of utah > > -- // stephen clawson sclawson@schnapps.cs.utah.edu // university of utah From lites-readers-request Thu Jun 22 14:30:22 1995 id OAA05810; Thu, 22 Jun 1995 14:30:11 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 22 Jun 1995 23:14:25 +0300 Date: Thu, 22 Jun 95 12:20:21 MST From: ronf@phx.sectel.mot.com (Ron Feigen) To: lites@cs.hut.fi Subject: subscribe subscribe From lites-readers-request Fri Jun 23 10:11:51 1995 id KAA17951; Fri, 23 Jun 1995 10:11:40 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 23 Jun 1995 18:56:52 +0300 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 23 Jun 1995 11:53:52 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 23 Jun 1995 11:07:29 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 23 Jun 1995 11:02:00 -0400 Date: Fri, 23 Jun 1995 11:02:00 -0400 X400-Originator: /dd.id=0201187/g=luther/i=lw/s=stephens/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.482:23.05.95.15.07.29] X400-Content-Type: P2-1984 (2) Content-Identifier: unsubscribe From: "luther (l.w.) stephens" Sender: "luther (l.w.) stephens" To: lites@cs.hut.fi Subject: unsubscribe unsubscribe From lites-readers-request Sun Jun 25 12:20:36 1995 id MAA10627; Sun, 25 Jun 1995 12:20:31 -0600 (5.65c8/HUTCS-S 1.4 for ); Sun, 25 Jun 1995 20:37:32 +0300 (5.67b+/DEC-Ultrix/4.3) id AA28332; Sun, 25 Jun 1995 19:37:25 +0200 Subject: FreeBSD 2.0.5 shared libraries? To: lites@cs.hut.fi Date: Sun, 25 Jun 1995 19:37:25 +0200 (MET DST) From: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Organization: Dept. of Computer Science, TU Dresden, Germany X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 376 Is there an easy way to use FreeBSD 2.0.5 shared libraries with FreeBSD 2.0.5 binaries under Lites 1.1? This didn't work for us; when we tried this, the binaries just crashed with bus errors. (For now, we've just statically re-linked the whole FreeBSD 2.0.5 system.) Thanks in advance, Michael -- Email: hohmuth@inf.tu-dresden.de WWW: http://www.inf.tu-dresden.de/~mh1/ From lites-readers-request Sun Jul 2 18:49:16 1995 id SAA23512; Sun, 2 Jul 1995 18:49:14 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 3 Jul 1995 03:39:47 +0300 id RAA27109; Sun, 2 Jul 1995 17:38:42 -0700 Date: Sun, 2 Jul 1995 17:38:42 -0700 X-Sender: ronf1@popd.ix.netcom.com (Unverified) X-Mailer: Windows Eudora Version 1.4.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: lites@cs.hut.fi From: ronf1@ix.netcom.com (Ron Feigen) Subject: subscribe subscribe ronf1@ix.netcom.com From lites-readers-request Sun Jul 2 23:10:25 1995 id XAA24839; Sun, 2 Jul 1995 23:10:23 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 3 Jul 1995 07:57:31 +0300 id VAA04584; Sun, 2 Jul 1995 21:56:26 -0700 Date: Sun, 2 Jul 1995 21:56:26 -0700 X-Sender: ronf1@popd.ix.netcom.com (Unverified) X-Mailer: Windows Eudora Version 1.4.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: lites@cs.hut.fi From: ronf1@ix.netcom.com (Ron Feigen) Subject: soory about multiple subscription requests Sorry abuot the multiple subscription request. I was a driver error :-). Hope nobody got too annoyed. Regards, Ron Feigen From lites-readers-request Mon Jul 3 01:41:28 1995 id BAA25693; Mon, 3 Jul 1995 01:41:25 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 3 Jul 1995 10:26:51 +0300 Date: Mon, 3 Jul 1995 00:25:36 -0700 X-Sender: ronf1@popd.ix.netcom.com (Unverified) X-Mailer: Windows Eudora Version 1.4.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: lites@cs.hut.fi From: ronf1@ix.netcom.com (Ron Feigen) Subject: second_syscall.s & mach_init Cc: mach4-users@cs.utah.edu Two questions please, 1) I am trying to build lites under FreeBSD 2.0 on an i586. I am using the i386-mach buildtools from jaguar I used to cross-compile mach. I configured both --host and --build = i386-mach. I get the following error in lines 318-327 when trying to build second_syscall.s: as:{standard input}:318 invalid character '_' in opcode I believe these are the kernel_trap calls but I can't figure out the fix. 2) I checked leia:foggy for mach_init but the dir is empty. Is there a FreeBSD mach_init source or binary around? Thanks in advance, Ron From lites-readers-request Mon Jul 3 03:06:00 1995 id DAA26457; Mon, 3 Jul 1995 03:05:55 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 3 Jul 1995 11:51:34 +0300 (5.67b+/DEC-Ultrix/4.3) id AA25046; Mon, 3 Jul 1995 10:50:43 +0200 Subject: Re: second_syscall.s & mach_init To: ronf1@ix.netcom.com (Ron Feigen) Date: Mon, 3 Jul 1995 10:50:42 +0200 (MET DST) Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu In-Reply-To: <199507030725.AAA19105@ix3.ix.netcom.com> from "Ron Feigen" at Jul 3, 95 00:25:36 am From: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Organization: Dept. of Computer Science, TU Dresden, Germany X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 834 > 1) I am trying to build lites under FreeBSD 2.0 on an i586. > I am using the i386-mach buildtools from jaguar I used to > cross-compile mach. I configured both --host and --build = i386-mach. This is wrong; try --build=i386-freebsd2.0 . Here's our configure command: (using FreeBSD 2.0.5) /home/hohmuth/src/lites/configure --build=i386-freebsd2.0.5 \ --host=i386-mach --prefix=/usr/local/i386-mach --enable-mach4 (the prefix being the same as Mach4 has been configured with) > 2) I checked leia:foggy for mach_init but the dir is empty. Is > there a FreeBSD mach_init source or binary around? I don't remember where we got our's from, but I guess you can just copy or link FreeBSD's /sbin/init to /mach_servers/mach_init. Michael -- Email: hohmuth@inf.tu-dresden.de WWW: http://www.inf.tu-dresden.de/~mh1/ From lites-readers-request Mon Jul 3 05:36:49 1995 id FAA27817; Mon, 3 Jul 1995 05:35:40 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 3 Jul 1995 14:18:33 +0300 id EAA00877; Mon, 3 Jul 1995 04:17:01 -0700 Date: Mon, 3 Jul 1995 04:17:01 -0700 X-Sender: ronf1@popd.ix.netcom.com X-Mailer: Windows Eudora Version 1.4.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: lites@cs.hut.fi From: ronf1@ix.netcom.com (Ron Feigen) Subject: Almost there but still a few bugs Cc: mach4-request@schirf.cs.utah.edu >I am closer but there are still problems. >When trying to link /usr/lites/obj/server I had two errors >one I could correct the other I could not. > >a) libgcc.a file not found. I did a 'find' and there was only one >libgcc.a. Makerule didn't have libgcc.a in a search path, it just >had libgcc.a at the end of the ld statment (not -lgcc). So I copied >/usr/lib/gcclib.a to /usr/lites/obj/server. That the solved file >not found error. But I find it sort of strange. > >b) crt0.o could not be found either. This was more difficult >as there where 4 ctr0.o files and a gcrt0.o: > >/usr/lib/crt0.o >/usr/lib/gcrt0.o >/usr/local/lib/mach-crt0.o >/mach4/obj/boot/bsd/crt0.o >/mach4/obj/libmach/standalone/mach-crt0.o > >I created a /mach4/mach4/lib so ld could find it there (I checked >makerules for a valid path. I tried each crt0.o and got unresolved >references for each one. > >I had a minor Mach error to: > >a) I can't open my paging file. I followed the (Remy's) docs and my >files look as follows: > >ls -la /usr/paging_file > >---------- 1 root wheel 33554432 Jul 3 3:18 paging_file > >ls -la /mach_servers > >lrwxrwxr-x 1 root wheel 21 Jul 3 3:18 paging_file /dev/wd0f/paging_file > >when I boot I tried /dev/wd0f/paging_file, /dev/wd0a/mach_servers/paging_file >/dev/wd0f/usr/paging_file. nothing worked. So i skipped it. I have 32M but >I am still ging to need to a paging file eventually. Earlier I had created a paging file using a similar scheme (from jvh@cs.hut.fi). i deleted that file and created the new one. Now I can't open it. Thanks in advance, Ron > > > > > From lites-readers-request Mon Jul 3 16:08:19 1995 id QAA06232; Mon, 3 Jul 1995 16:06:21 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Jul 1995 00:47:08 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Tue, 4 Jul 1995 00:45:58 +0300 Date: Tue, 4 Jul 1995 00:45:58 +0300 From: Johannes Helander To: ronf1@ix.netcom.com (Ron Feigen) Cc: lites@cs.hut.fi, mach4-request@schirf.cs.utah.edu Subject: Almost there but still a few bugs In-Reply-To: <199507031117.EAA00877@ix3.ix.netcom.com> References: <199507031117.EAA00877@ix3.ix.netcom.com> Organization: Helsinki University of Technology, CS Lab. Ron Feigen writes: > > >I am closer but there are still problems. > >When trying to link /usr/lites/obj/server I had two errors > >one I could correct the other I could not. > > > >a) libgcc.a file not found. I did a 'find' and there was only one > >libgcc.a. Makerule didn't have libgcc.a in a search path, it just > >had libgcc.a at the end of the ld statment (not -lgcc). So I copied > >/usr/lib/gcclib.a to /usr/lites/obj/server. That the solved file > >not found error. But I find it sort of strange. The libgcc path should come from gcc by running gcc -print-libgcc-name. There is some magic in Makefile.in to figure this out. Also for crt0.o there is some magic to try to find the correct crt0.o from a variety of places. Unfortunately crt0.o has different names on different systems and is in different places. It is important to use the Mach version when linking the server and emulator. Or actually just the server as the emulator has its own (ecrt0.c). One viable solution would have been to include a private crt0.c in the server as well. Unfortunately I did the path searching instead. > >b) crt0.o could not be found either. This was more difficult > >as there where 4 ctr0.o files and a gcrt0.o: > > > >/usr/lib/crt0.o > >/usr/lib/gcrt0.o > >/usr/local/lib/mach-crt0.o > >/mach4/obj/boot/bsd/crt0.o > >/mach4/obj/libmach/standalone/mach-crt0.o The last one sounds like a good bet. Or the other mach-crt0, probably the same. > >I created a /mach4/mach4/lib so ld could find it there (I checked > >makerules for a valid path. I tried each crt0.o and got unresolved > >references for each one. > > > >I had a minor Mach error to: > > > >a) I can't open my paging file. I followed the (Remy's) docs and my > >files look as follows: > > > >ls -la /usr/paging_file > > > >---------- 1 root wheel 33554432 Jul 3 3:18 paging_file > > > >ls -la /mach_servers > > > >lrwxrwxr-x 1 root wheel 21 Jul 3 3:18 paging_file /dev/wd0f/paging_file > > > >when I boot I tried /dev/wd0f/paging_file, /dev/wd0a/mach_servers/paging_file > >/dev/wd0f/usr/paging_file. nothing worked. So i skipped it. I have 32M but Confusingly enough, the pat his not interpreted by unix at all but just the default pager and the Mach device server. So the dev directory is never used even if it looks like that. The path needs to have a Mach device name. In mach wd0 refers to the first WD ethernet card, not an IDE (or whatever) disk. The name used for st506 compatible disks is hd0. You need to do ln -s /dev/hd0f/paging_file /mach_servers/paging_file assuming you created a file paging_file in the root of your /dev/wd0f file system (might be mounted as /usr or whatever). Johannes > >I am still ging to need to a paging file eventually. Earlier I had created > a paging > file using a similar scheme (from jvh@cs.hut.fi). i deleted that file and > created > the new one. Now I can't open it. > > Thanks in advance, > > > Ron > > > > > > > > > > > From lites-readers-request Mon Jul 3 18:42:59 1995 id SAA07897; Mon, 3 Jul 1995 18:42:05 -0600 From: sonoda@flab.fujitsu.co.jp (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Jul 1995 03:24:47 +0300 id JAA04281; Tue, 4 Jul 1995 09:24:38 +0900 id JAA14064; Tue, 4 Jul 1995 09:24:05 +0900 id JAA12706; Tue, 4 Jul 1995 09:24:02 +0900 To: hohmuth@inf.tu-dresden.de (Michael Hohmuth) Cc: ronf1@ix.netcom.com (Ron Feigen), lites@cs.hut.fi, mach4-users@cs.utah.edu Subject: Re: second_syscall.s & mach_init Date: Tue, 04 Jul 1995 09:24:05 +0900 Sender: sonoda@flab.fujitsu.co.jp In message <199507030850.AA25046@irs.inf.tu-dresden.de>you write: >> 1) I am trying to build lites under FreeBSD 2.0 on an i586. >> I am using the i386-mach buildtools from jaguar I used to >> cross-compile mach. I configured both --host and --build = i386-mach. > >This is wrong; try --build=i386-freebsd2.0 . > >Here's our configure command: (using FreeBSD 2.0.5) > > /home/hohmuth/src/lites/configure --build=i386-freebsd2.0.5 \ > --host=i386-mach --prefix=/usr/local/i386-mach --enable-mach4 I have next configure. /usr/home/sonoda/work2/usr/src/lites-1.1/configure \ --prefix=/usr/home/sonoda/work2/usr/local --enable-mach4 I do lites on FreeBSD 2.0.5, and can compile. But, can't work ld.so, so, the command using shared library is wrong. You had better to compile on FreeBSD 2.0. > >(the prefix being the same as Mach4 has been configured with) > >> 2) I checked leia:foggy for mach_init but the dir is empty. Is >> there a FreeBSD mach_init source or binary around? > >I don't remember where we got our's from, but I guess you can just >copy or link FreeBSD's /sbin/init to /mach_servers/mach_init. > >Michael I send you install-note and mach_init uuendcode. following, ----------------------------------- Building and running Mach 4 and Lites on a PC running FreeBSD 2 Remy Card Remy.Card@linux.org 2 March 1995 This note describes the build procedure for Mach 4 and Lites on a PC running FreeBSD 2. It is based upon the Mach 4 and Lites documentation and upon my experience. It is not complete yet: it lacks the description of the CMU USER collection. I have built this collection on FreeBSD 2 but I have to update my notes before including them in this document. To build and run Mach 4 and Lites on top of a FreeBSD 2.x installation, you need: 1. a PC running FreeBSD 2 :-) 2. the Mach4 source distribution, available from jaguar.cs.utah.edu in /flexmach, 3. the Lites source distribution, available from ftp.funet.fi in /pub/mach/lites or mach.cs.cmu.edu in /src/lites, 4. the gnu make binary, available from ftp.FreeBSD.org in /pub/FreeBSD/2.0-RELEASE/packages/make-3.72.1.tgz. 1. Building Mach 4 ------------------ 1.1. Patching the assembler The assembler included in FreeBSD 2 has to be patched in order to assemble some of the Mach 4 source files. The patch (against the file /usr/src/gnu/usr.bin/as/subsegs.c) is: ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- *** subsegs.c.orig Fri Jan 13 12:36:42 1995 --- subsegs.c Thu Jan 5 19:56:40 1995 *************** *** 140,145 **** --- 140,148 ---- if (seg == SEG_DATA) { seg_fix_rootP = &data_fix_root; seg_fix_tailP = &data_fix_tail; + } else if (seg == SEG_BSS) { + seg_fix_rootP = &bss_fix_root; + seg_fix_tailP = &bss_fix_tail; } else { know (seg == SEG_TEXT); seg_fix_rootP = &text_fix_root; *************** *** 171,177 **** { long tmp; /* JF for obstack alignment hacking */ #ifndef MANY_SEGMENTS ! know(seg == SEG_DATA || seg == SEG_TEXT); #endif if (seg != now_seg || subseg != now_subseg) { /* we just changed sub-segments */ --- 174,180 ---- { long tmp; /* JF for obstack alignment hacking */ #ifndef MANY_SEGMENTS ! know(seg == SEG_DATA || seg == SEG_TEXT || seg == SEG_BSS); #endif if (seg != now_seg || subseg != now_subseg) { /* we just changed sub-segments */ ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- Once you have applied this patch in /usr/src/gnu/usr.bin/as, you should rebuild the assembler (make) and install it (make install). Note: if you run FreeBSD current (after 2 March 1995), this patch is not needed: Nate Williams has commited this change to the FreeBSD source tree. 1.2. Extracting Mach 4 You have to retrieve the files mach-UK02p8.tar.gz and mach4-i386-UK02p8.tar.gz from jaguar.cs.utah.edu in /flexmach. Then, create a directory for the source files (e.g. /usr/src/UK02p8) and extract the source files: $ mkdir /usr/src/UK02p8 $ cd /usr/src/UK02p8 $ tar xvfz /.../mach-UK02p8.tar.gz $ tar xvfz mach4-i386-UK02p8.tar.gz You should obtain two subdirectories called `mach4' and `mach4-i386'. 1.3. Patching Mach 4 1.3.1. Building ZMAGIC binaries Mach 4 has to be built as a ZMAGIC executable file. The FreeBSD linker generates QMAGIC binaries by default but the FreeBSD boot blocks are unable to load QMAGIC kernels. The following patch forces the creation of a ZMAGIC binary: ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- *** UK02p8.orig/mach4-i386/boot/bsd/mkbootimage.sh Sun Nov 20 17:57:16 1994 --- UK02p8/mach4-i386/boot/bsd/mkbootimage.sh Fri Jan 13 11:54:45 1995 *************** *** 23,29 **** esac done ! $ld -nostdlib -o $outfile -Ttext 100000 \ $machbootdir/bootimage_head.o $files $machbootdir/bootimage_tail.o \ || exit 1 --- 23,29 ---- esac done ! $ld -Z -nostdlib -o $outfile -Ttext 100000 \ $machbootdir/bootimage_head.o $files $machbootdir/bootimage_tail.o \ || exit 1 ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- 1.3.2. Making the bootstrap understand 4.4BSD filesystems Mach 4 has been modified to understand 4.4BSD filesystems. Unfortunately, the change contains an error :-( You have to apply the following patch: ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- *** UK02p8/mach4/bootstrap/fs.h.orig Thu Mar 2 18:10:54 1995 --- UK02p8/mach4/bootstrap/fs.h Thu Mar 2 18:11:50 1995 *************** *** 226,231 **** --- 226,232 ---- quad fs_maxfilesize; /* maximum representable file size */ quad fs_qbmask; /* ~fs_bmask - for use with quad size */ quad fs_qfmask; /* ~fs_fmask - for use with quad size */ + long fs_state; /* validate fs_clean field */ int fs_postblformat; /* format of positional layout tables */ int fs_nrpos; /* number of rotaional positions */ int fs_postbloff; /* (short) rotation block list head */ ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- 1.4. Configuring and building Mach 4 To configure Mach 4, first create a directory to contain the object files (e.g. /usr/obj/UK02p8) and run the configure script, e.g: $ mkdir /usr/obj/UK02p8 $ cd /usr/obj/UK02p8 $ /usr/src/UK02p8/mach4-i386/configure --with-mach4=/usr/src/UK02p8/mach4 The configure script accepts additional options as well: --enable-debug Turns on various kernel debugging features, such as extensive sanity checks and (on the i386) the kernel debugger. --enable-libmach Enables generation of the CMU UX server-specific library libmach.a. Generally only needed in order to compile programs in the CMU USER distribution. Other Mach servers, such as those in Lites and the Hurd, only use the (more) personality-neutral standalone library libmach_sa.a. --prefix= Specifies the installation area. This defaults to /usr/local. Please note that the libmach library does not compile on FreeBSD 2 because of a conflict between Mach and FreeBSD include files. The following patch (a quick hack) fixes the problem: ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- *** /usr/include/machine/types.h.orig Thu Mar 2 22:16:39 1995 --- /usr/include/machine/types.h Thu Mar 2 22:17:00 1995 *************** *** 47,54 **** --- 47,56 ---- } label_t; #endif + #ifndef MACH typedef unsigned long vm_offset_t; typedef unsigned long vm_size_t; + #endif /* * Basic integral types. Omit the typedef if ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- There is no `config' program for Mach 4. The version which used to be contained in the CMU distribution of Mach 3 has been removed from the Mach 4 distribution. To adapt Mach to your hardware, you have to do config's job by hand :-( You can do this by editing the header files contained in the directories mach4/kernel/bogus and mach4-i386/kernel/bogus. Once you have configured Mach 4, compiling it is very easy: just type: $ gmake -r To install it, type: $ gmake -r install This will install the Mach 4 include files (in /include), libraries (in /lib), binaries (in /bin) and the micro kernel (in /lib/mach-boot). 2. Building Lites ----------------- 2.1. Extracting Lites The Lites source distributions can be retrieved on ftp.funet.fi in /pub/mach/lites and mach.cs.cmu.edu in /src/lites. Once you have retrieved it, create a directory for the source (e.g. /usr/src/lites-1.0) and extract the source distribution: $ cd /usr/src $ tar xvfz /.../lites-1.0.tar.gz 2.2. Patching Lites There is a (very) small bug in the Lites 1.0 distribution: the version number has not been updated and is still 0.8. To fix it, apply the following patch: ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- *** lites-1.0/Makefile-version.orig Thu Mar 2 18:03:26 1995 --- lites-1.0/Makefile-version Thu Mar 2 18:03:42 1995 *************** *** 1 **** ! VERSION = Lites.0.8 --- 1 ---- ! VERSION = Lites.1.0 ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- CUT HERE ---- Of course, this patch is not necessary to build and run Lites but I find it useful :-) 2.3. Configuring and building Lites To build Lites, first create a directory for the object files (e.g. /usr/obj/lites-1.0) and run the configure script: $ mkdir /usr/obj/lites-1.0 $ cd /usr/obj/lites-1.0 $ /usr/src/lites-1.0/configure The configure script accepts several options: --build=BBB Specifies the machine you are building on. --host=TTT Specifies the target (this is confusing. It ought to be --target). --prefix=III Specifies the install area. --srcdir=SSS Specifies where the source is. --with-release=RRR Secifies a Mach release tree (sup one from CMU for example). Libraries and includes not found in the prefix directory are searched from here. --enable-debug Adds +DEBUG to the configuration --enable-profiling Adds -DGPROF and -pg and uses libmach_sa_p.a etc. --enable-mach4 Uses the Mach 4 distribution. --with-config=CCC Sets the server configuration. See conf/MASTER.h and other MASTER files. The default is STD+WS. When building Lites on FreeBSD with Mach 4, only the `--enable-mach4' is really needed. If you use the `--prefix' option, its value must match the value used when running the Mach 4 configure script. To compile Lites, just type: $ gmake To install Lites include files (in /include) and the Lites emulator and server (in /sbin), type: $ gmake install 3. Booting Mach 4 and Lites --------------------------- 3.1. Preparing for booting Copy the mach bootable image (/lib/mach-boot/Mach.all) to the root directory, e.g. /mach. Create a /mach_servers directory and copy the Lites startup and emulator into it from /sbin. If you intend to build and run Mach programs which rely on Mach name service, you should also copy the mach_init binary into /mach_servers. mach_init is part of the CMU USER collection. Since compiling this collection on FreeBSD is not very easy, an uuencoded binary of mach_init is enclosed at the end of this note. If you don't intend to use Mach programs, you can simply create a symbolic link to /sbin/init, i.e: # ln -s /sbin/init /mach_servers/mach_init Create a paging file on a partition which has some free space. For example, if you have lots of space on /usr and /usr is located an /dev/hd0e, you can create a 32 MB swap file by typing: # dd if=/dev/zero of=/usr/paging_file bs=1024k count=32 # ln -s /dev/hd0e/paging_file /mach_servers # chmod 0 /usr/paging_file Note that Lites does not use the FreeBSD swap partition. Thus it is possible to use it for swapping by typing: # ln -s /dev/hd0b /mach_servers/paging_file Create devices for mapped time (semioptional): # cd /dev # mknod time c 25 0 # mknod timezone c 26 0 Create devices for Mach version of XFree (optional but for that X server): # cd /dev # mknod iopl c 22 0 # mknod kbd c 23 0 # mknod mouse c 24 0 Change network interface name to what the Mach kernel thinks: # mv /etc/hostname.ed0 /etc/hostname.wd0 OR copy the file to both names. This way both Lites and FreeBSD will boot ok. but you will see some error messages. There isn't VT support in Lites yet so you need to run getty on the console. The easiest way to do this is to copy the file /etc/ttys to two files /etc/ttys.bsd and /etc/ttys.lites and to switch the files at boot time: # cd /etc # cp ttys ttys.bsd # cp ttys ttys.lites # vi ttys.lites ... edit the file to remove every getty on vt and to add a getty on console ... # vi /etc/rc ... add the following lines after the line `mount -a -t nonfs': if [ `uname -s` == FreeBSD ]; then cp /etc/ttys.bsd /etc/ttys else cp /etc/ttys.lites /etc/ttys fi 3.2. Booting Mach and Lites Once you have installed Mach and Lites, you can reboot your PC. At the boot prompt, type the name of the Mach boot image, e.g: >> FreeBSD BOOT @ 0x####: ####/#### k of memory Use hd(1,a)/kernel to boot sd0 when wd0 is also installed. Usage: [[[wd(0,a)]/kernel][-s][-r][-a][-c][-d][-b][-v]] Use ? for file list or simply press Return for defaults Boot: /mach This should start Mach. Mach will first probe for devices on your PC, the start the Lites server. Lites will boot and you will get a login prompt. Under Lites, most of the FreeBSD binaries will work. Some will fail though: swapon, savecore, getty on VTs, procfs_mount. Some other binaries have to be replaced by the Lites versions (compiled from the CMU USER collection): ps, top, w. 4. Compiling Mach programs -------------------------- 4.1. Compiling Mach programs running on top of Lites You can compile Mach programs to run them on top of Lites. Suppose that you have a simple Mach program, called test.c. If you have installed Mach in /usr/mach, you can compile it by using the following Makefile: # # Makefile for a very simple Mach program # test: test.o ld -Bstatic -e __start -o test /usr/mach/lib/mach_crt0.o \ test.o -L/usr/mach/lib -lmach -lgcc -lc -lgcc test.o: test.c cc -c -I/usr/mach/include test.c Note that Mach binaries have to be statically linked. The FreeBSD shared library implementation depends on using the FreeBSD crt0.o. Since Mach programs have to be linked with the Mach crt0.o, you have to use the ld's `-Bstatic' option because the Mach crt0.o does not support dynamic linking. 4.2. Compiling standalone Mach programs Should you wish to write a new Mach based operating system, you have to build Mach standalone program. A mach standalone program is started directly by Mach at boot time and does not use any Unix services. If you want to test a very simple Mach standalone program, get my test server from jaguar.cs.utah.edu in /flexmach/test-server.tar.gz. The makefile will not work on FreeBSD (it was written on a Linux system) but it can be replaced by this one: # # Makefile for a very simple Mach server # startup: main.o ld -Bstatic -e __start -o startup /usr/mach/lib/mach_crt0.o \ main.o -L/usr/mach/lib -lmach_sa -lgcc main.o: main.c cc -c -nostdinc -I/usr/mach/include main.c Once you have compiled and linked the server, save the Lites startup file (mv /mach_servers/startup /mach_servers/startup.lites), copy the startup binary to /mach_servers and reboot Mach. You will get a very exciting kind of operating system :-) 5. Compiling programs from the CMU USER collection -------------------------------------------------- This section is not written yet. I'll try to write it soon. Annex A: Uuencoded binary of mach_init -------------------------------------- begin 644 mach_init.gz M'XL("'L?5B\" VUA8VA?:6YI= "T? ]?_MS-V=U^[E[W;W>N[9+ MI8:"#I85F6[<]!9;5J]"&VVD5)-SG^><\_Z9=P:5I6T_RYQSWO/O><[W^7M. M<5MUH[@T'<>E(=+5 MIF]N=5X1BOR9M]9#S<^/3\[6<:ZL!;-A2L=(+_X&.EU9-;.P'NO%WT!GN!LMC"2U MGA&!*-+:8-#%_>15X)2[7N\1)FR9SL4U/0]5SW.1^D-Q1UI= _?&;6N"AD!R M\X4QT-Y[$\.<8% MP!%?(/[B=0ZXI3\JQO6,]GB\ZQ;KN.?F>*8=%4>ZNG5[9@ D>]9Z/.''+I;& M&C5C]3@V'<<^,-C8"=<+,\2 7"[ \6KQO M/ &(*PMWR#FBQ)=QEM_]$/[4P/#FUKBF?A@J?@ M=FXYE!I/XJR5,\1%)W#7 M!F\:C 2 Q51RXL]/$D(*Q51:D*:-M7>"&(J7:2L%ZMS;8!?<,BC-O WW8'#- MY!PC?",_AIX!9_Q"^R4<\N0)5OL*:R5DR4175@:9=JP]@*TCH6P37R*3&V 7 M[T[2<94ZL1-_(L23^,-5CK!G (A%X12*BKC@!/G))_.9R0)6_.P'2?*FX&'5 M>\3;D0L%4SD.Z)F*2UR.($LH5,W#,69*565A?IFRNOH)2<]2/#C6NK*RL>!<8[Y:CB4'V/.T:X(FF43NR"!Z7JTGM4T3@'H.R+RF8;:\&>N/V@?U"/ MDJNS%Q5[:A8M=Z<99Z\+M7LK'*$ M-D^)"9ZH;MGJZNHGG34X#Y=;[3!/=II)NWE5;?4:,_W(!E55FVNKH7%5=:VY MT%I0/-=B758X[]$%,V?.U.RNK#QX?T0'EU;]$%0Z:S?7E=>NK5A97FX_@=Y-]IWI0OGK0 M&3YDT'>'R2!)T&X)3,/A@6FXLGT&]!'__3B9P6T=L+FM?MM"\;T\U92-JBDK MZ)2_IU,*UH$]76C^V-2C;787SO?X<2;:^#&B/H$-_C4=O(8,-DX]ESD>OZ^= M*UC]KAD[.YN??;1[DB;&),,IOT\,>WH.$F;/4^7:#T4M-FXK44P MQ=3+'K>UWR:?P.O;)7:-MXD%N,]"-LM5.LO39);$2N!8O\W&1D41ZN(I=4DJ MZB;?3 99#P6=VYB L[_0;H5OXK=M[+SZ;)4)]#A!*5NA YMZ50-V2 )R1K@: M^CAS M"DS##N!8+A1_;)68+!U1,UU_/%G?*,324W43EQ-]44K$A.TJ++^X5=G^/CK\ M_9>I3/F1_$@VZ.OG5(.V; V1J=_108%I?EF4V,BWGE:-S%&-?)4N5QT\PO) >AJ;Z6'U3,>:0V;J>8DB2SZ!^A9?5%\% MM3GN\@O$9LIJ;$W=$\M0BH5MN:1%9K M> DM;$'YRG)PNLO,3.6F,FV^SBP[X3 OZ,02@^ T2J ?&Z@S!>J,]K.X@OXH M/6B+,3,*,>*,*2X4;P-H]=SCR8S",W 8,J.0HTXC?+G[&?B2 /Y:H?@ <-.7 MD_06P*R%TCCP^%)*8EGU,D(EM8R2T5I=[BB7]B18V:R.FR0M.)X0MK<%+'04 M\1_"S(1L*UVYLKR&S!1VGC_1>99<^G\"X7.Y;BF9X%3 MKJN!N*;-4"!LVT8T*, JUHZ*5BP<0YRUJ:)4N07JZ-B7K..:Z8;>+!"603#Y--Q),>OCF)1(M0L!4S MA%?4JQ#>_4P(PJ/_PE2;/TA#2L-SUC'%AL.]SX2HM-?^3$6ME5+LRB(V1"+; M1LEV-?@Y1SK\#3BF*.HFL%6R6;> _#\38K.J8>JIK3WW 2Y=;8FS&>>V=0 T MM"VLXR;+JJI7E4DP< M.L\3=)Y]+R(9)]M"T5A6(<-0[065@:^UJDYR@9BL,R 2T8TEV[H(<1('O F+ MMX]&4[Q)&O V:C.FMGH\F>D1#J.K559HG\NP*RRV[S>C?J*6O/)JI5Z"076U MR@+_*K( MY6_0_J+HQ37_&Q]Z@&L8)9T C0X+;X+/H4],KWPBC>8A9*_"?;QEQS?OUD M]?QC8'XV]RU7R=QD"BY"FB/?(!09X_Y\"W^K;[8>1)L39AGXV0;?;.*(^F83 MMU1XS.1J*^,7F[QY,#L_.U&898JJP9S00$3]:*@(^N;X!TAV9K1O=M+;1&'W M&&'M@OF!3@(ANBS3FT*V,CP:QMJR,91'G0G?O679-+"G??=(5:P7\MVCHLZ@ M+[SH.]<&,^>@I""2@20HD#D&+SX*9./A));18S+PES6=))_19 M,NC/#"YHC]IU''=5!BJY0)V933N_$A8*P+IRR\Q*G,:LFH;,4SE//#X.\UAP MD'0EZN=;$NF/F?XDT9]DXORWZYG0.4C""S"'!?%GMP$.:J#$6PS\>"P@./$3 MWT66Q/7$;0!:6"W*SM(D]NW9JG@X:S,RR(MM,HO^[V:,_SRE.HYP*6I'*8L$ ML=>>G5#S1>TJE>+$W7)IKUQ:Q]8J%#^[A9$O^:LR'VLH'V^NY-C_$BMU;DN* M[:(.4\',IED2@5RCVY)H$_?<2C@A6)+VZ1RWP$_R50 O4&Q))'TO=A-CJ#1L MBWHVF^DH+(@K;F6>""C=.UQ96TB*:@0_'@O>C+&!3Z3# E%-\%?(2=JG=XQS;0+XQ>,1X')D"SV/>EQ9V(7;--V5Y2$J M]]Y +!8"L4WLP+"WF@EVY+RH?YJIVIY1'JF7;"4E_S015;3!@R,#T\BY)D(Y MPFT5;6+;>N*VA67%PELH+PE1S>> G9%[-K)DJB^*D S_-)]SWA*(\LAT2MOH M^:G'XPFB4WU.WR:2N1F$U<>Q2]H#%L1W6+\1E,\[&9^G[6!\Q@8^C9^V4UXD MARZ2 XO\@@[&3>!DV.:VF&SN')--O/,6U,+=:C[I"\-NP9;(V+"#LB$!V+!# M9L-.Q@9I$6!'JICI1VE"\5F.ZX++S(1F[T8 NM7/6[*]RXE(SD$A' @Z*S7V M 2R.23!U3B(YO;5FU=$9P..^>)B(@090Y(2'M7!ST%G&-:&_,LAYQC4U M8W00!+T0WC[ )LQ!JV.B6]05BM.!\HLI9%.PIPB."SUZ[N:0HP\Z&0]\O_@Q M]5DIL*1-B$5HB]I"]O+'<:J]U S.A*VT'Q6M8,JD,X^A9[YDG((V$'XL>'

    MC&;ZO:BW,Z.PMNG^ -'BN,75P>B[*1<4^Y+[\<;"7RBV))"" M:)@+ZB.5RBH.@(.)((Y6H3@5G2P\&(CWQ]&FQ=_ [M28);ZT06@PJFP?3!$E MLV0$;#NZ6(RF6V8:-]$81)$ T[H_BB@9XHU!GQ?)&_YS5R3I%" MT0#TNP/&6@?(6+H:M,7BAEX< ">IW= #Y]0OG5.QUCF):SXM[TPC*"5LA].( M>@#??C=JBQ'AM 5\="&=08;0P SAR" [&')\EV^2- $[\?"JYBW6+4TRRK:F,J=15C2\3NQOIF7J:[1BOL2?"$=PL+#6 G8@7(OD< SF='"/;^8B> M D_S:6>2:E8#SHIWH-*\(6QZ:XRD2$:([W[-\FUDN;AF"T;.02!7TZQ@VH*; MRPZ"X;HQ#(8&"=]TLQ9ILY9X-7'Z[HIJ?Z0-A4W+ MF1)PPM]$<8Z\1L"1D/F!8TR@WA2HCP_4Z\7C&%2%84I1'&%*YM+DN*;#.%]1 M2F9A8MSVWY*R\?(QG6,NV4K :0XXDXB/XHSG.Y._LR%5JZI93C"N^1W%0BK3 M7Z:)#MBL3IY\8W:H_--NK@T@+9$@M@($,F I#&1E$!A?3AZ*D_@*(+1G@@HC A::_,D:4P0'J#7VCF!M5*OQR9A_+4Z6XK$[*Q$XD2:OAOG$1(S M^QS1-O&4@:6C0 !Z^&G8A;KC/K)?)9:CI2UR::-<:I)+S[)2<'SY/S6A\67F M4\&QI$>>8Z=LY>5B)<=)9[Y/!!0 MR2O5<5-/N[+\Q,>:QLZ(F\7.#POB?4:FZ/Q4T8T4(O;XF?=%>IYV1E?:Q8$1 MJ.+X=X_HH_Y1?G"?E&_J%YB@(+TMG24C%TJ0Y0DUX_ MP(WG^YM/TD2AH-MS0'8F#DH' 3(8UX2I422M@SRQ:V5/6X6M-LXJ3?<.RVV204^0.U\X39>8%.Z,C/LN&((C_=X&P3[&XT MW^EJ!=(^N2)-=WE6JM[Q UAUELFU'B+_T3@M]&BA!*";7(IYL?L14T7^+0^E M1D#GV2;7TZ0SG4X8D*9SK3>S.4#+[?Z*-A<9?+/UBC,HL8J1MICN)1"+QW+Q M%'DX=8'1WHT='J/3D-[V3FS9W$^\O(O/0V?8%V(G[-2!RXP(8FKN^(Z: 8/D MLAV4QW9G\G+-+S=3;7AN5X 52W7%P3B:[; M M+R;10&IBGX-\49VRB>B22V?D4K=<$N72!;DT MP$IB-)#G$8A0@5,W0X@,H_#@PR38GXXPHN_$*N'KSUA7K=/QYV?BDY1HJ\%8$G[1PYM;7'B?BX)J9,JXA=T4]I*>YD_KP<431"L_LR!M1'\ +JFH(OG9 M%3J.YG;U;^! U[&!N8W?8*FAA])]0_TT^*, &0<.Y"S9;62EDVVT%6M>;.1G MQZN_4CEW99&1CMM50;Y XEZS>!X=&TL\NO,>,@/*H7@"6O9M*ITA4 MBYE8HO4U+ MPJLB5WMR\SGG/:Z&"YSC9O@;P/=M%UB75\KI7>8YY^A,I[\^FA^89.W/''", M(*+B$9S^2.< +%O/H_DZH\**J]> L67Y@!=UP15,_=W1AG>M6!6R\*_'PY?X M^1.Z /_EC[ZMC"PN%%,#)* $+G^,FB'?P(]!5W>JN[Q7\G-9GDPB1?Q9@-DQ MY [G- KY W>!^T:815DVEX]%AD$HL()ROU!,)ZI02"!;>^^.SKNL_KO(QE2O MU6J =,R]EI$[MGYUKM6+,X$PN4O\'@_>CN RA6S<0)GTE"%62, /NB)_SWO$ M_XLD=3X!A^-"(&:WXGL[DA5E9VW+CK3-X6%'1NEMM+1M6D?B/4(DL&B4DI89 MRY)7VW7T&?8'Z&\.IJ_SF+Y>FAVY=(Z[X9#/VC(&U9:UQ;800BNG4?R#$35S M/%_4B__2RGWPASI]?,F SWJ& '@,ZUHY&J/9_8J.!/[ N;"5<;_%"X$LW@SS M@:\@F$&L(Y8M?;RD3?T-/A29A/)XVV&6H(D0UW\<"%#YCG==2E(NB#$/[9MM M(FD*P,=#B0B0,6R]%HC% K_$TD@.6UK^KJE_JJE_HJE_K*E?T-0_TM2/:^KM MFGJ;IGY 4_\/3?V/FOH?-/7]FOJ_:^J_U]1_IZGOT]3_OZ;^@J;^6TU]KZ:^ M1U/_C:;NU=1;-?57-?4CFOHA3?T53?UE3?TE3;U%4_^+IOYG3?U%3?V@IOZ! MIOZ^IOZNIGY64S^CJ9_2U%_7U"]KZE]IZOV:^I>:>J^FWJ.I7]+43P;7.;,N M'M]NL#<@KMX4XI(9W"OH?';B&PNWCDJ4&\4M\$2/=$>++;C:ET]#5C&N+MQDVDZ# !; MMLF4ZXQNP9BX9YG'T_(.%HH]0K%>&'%4O#U=Y_HFQ:G'K(/K&[,S PKIKDU) MG&.*D(,/6X XYR32$"7D)/6,%W+,F5$&;(T5!T9PA*?ES%5, )V2 M;%^$Q"MBEZT&M[.;O^*S=B.#>*LH/GL%N=/KL_91[O1WR=S!:UK@SJK%"G?F M#I$[L@T)E[Q7"G[E8WGF%\&=&"'_NDO@ST>-ZD-L(W_1FYQC" MB/0\O,Q$%LBTGE'3*M.;P>@MZ> _\%D[*+V=XL[+2.\9@ BE]_Q_R_1F(+V% MXMK'./R7NX#>RX[\QJN,WJN,WJN,WJN,WJN,WJL*O>LOJ^@]B.OU7=R#-S2$ M?J@W;C!E(1WDM]^[COP.\. #H;7NA&/8@EFOHBYQ]%=X$N1"L7?A<.1RK5'\O)_*)113OV*X@[(9RHV;30]2W&T.C[N9B+O-!'>Y MP.B-#Q'Z$PA:B=%")^.Q\&-HQ7]-"4 MYW(F,7!M2AZ#X(JAX$H@=X&I!(!"3@I34 K3)%EEO&OL30&X$?89W2^>!\>) MOP+^ZCQ@R\_[L=8\ '^]G=C0[/\ MET7.85(6.8:D+'(*"5GD$$9GD3,8F46.( :Y_ RLTF/ 4BN4!#+1Q;]+9["? M)+CT< SX[[PXDL@QQ%#1/XFV#L_AXJM$"2$S@# M+'!2TS *3N#B=JHWP!Y,!A+$#[, J8>W$QD^P W\?&)6[X3OH!R%:^G=H M2,?G@SK"3/Q]+6^@7/SV%!!.3OEZML?XA<;V=&MMSZ7"8=J>S_I4_R'A^?SG$IZM(7A^0\9SV_7QO/?18#Q[AHCG ME6H\YYLR=;7):CP/?!8"4X#T%$]83+_^V0UA&K9DDL\Y63GGP^2)YK1Y&)+UY%:MWHP)G<260GA; 1FSCK,Q(ZKQ*LIBT7XE8U MKIK(]:V*SIGH:DOVC9!4VR,&\>1GL$:.T9=#H9!C^E""PEICI;D09>@%VW!D M",SE[SZ39 @J%SY3[&C79\2.Y@S%CFZ?K[6CO^T,YNUU9*B[0,/;"P7_C$WP M]&IDZ*.P,E3QZ+!DJ*I7DJ']O:$V86>O)$.YP[,)8L&_U"8[] BO' PXY0QWCM@]@>%A>7 M8*86_"X:'2<62]&Q-ZE8X5T7Y5VWN.6B)DK^5&6+4Y!W2^<-DW>E%U6\VW51 ML<6>BX1W#P_%%IN+0VSQ*2T_0C"6(<(\41-+BBJ>9:#ZN//A8>K>NT65[K6+ MBNY=(A+=.V\HNC=C84@,\L644B52.+(8KP[ M/]5(Y$5MC&=X:)@QWJA/Y1@O[U.%/S,^)?S)'PI_[(NN'>.%U5>8?D)]M?$Q MBAM@S);'J*J"F">_7Z6?DC[1<..2*@XD,O9-WC#CP.\^5LE8QB?!<6#*)T3. M'OD>XL"FQZX1!T9SAM XT,3BP,30.!#S##CFFGF&,XO5V.M:3/,,YQ?3/$/W MXD'S#"]&'QC6%P4#YQ2]1\ MTB^19=2P)+R,;OU(PY]>+7_*Y[M+=O,?>,TER)L6(=\(P9?UD,^ZF\ALT3[1_B%R9[_/>H!R MY^!G,G>68_:X4,RQ#C-?./=#EWJ?"&G4_*% M%[^D/J(J9[B#KG U)7%S3$?8Z."H9"(]K_@_VP1$M M6)(NOH"3D3QB"OGZ,]*9YA(%2TIF5"HT.S<)EE0I>Y@9E89-3Y*$(@JZ)2,S M*AV;%@F6&43F!4LV&"!LL@J6.4)^$C;E94;-P*9[!SO)KJWX)IW =0_S',- M+*+^X8-$P680C9NT#%APM^(?_I#YAV9L3\#7&2>2_2_%DC>9P"!\B\]XM$OB M$>K9L=I\;AA?,7LY5:YSEE/EFK><:HXB/Y\_0'W&+>@SSOM XS-^H?49[YP] M3'[>_8&*G_8/%)]QR0>$GT5#\1GG+;^VSWBM'.[R]S5:\A_:'.Z#LX9INV>] MKZ)UX_O!MGOU^X3>XN_!=B\I_1YSN&%MM\K/=B:"D^WUK%"[V#M(3?3N)+^] MWETK)"/%E_1Y=Z^@:'/ZT=OFF!WO9%?]BK-]F1T ^5]&I6ZA>&@FWOX?"HHS M*<:#(>Y-72D'0VDKU<$0>570#:=+UY!P?46]5$JEKEB<3Y;JI(^*)/O"W<#] M4^)Y3;)1RM!=VO M=TWG-MI= QE4#RTEQF$1L1@[@6'.?-(P$F^<\!JJ=\ D,\:Z)K>Z7]%%1MWCH M/8T^^EI[T_O+K.'&_^^IX__W%/U^ZCTBGR7?PUUO;UFXN]Z^,OFNUWB-NUXM M%A,D'N:I95(H,I/PM\5K7D5P223SC#>9U+KX_//>%%+LYDL@)%Y%0QLGA,2K M6!8F"84G?16+BEMD.6WU6=LI]SOHSZEOU<*3AW)JFJ&\TM'Z:#>RYS-!>^Y2 M]GQ>V7.WLN<+07L6;V3/_I ]+Y\>NF>2H\R0)?[("_OF8L$Z%O MQG2]:.["A&47^82I3+)04OI- :D_'M".Q)?]X0,'I8T/$Z1CA,.X 0?GY MNX"[.(_@)@U/&<4?=!&K\AW+#\H=1W=)F4C\%R4<$PB C=31["2=J9_9KLY% MKG!]O+HRM6:GGE,LD/S<7PQWE%GCJF=X,Y)/_IA1($-$XZW_A5Q'O$M* ^6COFR"FW"/X8F_+_ MVTD'@[* M]\\_2_\39N ]/Y+B:DL-2O)?.*M)\E\-2?(?S5 DS=$P!A)W'J6)LNQS/U5 MB='ZSY(8;<60\B@5(3G^CN#\;U2PC71VH*\EV\C^,QH;&0BVD<7BZ?N'JD9H7YZ>V5X/[VC4NVG1X7QT\/DX@R43W.('J2Y MID-H I]$1IV!Z!V"&,*U_';QR#O(M0[07I1KG>B54:[-H=9OUX^'^<[I^7?D M=T[GWU%XUOD.X5G9C?%L3BC/>I\,S[.^)RG/X@G/#&%X=B!(AJ^3 T]:([M] MYC5AB=6^GAM9H M+:W/W#=,6IL[5;2V=BJT'NPDM*X9"JV)U==_9Q#^#:2^)OP;R-^\I4%VC$'C M&6^Y=YBZP?66K!M:WU)TP\&W"/U5WX-?;*@)YQ<;:V[H#>38Z^B&C*=DW3#C MJ6#=0'(=R]_4<'"45C<\.'68&)KUICK^?U/!4,V;A(?50\%0]E/7OQ\C/DZ: MXN.\2'R<%_$^WIM7&^SG^(@;2R#58.#)2P=QWAOHTW:3KQ=DGU:$DE%BCAU= M*(JP"6G#\6G=GT-ZM,>[F2^:\$;Q*=E_ZT=I>,#;T@^;4V(3]NB\FGW MJWW:AUW?W$5]VED$:--IXJB6O+*4[=-&CX?F3(CSFBPYKRFR\YJJW*W;<.X4 MV7=-E7W7I:^C4YH2Y+NFAOJN]ZNZ,=^U7>.[!NL"*XV3);MF[1;WOJ[!;JQ* M^JG^FS)<_?>Z6O^]KI+_UPEVG_H>Y-_D""?_B8X;BHNO91^:7M/8A]%:^[#B M[F'RI_PU%7]VOZ;(]H[7"']JAR+;&'0NNA#D*K8RBTQM?? MT-OV076VO_[Z.GNG;S"=/2:,SJZ\\WO1V4_X-#K[U[[P.GNK3]+9SN'J;&[= MOT!G__[X#>ELU_'KZNP;S3=TK-?D&TZME_,-G>OE?,.9]4/+-_RM_1KY!L=Q M3;[A)H,VWS _99CYA@7'E7R#Y[B2;V@Z3O(-:X>2;^A:?[U\PV#^>6V*[LUN(SQ<-Q3=6[-Q>/[RNH;K MZ]ZD8X/IWH0PNO?OR=^+[NTYJM&]$X^%U[TQQR3=NWZXNG=CP[] ]TYIO2'= M.[+UNKKW>F\EYVR6L9VW.4R>:$&K!MOCM-B^=](PL3VM587MFE8%VV6M!-M/ M#^G>>_/UL7W--T4+MJC?%"W:(K\I6K(E_)NB>U_5W);?;-"\*8J?.,PW16-? ME=\4V5Y5[,><5XG]V# 4^[%\RXV]*>)4>I$;Y)T1X9^=\,\DE"2Z&W8"_QR- MY $*>\M\T+NND3XWPK?,A[P;2:V5SV_W;B'%#K[DE+>ID5UR)>$EU[.DUD7N MP,Y[MS>RZ_1DO$[W-++32<'3V='(;KM2$;\[26U *$KCB^",=LKOXG:+/SF, M9[379]U'SVC_CU0VSHYGM-H\S#.J/BR?T?[#[*TTE' MD_JM]&;R5AH/;%2N]F>B77/I6.A=LV^Y&8MMR0]]*;[_V.TXGDW^*>.\< ME_R6,\\E@WV>2PUV?"K@[/)9SU/N24"_TZ"Z.4S#F\,?W(XWAS*@M'GJ<.NW M*^MW*.N?NI'U[PI9_X4)ZO65F$FZ42CI]LYIDA[X8/2$,^>+H-;HE%+PE*J> MV8S_F>1Y$_"1_WFU3QOT%H0;["XW"6]Q=S6I;W%WDUJ7=R_Y/>_=UT2OCZQNE@U$3?,-O!^98M"^'QDS7O5^).3>.QPFNIIE3)QOEC'1 MW1R,B2WA,'%/"";^3Y(6$X/JL@R5+<#7\HNVJI_R+-DJOY9?OE5^+5^VE1U# M(NH[?_"K^7$O:6[W[E/I'?)JOO^V8>J=*RVRWDE_2=$[*2\1O?-O_[3>L6\- MKW=6;Y7U3F*PWCFD>GNGR%ZV]#:H%=\&M=)\18?H_PMRYM3_LO8T4%)5Y\W" M@(,9G471H-V6UY2>L%6"-)Y63H(08 DT0;<0%FTE\G;FSO'(-^!+ZWD<- _D--"!VX' MRLSQGT^_;M-\>M;LBKY_F9I /Y"<#W*.EI*09-/\K[J/JU]-'E>/4+_7.D>]U")P0^G5+G#-#345'2\3]4 _CO$W[.$^N+\[%>9G+1AGG=>[S MXKS']_G/"SVPC_AQOXF?Z_-"4E'\O-#4HO>\4&.0%SV?#VF5.(,/O&B3I^*^ MO4G@ [>^R%%N?9SS@;\R>90^\,P7&5[-ONC[P*M>)+3[;7P$/G#KIOH^\)GH M<4/)H\=-)0$]YN[EZ%'@Z?$77QPE/?YR+T./F_;Z]&C=2^CQP4CHL:ITYI@@ M(92ES&:Q+%V[AZ/ !EZ6FBX=I2Q-V>/)TDU[?%EJW4/F7SEG6/?-_9KG_;E?^3R9 M^XXZ3F=D9JB-[X[46CU!O'GF7T MQM3G?+F9_!RAR?%SEINM6\1R<^\63VXFG4%NZN8=WAQ@\PYO#7AN[]L#XKS# MR\]P>8>-<2[O<._$4?J6]S_C^99'GO'S#F\^0WS+$_&1Y*T':N<=$F?YLZ %>/<&;![&T9\\]/$U[ZG_BYG@$[>:?X#-BI M.\_Z#%CB+')[TEV>'9]ZET >>W9S\KB)M^-MB5'*XXV[&7GWXV=#CJJT>/:[>*J!'YBF.'B6>'@LO'"4]%C_%/O_VE$^/GJ<( M/7X_$GI#:U2>X#W2DLOI)3I]LCOM/_1!Y6G2!/_MO MG8L\?>M)3YXV/AE\YJ?G23+_D_'1/_.SX.XZS_PD1,_\-#K/_$P*/O-S-K'# MAGL\GMIXCX"G)CW!\529YZF/OC!*GOK3XPQ/7?6$SU-3GR T_<-(>&KS/6OG4;36HM/[K]WFV4XU:>V/[ -N>!EDEHVA[>1G,G M$. N&2ZU-!4.G-RTI&GCDJ'"T+BN"4XJY?AX\C*3=<[+3%Y[C'N9R1UQ[V4F M;E+EH?-]DBX<(4G)NTP>>/;O/U* M*;A?^0J[!M4P3S:"]U%> \+'R6TQ?WO1WV?HN=1XE/\<20^ MA71?R*L(N3W0'>7_V[V"B?@YRUBY%=:Q?1 MB3M=G9C:1?CM5)R\/_$V/T>UGGU_8@_Z&J5+#WXX9=U'#>BZ)M#=6-1_V%I M^.M:PG"+8([V5TE!#!ENWH"[3]EH-VU:*$5/?GU<=[3_L)W -^E$JM7$[(C4 MX+T_\6+"E* ?$_NZ))37F:@H'6K[M)[ YK\IK?<#K7??3]+?Q>5O8YZ:^&\' M*I_N0.K^V,]2W^E1=Q&U-T?&C])_>W>'9V\F[_3E.+Z3T/5/9^>_+0K[;\_= M+_;?]M[/^F\3!/[;[I'X*^\]X+'HT0<$M@7?^1O@SW_E;0^CW1R?:XPC4P!K?2!5 G'Z^L M8BK4G_M5#]7HL[?O_^&N:.LA]Z[HPH$#A:&8=U,T?6U_W+\I^OQ:]T2W3BH< M.E >@Y4GE*)W-\YS[XEFW\"Y "X3A5E>O\6!3^P[=&6# U\7:00GL[Q^\C#>4YWLOJ!X MB#0:._Y/>&?W^@.?L.5SH7P>*;]J*UN^#LK_AI23FV^@?$+QT+J?S44GL[R^ MYP0MBSEM3\+WID^;,V-.L_NN]O+*V++*%_%NC"6Q@Y]:O8\MC!#R\O M?#IG;;P<73HKWG_#XH;(VMC^7S],[D^$LM*D_E505HXN/OC>F%)T#*$J:5BR MM4Y-[]8DQ3!T0S)[34O)18*%23VE>/=]E.U86^7NST4C**V)]7U0G0,_83'' MX^K!F&Z+[?_Z=AC'=W$=>OYT=N:ML^%I89FB^-+!827%L1BI>A^JC-7;&=NKF?><4]NRG"WQ?6#(WIFHE7(XS9L0J'/"^Z(T4^8SLR^+EDR'\]'*W] M1#3BW:T#PWD'?E9RU_AE9.,S7EHCK6!OL"N>_.M_^ZQ:)5,'1 M3[\^-X*'C6:?!WK:;B[^L>_7B#H0J+\,*]Y!*Q)$Z[W3K^,I27O&['&HUZ=A MO5>#]59'2+453C7$L]YG*._0IXG<=Q$K34GL>ZVUVAVKC&EP+JE(E'$'O=P] M>>S::''-\*S/$X5WBJ$2+!POO-Q27G/AXX5C)NBSQ4EL4[%KB MI87C2]=!^'FR\'K\^%^1N[J&$OLN A 0-+'O&PWITC^.Z?MO\BZ^Y8 4+:TY MF7AVJ#!XWL'?CRT,CBU\,%Q887JJ#+LX= M?9]!:>.M7^K[#!B^<>V%;94%M.%CJX 44 J,G=CP'?C>5GD4IK&B\O V>MG. M*7;SVI?/->3.U)6-R]I65)H?(MJ 2E\,2W[Z&^0#OJI;GYYK6!E?UE;Y_(?D MJA1:]3PH>/$#_^K"0'_QDHTY86@=!?+GI%XCK?<%IW#<1X)>Q?4O%=7O?;I. M?6:^QQ[DYUMZIMY\W;N38OW5M?'M%C#6L0UT__P"_#&67DVU9+CXQJ)BR_#, MPZ?)G56)9\GU+U!2^G-$*PXU')G5,FS.PYL[AYN/%#]I/EA\H[5L#[3)IG+E/QQKHP5?S66 MW(9S?7'('4UQ,/$L*2M=0L9,[JG!EP&])1[SK$%S8O-0ZPIG#/O0O6J:M6;8 MO&PUS.0*,"6,.;D![W\ZV/_O]OE%,E7R;JE=BI'.ZMV"6O"_K0C*26>",M5;Q# @DV[ TMJY=H=6/(:>5PS21P!*/R75!&+:EI0" MMU4$=Y<9&@G"D81V,N/@!4!>AU*W;F=34CM,LC. D9&-5+=L*#@SGU%L3>V! MAA4%R&M;&5@R54YZ Z=0%^!0C:^L:G(>UB]OJ+*E2&DUJTA6;UZ1P!M/ZT9. MMAC021QZ@2CMWD^ 2!,[2TV2RUP^)"?TDE!6N'7>"O M#D/.<7A.J03\;!+"&+K6P>$L;9WOX>&0:O6)>*9EV$D+5P]&P,$M79=RLM8K M994N)0MZ)0U,D@.>1EG-RU:&F:!IR4"BZQ8NH[3*R%J*Z:]9^IZM6S*PKS\8 M*:6:G8[T*#U)6*P Q;P*E"&Q<]N$29\E+J&E:2I"_)0*S&ZAW,"\D4)*+N_H M48H K&$H%"@9N@TSMG1?/U,<_(DH'L,[S(#3=]0?=FPZ(1U0LD?-V3DIJ^94 MMAT!E7+N>59. JW6:#&Y2US1'HW3+)JQ&&FB2$B-8:@[X'P8OZ@MJP@PU M(-'7P))H7[9@(;*N^#E-T6)% R%*6T!5$QA8L8B4R+L(4JDI? )-&86E([F%5%,0+]I2VB%QS3Q-0): BK6SCZ )+EM"[!A5+8&DTAFN'$Q"!R!*"UETU0[L-WOV8J)@V)UOZ.5: E+*) U M6&0!3EK.J5F/A4T[GZ=316J Y=&3>M;!82ISD%!M!M77OJ$NH(RNJ!E>8Z(F MZS3KC>"<$"D_J$'"AS!5#6P9RCC1I'1@#'X.R =&'S%1(K*L"D6#95J@_LG, MF?7 90.](>!JGU"R9:$JH132=&VZB]&^&@93B[;,2A.U'60);AFZSX@&?QV; MRUM-B@D5[2R115 .1*G+6D> P1P_QZ,/%+#P=D/O5& 0:EX1ZC%.:>'DIJ/C M0G6CD^%B3&TVJW3(65 U2J=+P:!2\+1!5DE;_OQXK5MCN$J/DK0M8G+H.E . MX:3*!Q$VDRRK=WI6[53"?;F*W#2')ONFJ\[013A)0PW@167H9X)-4),J9==/]X"8R#7PX8/X98"O127+<*.PW#7R6"L/=.5#O M*P1%1XLX'1D%-&T*B%(#R9&.7HC[3 ]%T;INSG48S:[:4;4.G"5Z[P8(DF9G MLQ+:)2E<@Q33A8=(+1M&<#G3=RH"W@R/[H5WT'N7"EX]50(\FDMY[#X,)=& M$ZBD(=B'Z$78F0L1$!X9.M6,7-Q)0DDE!$(W'*-!"%' H^G&H-&SMSQNDE@@ MTHNJ.6(%!#;LP#)1J1:&Y6&DL*(,X[ AM /%3,;-.1G$Q&#:<#S">CBK]7:I M X* ?'TT9&\E&UP7(2(62FKJ#$BYFPE>[>:^V7)=R]+%\Z66I4NO7^K3 ,(V MH G(,\U\D.)4 .QVT:%HGHIFP)YHDU:0E0)@HAR)AB-JGC$U#!+HU+3:$[)U M@D%03 X$K*):) @&%SZ%,IG5]3R:;&20+$GEB"H8"@ZY+JZO[YBPCVV+L[$, M*&1;!=.A>3&6$A E,_J>;0Z54FT(;XYYN$!C,N-PPV\&).8756<]1T-934(R M8((4*,"D#3(-=FOQC.LQ3R!;2D=OH*;;75U@CE@'42V2B1( ]'2:1%X,2#QZ MS.'0A3$54+,IF5D6"DO9&-9B"B>P-#R0$4<*0C8/"KU?GL>O1.\)!I(WU%QX M&%A-, ":]%&[< @!2:=@\:1MD_$I'9^ 6&;7G2/^I?1D C'M !)"C!E2D\R M:YMJE^(E4!D@X7L_6<9H$X12F?-C(P;DY>;"@^1"/@X22*$Q,)(Y8?(Y#(AF M@(0@SZ@H/1G9-OE&.;+N?T!]=@4(/8)G<:(0 1=!=O)O"#XEZF*STN1C$!*I)2<=\'W8, M]BH7PDHIZ.!Z_H998_A^]M;6PGX>@Q7(W^94$YB'AHPU4+D4+H)G\6(-:68PQ-3(ZO+*?0BG9 OLI(0PWB%:=X,10R,:6H#/QQ- $Y)%NF*92 MY,Z\#K92\DI%>%ZNN"Z6 K-W1*P>&@165@86&[1*73S7#*@:W8$Y QIG2!B, M&DX"1.+3,=LL9VG -MUE1EHH_>W9H\X4HW9#0*=W$[,(T3=-(8KP0(W1O!_Y M+<:!@->RH2LY*QLY,8K3QBV*P,JS>,F\3;1736^!1<:T2KUQ658O*L$\ZR_Q M<%6K":;Y)K#HN%4F1-!!?%*+4AMM%!4K@S]+J-6S7Z MKK,2F/>M2S4G&<6Y$"Q&IYJM4=?3FF(PN)DU:.UEP\1@9%"[!JG$(M1#(WIJ M*G ?( P)[FGS4&;;7 !5NG!Y:C@YH3:4+B?+%AH<=4[10($CP5!5, QQ"U[* M@57''M0QNK;6KFJIFF GUA8U#BQNXO1@LN(FP(D+9M \2/UU$:ZE0$/RAJ.& MH>3="-;W#<9E;&#*AMC"/(W?3-IL%J2JN(19*%47RF9&IH$[,0/=*7\?B]'! M*:D[@YJR72'>EIXG48U?A>SGNO48KJF#X>RG>VBHOEUR+5X0KI]2+)KTXN=(FW3&+VR!)-K)S@,;ZGB[R[CZ:3FI^#5\ MRC+<)V11LV-Z1D%]50M*U34K5JYDY773I)%= J5'&LA:M*K:]04)?>08!A* M%XJOBQT*-4P-U>&VQNZ_UQJ/+PX!E214*9H>DNMV/=4;*J3T%NL ]W!BL#2E M!@0[/+A <8C$?D..9@E4$JD.EZ2\R-<3=9KY$.@FCEBN[N'% )?#T'O=8RN@ MH:V,)YT"D0! <.=Y'="AZ#VQH0 )D(FX/R MFQ0!,"4(\\R1:;<+G?5Z*([J![U6%\U)8,"RT/)ZR.+S^)G'O]L0J?S9C9%( MN:6Q=5DF' 0&ELX;5H]:W" MUR+VJ=+*X>*)E8'S\\M*E_P8*WQ:M2^?>;@P^PU2+[$?/P<*!Z+S"M=$[-/% MM_H/6)/+3?V(BVU"@Z\-]WV&/^T_9-;]/!*IS*#/Q[$=X+GUV:EO-^"5DH/C M\ L^AE7IKU:K!(WTOS)6NF0(VND_;$]Y>6M[0V1P'/[$;^2A->9/X9;HE-N^ MDOF_]KX%NJDJW?^<)&W3$IJ 0I6J%H<.B"T/(3XHE!21 ST85I'+8A !!10 M. =0FCXFS97-,=JY(W>X]\(,<]4[W!GNR,R ( *F!0D@8H&J+6VQ(..W_[VZ]OHX([66>#0&K!4Q+; M.(_G<#Q3-1CM;]$_41$:K#150Y[\N38X59/E[B7_[-C@(CQKY#RI?]T]')4^ M\^Z\@GQYOYKC8IRS??B&B,X *W&+?0GFZ%D]I>6OQE-$# MYY&<8IP\M9CC;(ZU.DZ\U>;)T:5Q69T>'8D?YTY.JV06"A7%>/)'8UC M;1JGW^#6O].N?W]F,K&T.X_8^SL[A60I)S5/RDD+UF5U@K-%[_!X;B>0!WG) ME[?CZ6X/'@ +VL>!XS&_'9$-Y>OV.OS\ZCNB?,9Z>U'Q9I#ZHGMBZ0"_NK!S MB*8"4F\'$T.>G+:0GD_QY-"#,)X<2G6/FGVP8_@Y1O9(H?JCUV9RPJVNG&Q3 M3B8&FIDGMRQ0@LAD[L8S=],XX18I9UJ>O _L/3G3J"DZ>PC?($NI2#Y4_]%! M:$*SW+XG(O7#WLZ5#C/9VX4ADJ4]OU@N5(YZN4L3B^5#$N6 M/C]Z9>*$T5EI(Z8N7/'LPN<6OIB1-G[,V'%C3)E49_>T=(UD3"<&\IB&/*4E MBW3D>0-98VQUDI+=-(*@_22L>F+QB5XZ57I 9P#>7N36O8 DG3U+C'>)V'6T-F&!*CS9. M4 ?-LF26T'[+/ MZ-4>Z8=[*:Y//.]'\_%,;)PJRK_/<843XNB5X-T.\!0"(;7K'TG79;FKUP^9 MU"BJ2-W4JB;QVR>BSO_I%%VM=J/#;E )M\)_?K4&JE(_2BKO3'9/._X4&A?) MZD=9 RRC]38WVY2+]387ZNWPIUF]S67U-C>%/6@+T+\_1U?5!&TD%]I(8![3 MUO[%D]_""\9L#1W4+)*_R..XQ .TD8I)'C,]H2S9 PX[,(B28CES'IZ1U^%I M-;?X,*0*$VJR!R -]D"QW$^Q1M>C*CY4V<@/:/^KH&DR$#*C)T'M,*(S@.\<(L2HE1D[#I- MBE)\@ZNK29G6US\J/,6))VX+L+GL,4I]+;QN?5VY^)F5(@SNEBV@M79L=*W-&CLF:R*MM@-I0+3= M%>!9:/3A^,VZ/&C0>:P_?R\^IHO!_LBJQ0X>2 9DVA1K'>DOUSS. M;4LI338]I M2O6.-5!E&J5LK2\9[::+5OZ-2RI_UQY(9 M&RLG#'6>%%3KDL#=T*G$@%6PN_]X#XV9GL[OD0,F/Y7@\<#UZIS[5PA#RW7W MSQ,>\MF8__M7"ZGTP+SRVXW-..MDUA&?E7UC]=Z#0;_+05'X)G>+/\I>"QP+ MU>O%_#QQV$4-I&3RI4'[NV^DT*?BOJ=%0\5:?B1(+MA7[D%>EWB4#*1'*[O+ M)S3]3'*XG06'&CH8Y_H?+LRYHN2'(87RM-F4?9%#/GV,/8@+(%(( Z*[=>@S MXO9C<%']>W8).]C:L]N^JR2ZVZ;]M8'VUWU+POTUZZ%CA0/2WC-WT%]\7J*T MO[A>VU^4/HFU6DY(*\R3%]_:/>@HCJ28A*LSO0_D,0V[#\2NE2PZFU2LJSCW MO8U8=]BDZEZ:.(N=[EW'H5>>M68M[M,6]'J=!CWLL>;LH- MK8:"?)>XM4CFU$Q+B<[95*HODBLMR'F$N/>0E)WF'=G V&;KLD&">&O357J[ M1>_M"_@74SLC&E ;-^3T6I+PD_(!CFM:?=4K2"-/I)0=UPSZJE^AX9^IH>-R MXNH^,RMJ,M?U\6X'D\K+$'GYJMMG[O[HV+%C76=K+JA=FG_EW<0(Y6_7J- 5UHQ';?T-CV(,]\**;&*F>8 MPY2)G'.U8*%+5GJMN#E5LAN<3:O[Y145%.?+'E0F-)YVVHXK2<+(\L&.*T K M+!YO'SXF?,<5H-=G:/$-I1<$DBK&(=4&S%["+4DJS)<34SD.\IG@105RE5D]&[*C:6WGQW:18+/6&;C9LV; MQ65FC1TW?L(]$R>9YCT]?\%"&S<"-_IF1)E/F9HSS9S+97*9H[G1W>MO95NJ MBK4O*"^+MG,*<*!XQXL&U!N.7>V[N9050=/HSYA6TL!(DL"#39JALSG.#K$Y M+B>)P\"+S?%2,E9>2UTQ9 V_#8B_)9^+4A_AYPY M:-8M@4JJG?CN<+TJQS\.G M\I[F!;L;P/7"[8XZ<%M]@;V[+_3B)BJLNJ^ND]9+D7?WI1N/>SN$_9D2__8+ M+/X*Q2SDIEIY3X.X/P,\=9'CMBAF6RZRY\2H..LNQ7; %?MH4>F=LZ^%RBW- MB_]#]BXLZX3C\D_%>T(A/QX@F[$B@8RH=[W[/=:Z4+WR_O[[<,)"\D&31)L(DQZA M7T[]3[(9(Y-H^*XG?U8G;6!1]F>-28FRMLYQ)7%5751<3\?&54CC8OFI\&8J M,6.P[VUL7\VWPNF.^T[S;E6^7*R_,'Q2*K2\( M> \F*,6J^)?HH[,F37@07&F1K@_[B4N'#?#A '$9: ,WT*)WE:$*I\UHY]A MC;HVX\/W-);7!AI0K4$80*.S&*09X!^+W#+P$$UMT)**3MHZ4@)$BT.+()??CNHCP07SDA0:F8BE,8 MDE(WJ"6%9MAB:)GB;]F;!RC3*\*$QHO-U/[SUHKS9C%!28K' MB:3==I[CWL?9(6]I?$R#B0EL;CBP%.9M>]B;6?%629.)XP[7AFGP5L#J3+YK MPT/XY7)AN\MG5 0[S$-^3!S_B2IY:.".@VF,)S\C)+*7Z>+#CGT83J L6=J M?DTTV+*,W69*1NI:C-N-VJ<(9;R^E&[R/C5])NQZ87E)T/70M5#=AI2Q=%K\ M^7([34H*UC^/>M\TFB2=@[[P^M=PMB-4&WA]U>^1"F]V%_>5/LPF3F<)Y\I& M2_1%*5>Q3ZCF\L*S+$NNTGMYU!BH]+_4G<.C\CW"OIWHV^3$1)3W)YZ(]U&^ M##K>*D^5*.4=M2KRV4@:F<]0'0D/[:97[)O-.CL7",Y*3?!6:B(Y2A.&A^K_ ME("T 3M(N'VC<=7WKO487*O7N@ M=/SH<0: %^XX'R)OQ;G/*XZJ"'UG%7(-AM+.T\8<]C^>23E)K*U]<#[$*+C2 M&:RJ%"P!F0/M\N7T_O0R4FB:1N(9N0\-3=2QWO4&)(Y5(^]&5??ZF>F6J./ MN]@)?/-'9XC)$WW"U&*JP&RG?3S90^N8#*2+T#=>' =U)Q>BK MV&>'[?6[P@[Z]T(_RBD_#;OH,T6Q R&3Q M[]/1QGVKTN6(_7V#POS &,W/56'1,9UVI&/JJ4IHV^<:'^1\D MS)$(74)49[Z>"@[K-J#)^S@_HU""[--@"V%BFF!PS>9CYI1"I%8)B:[9*N)" MQ](&)!O9P%$JH8GIJ#V>N/"[DXKP57KGZT@8*IB,W(P6SB;]JQ78#5PUE)E1 M7_&$)WB<)3;0'K7#$#-\H*.5 KH*T^=2>/AP7$N'#XX#[1!(^3X61"^#CRC? M'UT,^ZYFOD,YO<>U(8>.7B -2(Z@.2H0_:L2)C\RBO$]6QW+?U7"U"XK RIF^.)-]\8;=_^*AS/BH1NM#7_7=J^$/$]7DGE M9BU-C::W\K[!--T:"?5,_(].4TM;V/>6^"C*=1[B12-K1R29E&EX>X=W5APP M.44JT;]Z ,2JQHLM3A2*3GM19IM6T9&M=S:%Y45.Z!-F/.(@3WS+>;K,H50> M[U-JY)F>^,^9<:]E'#4L'A=):6><0CT4%68BX5HTC'#3_@[=HL+[PA<.[[_C MKDLW[YYN/9(B)NE?^Q;[S1M-_*I(9*90XC&>_CLC07ZI MN;%RC_+]UPMAWUN9[U!A,^&,%&DD%[YXK>H8 D3+=_K7KE%NSF8UF'LR2\-" MX*W7C7Q1)/*1FBAJC*0%"LVR_$>6Y:!(@*?5/YH6C=ZP[TUJA1:*T K=@@J+ M^5QLU9T6J13A.9U<(!AF@K=9Y&D;W6*Z7W)]&0OE*U4O1 MC:1A0@'&E(#^U7?Y& [M_3?QZ)S,PB_@A!AO8MC;_*Y\!H[Z@,M<+1I6XSI3?8VF;\=AMLU34O; M)+NQRX.E+^23T_Q1&O;0"E.F. AJ=Z1>)U*Q,>-S\J!Z8./%2!\I&HG5'XI5 M,OL/<9E!L]]D]:_XQJ=J:9#L_HR/I9)TF0G7XQ] 2CD:[5*N)U7$TL*ZBNGK$;UVVZ?+ADTQ"U9.,\ M#*3,.$ VXW,]_=)DKN/)*?!7?G1&Q8',=8--WI5#UO/KXJ?DFKPK.MGXYE!\ M9BY:#LTE[1E^UUM[K\6N5$7V.]'%,\>+J"_X?Z%(.J?3:?YR R?V*Y8_&:W, M\>N=O\;AH$4G)1*+'_\%)'B^H''4:,$ ?*F$9WVW1?A!+XZ1;WVK MI033=,/*#-.95<,5%_M/Y[N/MV#61ZFIGIYBFF%TW[]AFQ7N*Z-)6OGPO M$ ]WU0E&R1QX**.66-NCFIAK%D\LN!.):E,_J"/M)K%]I5HRMP,%U7.-TB!3 M,=*GH8S1IT >DAVFS]Q,A3[B&M\#2OD#?1I*!_=*G[("WR!R($R/$Y,C],@H M:1>-Q7)R.,"?*)GL2:@K3(6_D@5^PA.OA=."]H:T(4?L%L?W@C3>BT7G$/JCKM.,$U]4( MU"66#LIIZ'T5[#LKZ.RT&TDC^;:KT7&*ZVIR=/%437@UFF'J"O.#8D=0;)?_ M8,(E:3^0R!D4$D*AUI&CO6<0TI-UTB:9DVW#V\MM#[27B\8NLPYD04Z,1V7@ M0AS=S !,(_4O636#<=ET0QG[J"Y=F M,^X>S,/UU^'WXS9/R"!Y6$,>URK7."B7.I ZJ<3?8_\)!#I0FJJ1-$X,E:AP M!ZB1O?>V?RBT/ZS,0.P!UQRC4I@-(PFXJTY6.E7$UVGJS!+7D' M7#-UKC*=5&1P:3;0W1-N;5YQOMQU/ZW91?*#Z.H,3AK9 ^31_<;I!)+4WFT_ M55@/--6:;<2]-FXM,0?VF%[]8E+7A1-7H-W2GB'KB,<<8+<>\&50N4XL#$PQ M60.E7?FRB#),+5EA!&JBB_V);)>E(YA8-LIQ(+%:OU_M<-?EY2Q)*I ;J&-( M8*[I6NF7.;ZLZ/[^0)+O]JCO:'];(OY$0_E?25UDZ3EF?Y%5F^7NJ@5A+"AJ MZ7Q7S3D#?G-!J)-N;NPW MQJ)>PLNUJ##^,:,GV\!';;-F]T<4A_8X23D&4ZZA3$O ^EM)#$@Y&FFF 7OB M(@.(XOP)8-ZFF5H[#U7R!0S0'" >AP?85[M+]QJQG#=]O#+9DT#KID=CLI]? M_8WC@)&4G <6XS+^DEA;'8>,1&R6+!TNW:O$T@#5W5$+ E&]Z;C><9%-HTJ6 M9OTNZ&ADYQ&A1+*?E\1ZC[F-]4?Z70G0CF3]KH%\G=K"85M[$/^ *2!-#)K&YFCLDG6.AL9B-<9V%M7[X 1DZ592J3VLO!43$S2 MT'!<2GBQL;&@BE0V,A1O9PC%K=^5S!^62MI8U*?!([&V861_ 7?F9HW#7*^1 M+ TFR.'/!Z L:VT'QN02?F%TGBQ+=QP*.![DQ-2'@8O#M]&75!VTH!#.E6F9 MG7")^2#Y!FBEKH7N7MH#TX=/_(Y6M3 8.A>-\_DG>9" 4)ZVT+U)6FA3-4&5 ML$*:L !9:*>8NN@%J)/R<9"DWT C94QQ M3BHY/5!=G&$UMDDWKZ$DW_OI\U8X0N>;+KKWJM5)$,86*02X .0/)!;K+KW MPI)&>+T_5Y,G+V2!D,=TM!/T0RMW&??C=29V'; ')";(-@6A?HOW$W,;5&,H MPJPF:&?Q>+W)KLD9?KZ!F,^3 S57#7B;H $K>W]H1!EU?(/#W*Z!ID8M;60* M-&;[>1LQ.6HT$C0Q:_N*W2:Q8Q4>]X#PNH4#OGOU"3Y6GV #F=!ZLL7OJ DX M3)SP'4I%T(T6LY;6\ /[[W![\G"4;5SKH&,).(^4I= ;R_QT<^'*&/Y\N*L! M>,AEH^/R+>5W[.$X+7?J"KU FSG.[;[_DVW1=]2T.2X/+;]]SS <4AXE)V@= M.'4.1Y*WQ+KWHTV+V1_5W^-X&!O>0WC[I)0-8H?*)6@#TM!">2\6G.==; <9 MEW$3=Y(CF%0^X]T^U( TG,(K@]HGXY4/8L?*?E)N((9D"/N/T[S+MK-71(>&\D2F)Z#OJZRH4ZE%:ASM=9"H"0X#Q':2 MJZ'%B)L^Z2P%U#7H+GR94?3%R0CY91H'> *OGNFLG9K;J&1V( VE+IPT&8Y] M:M7@CX##2Z*!Q.^?@&DY@[<79OG&A,*K/' <'5@,9+ D0A-LEZ;]"7*QLQ-B M^*;F7%Q&+8B$9"#Q]YQZB-3WE-"1,G8482/P^Y:2=DQJH2S1#QFXQ4AH/[F& MD3E0W>+X.J>[[)::5B-O[HB9H0"C#'-;B[F]691IE+$Q9K-'^_OLV3IYPX0M MKP>#GT^>\->W)T2^/YX<,S^"I[N@B)4-M[C]ECYVLX>?/6B[@FP0<0>6BWV' M?O\@QY6[]2]?II<6;:CNB^?4'@-J5R3_,)[O!17_)/R8L(J59UXRST7XP6XV M3[E#$G=4@' QU/MU]* ?++P@.(>GX:BK3!P.[T5_N81]]\$ [#LJ)F<"7Z0! MZ:N>ZH,G3G80^W:/LS08VG.X)O1F/D@W4C?I]RH'V5.QW%57WZ+M*^46K_/K/$CA^5 OS\> BO?24H.._RC M]4[9FBD>;-'>4K4[CDROL8-_J^?)0+I5P2W;QX4*DH MX![&'GJ\VABLW;S]X+NTI[UL-U>3TSG@M3PMG'+^)-FP)G1J,&H\<]50WB^< M?G2$KU-,%G?Y7B6,U$CNC7E*(,.B_?>/Y!\=X'LXA4IV7'FXE4W_+S.H73UE MJ?Z%0J+#;]8[48R&SCW=87=#>3OL>SDQ!00K8M_AW9;8;<('@B.BUF.NXY32 MIK0:*6@=_KM%7=!<%Z:N$N7+ZQ4*ZZMCB/L-(^[J.:Z'ZBAMMTTGU!\6_JVT M[ >XC,3U2%Y=3%%^*5EWC+1N0\)H*R\/F\5Q97T@1_CBBX/^TE+OL-=QPFU= M)?4X Z=D%J^"9.FG^8++YDA MU,.0JR $,&OMZ^V^WS0.^M?/8L]4(WCK%[H&Q5' MB3^]'6RK?@=-X0'<,U\VBATBN0.)-6#+7*!%WS?GXFU1>$VK]^'8--3X-?JJ M9WD\$^/P\V7#WIU40IG35E[08BR)$(&C1COUA!^LR[V5R):W!VC\GZ!3L 8A MK/)O*%T1VBPJ@;UL*=6_O$IYKRY=-02X>3!XJ1QX.]TJ>C4B?] \]1>63&" MK+B:<7]E0U16Q\=F%;L+2#=+\6WO/H4IODYZP:C%*K/DHCLHDL:++6=#4_TM MC>*RQIHSM8U'P"+B)&HM8')L?Q0AK9>G.Q;QYD6+OR!?_B4(*\T06PD>$_;N MBE-R&/+'Q#Z?IJ6AI8%581P%'BZ6Q.U%?);/Z4S2BYK>X'+VE$03L6^3GJV!82G-R[A MVR;'P12LUZ4_R7)'>@&HU&0?IH'8FR.BA\)OZKO.$-IX)"?C;,VQ'0<*,Z7 MKSIX6MR^@=W\=V30[#$>2>P-DK5#;6UW/1RLO*R"6F#O"P:5M>,T0 T8-^ZY M!T=XUG:>LE&>\F%[[;XR7Z-%D:[&H8F8/LKL^@]AG4/ .,W&7#\R1Q M4Y'\FW::9\F^M3A/KD6B'BB6C_IP$+S5<=#HH$GBR@8RYE"$[N1;OZ84P\L M[VL",""THKZ6\/\@?47$6M[ _77 !:;(+YVA? P9GR3 MQ3$(MTJ9-TJ/Z3S9[" HI#9/WH)1UT"I.X_8IV/G6*E&\OJ!.:Z&MRYL-'KX M6 (?2WC)OK%87DH#WPB>YW]-;YMSNLN?]85. *^$L(/B4FJ,[;6R%N7ER.#&RZM[\"L#&C,X<@0CZQWY# MGZ9J;)7$0.67E/G1NE%Y#83>V*5B:5-X9RAW#?97VFR5\@E M4(I-2RO.'&&L(TQ>R&G3TE>PW'Y3NFID2T.EO0T9*&9$#NJKAES!AAG#4P

    -]@'9KF]IWLL]T']U]$9V;:@)8#S_JTJ8C[/'R*B#)(5SMP%ZZA=1EG>SJ)&;:26Z+'DLIZX,PH,3)50A-OZM6_[891M4=? U.@GZJ?QO& MNW3QXQLH(E)7(QN(N4._:Z)^UXF,3Z'4^:_Q""$8^J6)-1<-^EW6UHQ/R3=\ M+;BEQC92K+(1O<.CD439)+:MJD:%)"-8,AT' J:KJ_JC25_(B>]29+XQ@$)@ MK@&/0TMXU?-ZVO6=ASR\XJ$B=7ML-D@7SF?C';9&G*2*R5,X/\1ZRU^Y:6!\YF(<: M_%]DI_.4FN&?/"]G^?S?O7QR\E\./R6-6']H\M47?Y-WR[13RM@Y71EKIRI/ M8W9HS-WCO%X%IYS72W4\D#H?M;W<+0W E]^FX=SQ5,U^NOB!4R KM 7RUO/ M3>*H0V65"&JU?8!'C0;*9(M/IXQ7U>R,K$[I0J[0)7"#MJ36CIP_JK27,<' MD 6_20<[+T:GWZ^V!EQ_'@OR#1'K'-?2RD;MQI+*:,?;Q)'DXKK*VOX:-O@Y M<>HB^::/=1T[S(GC"3KC;:F#N$^=RSH2'N&4M%=B]3=<@ZAQ"@FBIO.(<8]" M)IN7MK?$/9F*_5)+W )\UK3$/0?/TY:Z,\#N7&IW&1U-RYMBVRR M&=ID=D=M]NH7M+A#9R>?A2I(Y:#Q'(,STC'SO?N8%0QJJUNUPH>Z@01CQ'K06\SK<"X3!.GY]&QQBX:.._^ M"CR<^1H<^_*Z]U]F=U>#<"^IQ9@@5)TRP-7B;+]&N%T)DH;9!\)$-TE@'0KY M;[1#'=\H-Y=H684= 9GERNYPV ]R^E=QKDRBA(=ZVQ(G8&.P0&O1LJ!.6]:U MQ)6R!E'26FD^C]/_Z%^<[C%O9!4'-_9#.ZH"5YB+LRU6;;.UE<:EKVJ)P[GZ MUL961<+05^T#$^]+X8[:8=\!]/YO&L0K$ 30N'G\=VL@C\T+6R%.9>8&I4Y, M'.5?,>V1"5M/0)L$JT(F#4'Z*PYD2I;J=8.G$ OZ:2YI#;4V?=5&+018T[PP MUO0;.M56!PDPB75ZURFZRM#:< 02 0'@4^NKA+!:) MX:\WFCZQ&K>5B=!FCYDL=>(TC*X&XSI!4]72J*^"P@4Y&$BAT$_,F04><,:R M+_:5U1+]$+X+ J__ &A]+AB[!9&.GRVO %7H H(6!I/$JI/$O41T M2Y;#4!&HJ/_*-)ZRK&3]:_?RE,.T:.@T##9<^[U8!I?]N/,=!D]!7;4>E)%$Z%B#O)DNU,"(D<" ]0G0T"6>ASESC ML 6^I,,R_:,C^DXO0"3 M+9B039:!)%)5)%DVYLNV5C9 %[? R)I@F >*Y%\TX<3!%L=!HU32,+*D2AA8 MZ-/08;YE2[X\KE69L\&]&_?09+Q.D[&-*S-(XC8(R-"JF%)53.7W4:%H=$@H M&MZ%2J':RX74H+D9V-%6.D$TL,?ZXE9&[&V<,$ZRO([+Y$87H\SKTJ-C#07R MOS=3A2VNXK2,VAC=353>*>8=YX:A3(.SM'U"X@64#AAHRM(5 '2T=&YA:CB@7!X\K10OM/"#T&_2=OL< MJMHJL^%[Z5AP&H=AR[=0IZ_GT4AR:21&I[O\]A[SO=!;=YT ><7;!]LSBH_5 MA^*SL&5"6_%V=C]/0FOY0!46P7;,M&5[/AW]?1&J>2 0;22630[[5DZ8(N5K M"F1_ [-R0ZHW.0[I),NF2+'A!![4C?,#Z03>$IX&]F^AP'0A_A*FUX M*IDKG&YQ$NI>$L=VFK6\.,IAKSI37K>VA\HI.&IT-Q-39AX93-B^<,@C1MU^)GU'2V1Q%R34M M; G;X&PJ'R0^H-!R EVQ5OJ#E$@?\%6X#_"-BO!_6L%]M](^UU*-F^%UW?I? M6ITV?\K40MDW<@+4D4TP2F-D$W24*G9FS^8_V'OT[I90_PRY*_P4ITE>,8G5 M8C)N0H?H0PJ6L&#AOWL*C-Q(,AVU02."M*219,G\BNLM(3)UHNPG=94$"N5V MZ%:6Q!?*(^*P? N7J.5?QZ.)/"8>E9HDQF.32EN")N:PD[7,B8XZ^1*->?EW M$1T%ROZ[B!K/M< 54,F6F ?_#:*>J1Y=$Z5_2R-D]:(VZU*_:+59%?-U38JJ M*BG'0-05,W5:QUIH-)!\$T=C0/U[3,N55(CZ]PI3D))9;K!2B6HIQTARM+WJ M,X6A*]T.2!VFATY#%,HOX$CK$*K[E$\:E+8G#H.85:Z<'*(F.09/#E,9F!VM MORRDV*_R.$X;4'>X"2+'B/-Q0C_]^SG)>;)50[=!J!W'>5OB2AW=Z!G9O_14 M9'^BW6!SK$WF2ON[S%ORF-]?]*%J*P>PO5]4RT#D9Y/,6VW#N7;; UR:_G4W M+OKP1.^PMP(_\\3CT8#='!#)-R$\GF@E\?@OYY&0USWH /Q7B,F5:ZEN3S%N M#_K$#:FO]SR?P1+KTCQ1TZK*:'!I/L EO#SYUWI%VZPNRQU1 ^>:JD\/>%1T M%/NXADS5=M, 1SS[%\%(+/ NJH#[]BV'^[&9+_HPXH[K[D?O%;G%XR+$F2\2P 43,=2\G2K;Z3T?M[?"4Q M]/1DZWB.[>WS9#,E:ME,>6LV&T&S#62>[!2FR"T[&8:YV4S59?9X]IC&'E0A M:T]]OX7RYRHEV2/CGH3_P+.'X&Q7HG3KR!Q(8_DW8*+-DZMQ?[ Z-@#POZ@. M:IO\2TTOVORH?:1*>N*04#%Z_YB^0JC8 UDPCVAB=]EV9NM2A*0\.5WQU$VA M7F_[9=CA%_W[TW5;M<+/I-4&9Z=0( W+^)9,W*H6ATK3C62ZUG=_M_,%RBYI MSW1*X[ 46U@4/N5 U2F4'<\XP!\"QOTE[OKK62D4_8L(]GA.\)3[]K]C[U3I-S 5R9'VG<(T?!)S1^QJJ.OAH!*K M,ZX-]40G@(6*:JR5@2EUY#$]G$YWJ5913UO=O11H^*.H2LQZU_HJ^@1']ZZ?=GG(?OAU]-^&[(W7T7\;LO_9#^D+QP/*0S] MJP[E@D?2M8[+G)CDF99.3R3ZXJ5$ H:[,Z/"/P7.=.!,4!$^I$FT6_V4)E - MVIU":K4T1Q/97S'MU]I@W6J* 3YACW_T,<58G'_!45,\,'\9!UKRR2Z9.%$9>V (]) M6'0%^2R%\\$+.4%JJ1ISQ^6@.( %V4UCJ*URIHXSD,(\,O-1/"73FSYP,S3V M;$C%QEY84/C\1=;)]Y'#.8-"IK1:*\W5,,9O6%,>5_H! 9']&WX5<)(GRF<_X)%1F%4163& MH /Q.CGP/A.]"N13$'%PLB^@O54Y-'8XM%$:/4/L/H*2Q:)6@J2B0[U7W MUCX5]ZC/.E"P:+6 9V,,5&]UJ5%1V1NK7[4G/T!Z98^([#^GW^E1WRPQ4T?\ M #]$^_2_8S^B-RB@[C3^4?7OO]4>+I1EAE15#XJ$Y+%HK<&F%LEI%!W[ Y(1Q*+MA2\$_^2B/ M(NNBEZBK%I[R0<$ _7N_'O222CJB]LM">L'?'/"7)[_%=RN4Z/+#N@+U!ZM1 M2F@CL\.OCJD_RHFBJL9NI$C^EP = R,%'W)<58N)+O/7O@26GO;UW#KSJ?N#0K\EO,M\"EQO MYQBQ;P-B#[VN?M](^XC.A"N.C_!Q,/5>BE?ZCY+>^Y>/0_;W]&[_=L@^OG?[ MUT+VFNOT?R%[]77ZOY#]ONOIXZ7ZF8V4_9IU!5!!\X'(**'(O^K9);/Z_D/G M'W'76?3Y1_Q6SC^>)E\KSB+G'\$,8BP(BH&@Z)=1AP!R_1YG']L4-N4MCU/R M<^AZ^5'2A^F]7OZH>;UO6[ILU129; *;\M ML8Y>(L [:E3$XL\!;^6?Z7=IYH"S5AO1S(DDH6=]%L+G.>A$R7TXZ2Q.D/I6 MS<-K%S92F2GK9-?7Q%Q/S T.>PJGKUJ#*X*6%))%7M1XG]6$.FV3W;@Z0@01LK6%#*6O*2AJVU[:)E.#3NO=EDZB*7.996)]9@+YVX/$[&>V!ML M=/5GIL""[ DUBO@H-Z&9XFMX+P>Z@.Q MPKB^(<;1!7 $OBUMDK4^)MB+X !\XXT&5-^VS6&_P.F=],B?9;?#OIO7.]^@ M,P'']+M^!MRI3K]KJ@HH\BWYU$;,VVJ^-!#Q=C)HUK3O@ M8_<,L#CFJ%45R!I4SFG>SN9;CMFD&2HHEX/Z72>(=2LE.Q#6\J9D/4RL6R2< M#]Z$:]>;;-(0R;(=UAEDX2'-393R4$QA<[=\)Q^5X-O4LSXMQ%H-YP= MD07"BUN)V4U.2>8W]6^;W5 N^EW'$T^8#J^ZB^Z-<*M+MJ(&9LC; ,D*;JQN M&H!^UZ'$&M/1U2U939*XV]E9E@WY<-V_ L?[V_EV6KBZ*?I=@]!'QHF,1O(A MTIZD3JGQ&4C)QCV8MHS3^EVG'9YKLYR=Y8;CI=EOX=\9V3)#B"P M2[-"OTL+ JIE!QXP8I7ZD1>ND:.D$<\-L;;4Q_*ZC6BQSIC$O:7'L6 \FA70 MHB1+)Z6;U4^K,'Q?8=\!_*ZG];T>ZWL#J^]GF&UKR/4Y]GV>N39#"V]P+:SH MR=%PO#.?WEIT_1L]WL NDG:/],!;#$,LP@/C.DE(-\ 0QVCJ6CDP4.-5??L6 M?CG.JK]]$\^2SYUS@/^8/_X]&,R>!49@!XX<%]6.2VIP2ET$NL\4_+_Y47JL M$#)'S^\^\)LP)FL\4N/Z/_XZYEO3.4X[7/E(XV[^HGXRB$EK[KUQ]V.6C;'- M6RF,$5>N&//XTX# M#@.V 38 *@&+ /F 28 [ 7T!5_^'X\X#/@+L!&P&5 &> >0!3( TP,IMX!=P M#V @H!/B:0"\ _@/@ "8 ^C: _P7\$O "H 3P & PX.([''<$L 6P"O 8 M(!MP!Z!C)_@%[ '\>B?S\Q(\'P=,!J0 O- =O@_X=P#P4.XQ@ DP&+M)P(6_ M<-Q1P/\ R@&/ >X&?/MGB!?P!\!:0#Y@!( 'G/@3Q_TW8#' #$@%J !GH9O\ M"\ %6 +( =P&N/HVQ]4!W@0X 0L DP )@/8_!OP"\!=(,+A+&S%5)X; N^HJK05WF_9'2G^1'C/ MAZ! P') $N@7CR,6 GX-\ :P%/ :8!?@K0 SH@ MCD\![P+> C@!2]['X3BD#S !T!=P%KJ:6L"_ 5X S 2D :Z 'L*\+\ "; 8 M,>1 M;@-NV(%WW&[7#N\=QYCY)#//?0GO.(.?!^^GC[$V(\#[T6/,?3V\_T5QGYK+ M%\"[WVQO<'[>\>AG $( ">!)@!/P'$ M ;R0+@_@+< *P"P%L E@*F '( /0!U(.?;^N WP#^!-@(> $P&W W MX"MP8SK!<7@4I'XZSXTYP?*G>8CGAI]@]!L![QM/0ED!%@"R3[*TA=*5 =\& MP#?@OAZP\P3+PR9XE@&>!DP#?' *V@V@&E *6 "8!9@(& Q0 2Y". V &L V MP.9Z<%O/TOX$/"?61](^$(_W 1I.L3ST@\_G'F)Y0'IN5_* O.P\O%=\ FD! MF %W C2 <^"_!O";3UC99,[@:3U)^13*:1I;\/D:[$KA'07FX_!N!#IA_?DC MO#_T4.1=-X.YQ_='9O W!::;O_\O?\IF?N[Y1_B_._Z8)RQM6+C\^87+;L@#3<]S\U8LO;'@0^E9%4I0[-I9 MUIBL>V+]*.MM\YKUD>V]/]\RL6+Q-^3'Y_A =T+\Q[^KF%O:9E(G5> M("Y;:)GWS.)ERY5BX7JGX1LZ#%':/YQZ.(X M'J "J $:0!P@'I T (2 3\41A*)X_H =("^@&2 GN"ZG^:?B^O%/QCB!^@ M?0') #V &ZSYYZ)[W*J;_._FC\G$6!50MD%Y"&],C.>8C(0R(KKX2QP< $; *L!J %Z2\"'@)\ 3@ M20"NT,T!S 4\]7\Q_K4X1P2P _ NJ7*< \"C=H"?XZ0Q #>_X]YZG$1^&<=6 MN! &0.T>>)<#[M;%_<1X:<)KN% *^ 7@7W%N (!'&E"I!>I*P64[W++_[\H* MV7\"<"?_9H R3<5MP4O5 3@5A4LS>+#M+0">;/D=SE$"\#)2U$>-2ZUXQ@H7 MY_X(>!OE?L"? 'AKY5_8% V'"@O> >S",2"]894M6+T'0!T.N ()PWL.E0?A MSE 80G.URA70J)SF [S5 Y?0<=P(@&$LAZIA8.C)P? -AXL<#'DX&$YQ># MAAW<2=R.Q(8H' P).+SY!:^'Q(-FC8#3 +P" <^EM0#.L&Z8P[LA4<'&.0#J MJ#D/^"L -0O_#>^!Z"&_N#-]D_;_Q1%I,D!X!9$O),K%S =@'L1 M9P >!LS$\3S I@%F(US QR;)RO .\,!N._,BNL/N/T=\!@ =W0]_@/M__]6 M_#?;_\WVWUO[_Z%?^BPVSX'C#QQ7W.!PBXUOGIOWS,H?,3ZSS7]N^L5B8>$-C\?$IX_Q'!4_>+ M5RY>9OLQXV%AA;!\P?4]Q"F\VQ[VU=Y-)\#/V#/[-?9<=X ]E_CILZ)J-+(V MKJ[_?/JL^NQ7]+GPHX_PF39WBPK9GKSJH8GX_*_7ARR%9_9?-V7^%SRKAQ[< M^RD\Q]_UW;.Z'*ZB=>*+!Z;D<%L:G,7C5^5PAV<]L[3F#SG< []XZOQC9W.R M7]FYYK:W!TS+NW3NT_-#9D[[UT\L\1^W5TP+^1NT+&[GSMV_S/WN\F2O>O8D MR]C;,B\_M/KGC]___LKREMD#Q+VDX5=_/KGI_G&_V_K)G9TS3 _\KF/:]_JW MQF[^U2L?:_<\,3QG^;8%(^(/)\7,/SR]?(7P(^B]>N5"07S^QLMSZ;QG%][H M! JMOXN7+; ]W\OT!CH?S]QA7^V>'SO7H^F6UKPY/.<>!QC+=[Z3PHWJ?O =>X_'NZT.6Q.%_/<@YZVY\25BVZ4X]'V4=YM_@A*?/GS M-\(#%??+YCWW8]K[/$%X\<;=W_CL78@_+%B\_,?P[]7SGGOV1[@7%JY8NGCY MRIX5=NR8L5GA&AMQ_]S*A0M[#3]K8J_Y_1'LEKI_ 3RL6+CTQQ3XS=_-W\W? CS=_-W\W?S=_-W\W?S=_-W\W?S=_-WS_U]W\ J(WH9P!@ 0#T end From lites-readers-request Mon Jul 3 20:09:18 1995 id UAA08435; Mon, 3 Jul 1995 20:09:16 -0600 From: sonoda@flab.fujitsu.co.jp (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Jul 1995 04:53:52 +0300 id KAA18307; Tue, 4 Jul 1995 10:53:41 +0900 id KAA04363; Tue, 4 Jul 1995 10:53:10 +0900 id KAA19817; Tue, 4 Jul 1995 10:53:08 +0900 To: ronf1@ix.netcom.com (Ron Feigen) Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu Subject: Re: second_syscall.s & mach_init Date: Tue, 04 Jul 1995 10:53:10 +0900 Sender: sonoda@flab.fujitsu.co.jp In message <199507030725.AAA19105@ix3.ix.netcom.com>you write: >Two questions please, > >1) I am trying to build lites under FreeBSD 2.0 on an i586. >I am using the i386-mach buildtools from jaguar I used to >cross-compile mach. I configured both --host and --build = i386-mach. > >I get the following error in lines 318-327 when trying to build >second_syscall.s: > >as:{standard input}:318 invalid character '_' in opcode > >I believe these are the kernel_trap calls but I can't figure >out the fix. When you compile mach4, you need --host and --build = i386-mach. But, when you comile lites, you need --enable-mach4 at config. The i386-mach buildtools is used only when compiling mach4. So, You should use "as" on snapshot FreeBSD.2.0, or FreeBSD.2.0.5. Or you need to patch source of "as" on FreeBSD.2.0. I think it is best that you ftp source of "as" on FreeBSD.2.0.5, and compile it on FreeBSD.2.0. From lites-readers-request Mon Jul 3 20:57:00 1995 id UAA08713; Mon, 3 Jul 1995 20:56:48 -0600 From: sonoda@flab.fujitsu.co.jp (5.65c8/HUTCS-S 1.4 for ); Tue, 4 Jul 1995 03:11:17 +0300 id JAA01868; Tue, 4 Jul 1995 09:10:56 +0900 id JAA10502; Tue, 4 Jul 1995 09:10:22 +0900 id JAA11900; Tue, 4 Jul 1995 09:10:18 +0900 To: ronf1@ix.netcom.com (Ron Feigen) Cc: lites@cs.hut.fi, mach4-users@cs.utah.edu Subject: Re: second_syscall.s & mach_init Date: Tue, 04 Jul 1995 09:10:20 +0900 Sender: sonoda@flab.fujitsu.co.jp In message <199507030725.AAA19105@ix3.ix.netcom.com>you write: >Two questions please, > >1) I am trying to build lites under FreeBSD 2.0 on an i586. >I am using the i386-mach buildtools from jaguar I used to >cross-compile mach. I configured both --host and --build = i386-mach. > >I get the following error in lines 318-327 when trying to build >second_syscall.s: > >as:{standard input}:318 invalid character '_' in opcode > >I believe these are the kernel_trap calls but I can't figure >out the fix. When you compile mach4, you need --host and --build = i386-mach. But, when you comile lites, you need --enable-mach4 at config. The i386-mach buildtools is used only when compiling mach4. So, You should use "as" on snapshot FreeBSD.2.0, or FreeBSD.2.0.5. Or you need to patch source of "as" on FreeBSD.2.0. I think it is best that you ftp source of "as" on FreeBSD.2.0.5, and compile it on FreeBSD.2.0. > >2) I checked leia:foggy for mach_init but the dir is empty. Is >there a FreeBSD mach_init source or binary around? I have mach_init uuencode. following. begin 644 mach_init.gz M'XL("'L?5B\" VUA8VA?:6YI= "T? ]?_MS-V=U^[E[W;W>N[9+ MI8:"#I85F6[<]!9;5J]"&VVD5)-SG^><\_Z9=P:5I6T_RYQSWO/O><[W^7M. M<5MUH[@T'<>E(=+5 MIF]N=5X1BOR9M]9#S<^/3\[6<:ZL!;-A2L=(+_X&.EU9-;.P'NO%WT!GN!LMC"2U MGA&!*-+:8-#%_>15X)2[7N\1)FR9SL4U/0]5SW.1^D-Q1UI= _?&;6N"AD!R M\X4QT-Y[$\.<8% MP!%?(/[B=0ZXI3\JQO6,]GB\ZQ;KN.?F>*8=%4>ZNG5[9@ D>]9Z/.''+I;& M&C5C]3@V'<<^,-C8"=<+,\2 7"[ \6KQO M/ &(*PMWR#FBQ)=QEM_]$/[4P/#FUKBF?A@J?@ M=FXYE!I/XJR5,\1%)W#7 M!F\:C 2 Q51RXL]/$D(*Q51:D*:-M7>"&(J7:2L%ZMS;8!?<,BC-O WW8'#- MY!PC?",_AIX!9_Q"^R4<\N0)5OL*:R5DR4175@:9=JP]@*TCH6P37R*3&V 7 M[T[2<94ZL1-_(L23^,-5CK!G (A%X12*BKC@!/G))_.9R0)6_.P'2?*FX&'5 M>\3;D0L%4SD.Z)F*2UR.($LH5,W#,69*565A?IFRNOH)2<]2/#C6NK*RL>!<8[Y:CB4'V/.T:X(FF43NR"!Z7JTGM4T3@'H.R+RF8;:\&>N/V@?U"/ MDJNS%Q5[:A8M=Z<99Z\+M7LK'*$ M-D^)"9ZH;MGJZNHGG34X#Y=;[3!/=II)NWE5;?4:,_W(!E55FVNKH7%5=:VY MT%I0/-=B758X[]$%,V?.U.RNK#QX?T0'EU;]$%0Z:S?7E=>NK5A97FX_@=Y-]IWI0OGK0 M&3YDT'>'R2!)T&X)3,/A@6FXLGT&]!'__3B9P6T=L+FM?MM"\;T\U92-JBDK MZ)2_IU,*UH$]76C^V-2C;787SO?X<2;:^#&B/H$-_C4=O(8,-DX]ESD>OZ^= M*UC]KAD[.YN??;1[DB;&),,IOT\,>WH.$F;/4^7:#T4M-FXK44P MQ=3+'K>UWR:?P.O;)7:-MXD%N,]"-LM5.LO39);$2N!8O\W&1D41ZN(I=4DJ MZB;?3 99#P6=VYB L[_0;H5OXK=M[+SZ;)4)]#A!*5NA YMZ50-V2 )R1K@: M^CAS M"DS##N!8+A1_;)68+!U1,UU_/%G?*,324W43EQ-]44K$A.TJ++^X5=G^/CK\ M_9>I3/F1_$@VZ.OG5(.V; V1J=_108%I?EF4V,BWGE:-S%&-?)4N5QT\PO) >AJ;Z6'U3,>:0V;J>8DB2SZ!^A9?5%\% MM3GN\@O$9LIJ;$W=$\M0BH5MN:1%9K M> DM;$'YRG)PNLO,3.6F,FV^SBP[X3 OZ,02@^ T2J ?&Z@S!>J,]K.X@OXH M/6B+,3,*,>*,*2X4;P-H]=SCR8S",W 8,J.0HTXC?+G[&?B2 /Y:H?@ <-.7 MD_06P*R%TCCP^%)*8EGU,D(EM8R2T5I=[BB7]B18V:R.FR0M.)X0MK<%+'04 M\1_"S(1L*UVYLKR&S!1VGC_1>99<^G\"X7.Y;BF9X%3 MKJN!N*;-4"!LVT8T*, JUHZ*5BP<0YRUJ:)4N07JZ-B7K..:Z8;>+!"603#Y--Q),>OCF)1(M0L!4S MA%?4JQ#>_4P(PJ/_PE2;/TA#2L-SUC'%AL.]SX2HM-?^3$6ME5+LRB(V1"+; M1LEV-?@Y1SK\#3BF*.HFL%6R6;> _#\38K.J8>JIK3WW 2Y=;8FS&>>V=0 T MM"VLXR;+JJI7E4DP< M.L\3=)Y]+R(9)]M"T5A6(<-0[065@:^UJDYR@9BL,R 2T8TEV[H(<1('O F+ MMX]&4[Q)&O V:C.FMGH\F>D1#J.K559HG\NP*RRV[S>C?J*6O/)JI5Z"076U MR@+_*K( MY6_0_J+HQ37_&Q]Z@&L8)9T C0X+;X+/H4],KWPBC>8A9*_"?;QEQS?OUD M]?QC8'XV]RU7R=QD"BY"FB/?(!09X_Y\"W^K;[8>1)L39AGXV0;?;.*(^F83 MMU1XS.1J*^,7F[QY,#L_.U&898JJP9S00$3]:*@(^N;X!TAV9K1O=M+;1&'W M&&'M@OF!3@(ANBS3FT*V,CP:QMJR,91'G0G?O679-+"G??=(5:P7\MVCHLZ@ M+[SH.]<&,^>@I""2@20HD#D&+SX*9./A));18S+PES6=))_19 M,NC/#"YHC]IU''=5!BJY0)V933N_$A8*P+IRR\Q*G,:LFH;,4SE//#X.\UAP MD'0EZN=;$NF/F?XDT9]DXORWZYG0.4C""S"'!?%GMP$.:J#$6PS\>"P@./$3 MWT66Q/7$;0!:6"W*SM(D]NW9JG@X:S,RR(MM,HO^[V:,_SRE.HYP*6I'*8L$ ML=>>G5#S1>TJE>+$W7)IKUQ:Q]8J%#^[A9$O^:LR'VLH'V^NY-C_$BMU;DN* M[:(.4\',IED2@5RCVY)H$_?<2C@A6)+VZ1RWP$_R50 O4&Q))'TO=A-CJ#1L MBWHVF^DH+(@K;F6>""C=.UQ96TB*:@0_'@O>C+&!3Z3# E%-\%?(2=JG=XQS;0+XQ>,1X')D"SV/>EQ9V(7;--V5Y2$J M]]Y +!8"L4WLP+"WF@EVY+RH?YJIVIY1'JF7;"4E_S015;3!@R,#T\BY)D(Y MPFT5;6+;>N*VA67%PELH+PE1S>> G9%[-K)DJB^*D S_-)]SWA*(\LAT2MOH M^:G'XPFB4WU.WR:2N1F$U<>Q2]H#%L1W6+\1E,\[&9^G[6!\Q@8^C9^V4UXD MARZ2 XO\@@[&3>!DV.:VF&SN')--O/,6U,+=:C[I"\-NP9;(V+"#LB$!V+!# M9L-.Q@9I$6!'JICI1VE"\5F.ZX++S(1F[T8 NM7/6[*]RXE(SD$A' @Z*S7V M 2R.23!U3B(YO;5FU=$9P..^>)B(@090Y(2'M7!ST%G&-:&_,LAYQC4U M8W00!+T0WC[ )LQ!JV.B6]05BM.!\HLI9%.PIPB."SUZ[N:0HP\Z&0]\O_@Q M]5DIL*1-B$5HB]I"]O+'<:J]U S.A*VT'Q6M8,JD,X^A9[YDG((V$'XL>'

    MC&;ZO:BW,Z.PMNG^ -'BN,75P>B[*1<4^Y+[\<;"7RBV))"" M:)@+ZB.5RBH.@(.)((Y6H3@5G2P\&(CWQ]&FQ=_ [M28);ZT06@PJFP?3!$E MLV0$;#NZ6(RF6V8:-]$81)$ T[H_BB@9XHU!GQ?)&_YS5R3I%" MT0#TNP/&6@?(6+H:M,7BAEX< ">IW= #Y]0OG5.QUCF):SXM[TPC*"5LA].( M>@#??C=JBQ'AM 5\="&=08;0P SAR" [&')\EV^2- $[\?"JYBW6+4TRRK:F,J=15C2\3NQOIF7J:[1BOL2?"$=PL+#6 G8@7(OD< SF='"/;^8B> M D_S:6>2:E8#SHIWH-*\(6QZ:XRD2$:([W[-\FUDN;AF"T;.02!7TZQ@VH*; MRPZ"X;HQ#(8&"=]TLQ9ILY9X-7'Z[HIJ?Z0-A4W+ MF1)PPM]$<8Z\1L"1D/F!8TR@WA2HCP_4Z\7C&%2%84I1'&%*YM+DN*;#.%]1 M2F9A8MSVWY*R\?(QG6,NV4K :0XXDXB/XHSG.Y._LR%5JZI93C"N^1W%0BK3 M7Z:)#MBL3IY\8W:H_--NK@T@+9$@M@($,F I#&1E$!A?3AZ*D_@*(+1G@@HC A::_,D:4P0'J#7VCF!M5*OQR9A_+4Z6XK$[*Q$XD2:OAOG$1(S M^QS1-O&4@:6C0 !Z^&G8A;KC/K)?)9:CI2UR::-<:I)+S[)2<'SY/S6A\67F M4\&QI$>>8Z=LY>5B)<=)9[Y/!!0 MR2O5<5-/N[+\Q,>:QLZ(F\7.#POB?4:FZ/Q4T8T4(O;XF?=%>IYV1E?:Q8$1 MJ.+X=X_HH_Y1?G"?E&_J%YB@(+TMG24C%TJ0Y0DUX_ MP(WG^YM/TD2AH-MS0'8F#DH' 3(8UX2I422M@SRQ:V5/6X6M-LXJ3?<.RVV204^0.U\X39>8%.Z,C/LN&((C_=X&P3[&XT MW^EJ!=(^N2)-=WE6JM[Q UAUELFU'B+_T3@M]&BA!*";7(IYL?L14T7^+0^E M1D#GV2;7TZ0SG4X8D*9SK3>S.4#+[?Z*-A<9?+/UBC,HL8J1MICN)1"+QW+Q M%'DX=8'1WHT='J/3D-[V3FS9W$^\O(O/0V?8%V(G[-2!RXP(8FKN^(Z: 8/D MLAV4QW9G\G+-+S=3;7AN5X 52W7%P3B:[; M M+R;10&IBGX-\49VRB>B22V?D4K=<$N72!;DT MP$IB-)#G$8A0@5,W0X@,H_#@PR38GXXPHN_$*N'KSUA7K=/QYV?BDY1HJ\%8$G[1PYM;7'B?BX)J9,JXA=T4]I*>YD_KP<431"L_LR!M1'\ +JFH(OG9 M%3J.YG;U;^! U[&!N8W?8*FAA])]0_TT^*, &0<.Y"S9;62EDVVT%6M>;.1G MQZN_4CEW99&1CMM50;Y XEZS>!X=&TL\NO,>,@/*H7@"6O9M*ITA4 MBYE8HO4U+ MPJLB5WMR\SGG/:Z&"YSC9O@;P/=M%UB75\KI7>8YY^A,I[\^FA^89.W/''", M(*+B$9S^2.< +%O/H_DZH\**J]> L67Y@!=UP15,_=W1AG>M6!6R\*_'PY?X M^1.Z /_EC[ZMC"PN%%,#)* $+G^,FB'?P(]!5W>JN[Q7\G-9GDPB1?Q9@-DQ MY [G- KY W>!^T:815DVEX]%AD$HL()ROU!,)ZI02"!;>^^.SKNL_KO(QE2O MU6J =,R]EI$[MGYUKM6+,X$PN4O\'@_>CN RA6S<0)GTE"%62, /NB)_SWO$ M_XLD=3X!A^-"(&:WXGL[DA5E9VW+CK3-X6%'1NEMM+1M6D?B/4(DL&B4DI89 MRY)7VW7T&?8'Z&\.IJ_SF+Y>FAVY=(Z[X9#/VC(&U9:UQ;800BNG4?R#$35S M/%_4B__2RGWPASI]?,F SWJ& '@,ZUHY&J/9_8J.!/[ N;"5<;_%"X$LW@SS M@:\@F$&L(Y8M?;RD3?T-/A29A/)XVV&6H(D0UW\<"%#YCG==2E(NB#$/[9MM M(FD*P,=#B0B0,6R]%HC% K_$TD@.6UK^KJE_JJE_HJE_K*E?T-0_TM2/:^KM MFGJ;IGY 4_\/3?V/FOH?-/7]FOJ_:^J_U]1_IZGOT]3_OZ;^@J;^6TU]KZ:^ M1U/_C:;NU=1;-?57-?4CFOHA3?T53?UE3?TE3;U%4_^+IOYG3?U%3?V@IOZ! MIOZ^IOZNIGY64S^CJ9_2U%_7U"]KZE]IZOV:^I>:>J^FWJ.I7]+43P;7.;,N M'M]NL#<@KMX4XI(9W"OH?';B&PNWCDJ4&\4M\$2/=$>++;C:ET]#5C&N+MQDVDZ# !; MMLF4ZXQNP9BX9YG'T_(.%HH]0K%>&'%4O#U=Y_HFQ:G'K(/K&[,S PKIKDU) MG&.*D(,/6X XYR32$"7D)/6,%W+,F5$&;(T5!T9PA*?ES%5, )V2 M;%^$Q"MBEZT&M[.;O^*S=B.#>*LH/GL%N=/KL_91[O1WR=S!:UK@SJK%"G?F M#I$[L@T)E[Q7"G[E8WGF%\&=&"'_NDO@ST>-ZD-L(W_1FYQC" MB/0\O,Q$%LBTGE'3*M.;P>@MZ> _\%D[*+V=XL[+2.\9@ BE]_Q_R_1F(+V% MXMK'./R7NX#>RX[\QJN,WJN,WJN,WJN,WJN,WJL*O>LOJ^@]B.OU7=R#-S2$ M?J@W;C!E(1WDM]^[COP.\. #H;7NA&/8@EFOHBYQ]%=X$N1"L7?A<.1RK5'\O)_*)113OV*X@[(9RHV;30]2W&T.C[N9B+O-!'>Y MP.B-#Q'Z$PA:B=%")^.Q\&-HQ7]-"4 MYW(F,7!M2AZ#X(JAX$H@=X&I!(!"3@I34 K3)%EEO&OL30&X$?89W2^>!\>) MOP+^ZCQ@R\_[L=8\ '^]G=C0[/\ MET7.85(6.8:D+'(*"5GD$$9GD3,8F46.( :Y_ RLTF/ 4BN4!#+1Q;]+9["? M)+CT< SX[[PXDL@QQ%#1/XFV#L_AXJM$"2$S@# M+'!2TS *3N#B=JHWP!Y,!A+$#[, J8>W$QD^P W\?&)6[X3OH!R%:^G=H M2,?G@SK"3/Q]+6^@7/SV%!!.3OEZML?XA<;V=&MMSZ7"8=J>S_I4_R'A^?SG$IZM(7A^0\9SV_7QO/?18#Q[AHCG ME6H\YYLR=;7):CP/?!8"4X#T%$]83+_^V0UA&K9DDL\Y63GGP^2)YK1Y&)+UY%:MWHP)G<260GA; 1FSCK,Q(ZKQ*LIBT7XE8U MKIK(]:V*SIGH:DOVC9!4VR,&\>1GL$:.T9=#H9!C^E""PEICI;D09>@%VW!D M",SE[SZ39 @J%SY3[&C79\2.Y@S%CFZ?K[6CO^T,YNUU9*B[0,/;"P7_C$WP M]&IDZ*.P,E3QZ+!DJ*I7DJ']O:$V86>O)$.YP[,)8L&_U"8[] BO' PXY0QWCM@]@>%A>7 M8*86_"X:'2<62]&Q-ZE8X5T7Y5VWN.6B)DK^5&6+4Y!W2^<-DW>E%U6\VW51 ML<6>BX1W#P_%%IN+0VSQ*2T_0C"6(<(\41-+BBJ>9:#ZN//A8>K>NT65[K6+ MBNY=(A+=.V\HNC=C84@,\L644B52.+(8KP[ M/]5(Y$5MC&=X:)@QWJA/Y1@O[U.%/S,^)?S)'PI_[(NN'>.%U5>8?D)]M?$Q MBAM@S);'J*J"F">_7Z6?DC[1<..2*@XD,O9-WC#CP.\^5LE8QB?!<6#*)T3. M'OD>XL"FQZX1!T9SAM XT,3BP,30.!#S##CFFGF&,XO5V.M:3/,,YQ?3/$/W MXD'S#"]&'QC6%P4#YQ2]1\ MTB^19=2P)+R,;OU(PY]>+7_*Y[M+=O,?>,TER)L6(=\(P9?UD,^ZF\ALT3[1_B%R9[_/>H!R MY^!G,G>68_:X4,RQ#C-?./=#EWJ?"&G4_*% M%[^D/J(J9[B#KG U)7%S3$?8Z."H9"(]K_@_VP1$M M6)(NOH"3D3QB"OGZ,]*9YA(%2TIF5"HT.S<)EE0I>Y@9E89-3Y*$(@JZ)2,S M*AV;%@F6&43F!4LV&"!LL@J6.4)^$C;E94;-P*9[!SO)KJWX)IW =0_S',- M+*+^X8-$P680C9NT#%APM^(?_I#YAV9L3\#7&2>2_2_%DC>9P"!\B\]XM$OB M$>K9L=I\;AA?,7LY5:YSEE/EFK><:HXB/Y\_0'W&+>@SSOM XS-^H?49[YP] M3'[>_8&*G_8/%)]QR0>$GT5#\1GG+;^VSWBM'.[R]S5:\A_:'.Z#LX9INV>] MKZ)UX_O!MGOU^X3>XN_!=B\I_1YSN&%MM\K/=B:"D^WUK%"[V#M(3?3N)+^] MWETK)"/%E_1Y=Z^@:'/ZT=OFF!WO9%?]BK-]F1T ^5]&I6ZA>&@FWOX?"HHS M*<:#(>Y-72D'0VDKU<$0>570#:=+UY!P?46]5$JEKEB<3Y;JI(^*)/O"W<#] M4^)Y3;)1RM!=VO M=TWG-MI= QE4#RTEQF$1L1@[@6'.?-(P$F^<\!JJ=\ D,\:Z)K>Z7]%%1MWCH M/8T^^EI[T_O+K.'&_^^IX__W%/U^ZCTBGR7?PUUO;UFXN]Z^,OFNUWB-NUXM M%A,D'N:I95(H,I/PM\5K7D5P223SC#>9U+KX_//>%%+LYDL@)%Y%0QLGA,2K M6!8F"84G?16+BEMD.6WU6=LI]SOHSZEOU<*3AW)JFJ&\TM'Z:#>RYS-!>^Y2 M]GQ>V7.WLN<+07L6;V3/_I ]+Y\>NF>2H\R0)?[("_OF8L$Z%O MQG2]:.["A&47^82I3+)04OI- :D_'M".Q)?]X0,'I8T/$Z1CA,.X 0?GY MNX"[.(_@)@U/&<4?=!&K\AW+#\H=1W=)F4C\%R4<$PB C=31["2=J9_9KLY% MKG!]O+HRM6:GGE,LD/S<7PQWE%GCJF=X,Y)/_IA1($-$XZW_A5Q'O$M* ^6COFR"FW"/X8F_+_ MVTD'@[* M]\\_2_\39N ]/Y+B:DL-2O)?.*M)\E\-2?(?S5 DS=$P!A)W'J6)LNQS/U5 MB='ZSY(8;<60\B@5(3G^CN#\;U2PC71VH*\EV\C^,QH;&0BVD<7BZ?N'JD9H7YZ>V5X/[VC4NVG1X7QT\/DX@R43W.('J2Y MID-H I]$1IV!Z!V"&,*U_';QR#O(M0[07I1KG>B54:[-H=9OUX^'^<[I^7?D M=T[GWU%XUOD.X5G9C?%L3BC/>I\,S[.^)RG/X@G/#&%X=B!(AJ^3 T]:([M] MYC5AB=6^GAM9H M+:W/W#=,6IL[5;2V=BJT'NPDM*X9"JV)U==_9Q#^#:2^)OP;R-^\I4%VC$'C M&6^Y=YBZP?66K!M:WU)TP\&W"/U5WX-?;*@)YQ<;:V[H#>38Z^B&C*=DW3#C MJ6#=0'(=R]_4<'"45C<\.'68&)KUICK^?U/!4,V;A(?50\%0]E/7OQ\C/DZ: MXN.\2'R<%_$^WIM7&^SG^(@;2R#58.#)2P=QWAOHTW:3KQ=DGU:$DE%BCAU= M*(JP"6G#\6G=GT-ZM,>[F2^:\$;Q*=E_ZT=I>,#;T@^;4V(3]NB\FGW MJWW:AUW?W$5]VED$:--IXJB6O+*4[=-&CX?F3(CSFBPYKRFR\YJJW*W;<.X4 MV7=-E7W7I:^C4YH2Y+NFAOJN]ZNZ,=^U7>.[!NL"*XV3);MF[1;WOJ[!;JQ* M^JG^FS)<_?>Z6O^]KI+_UPEVG_H>Y-_D""?_B8X;BHNO91^:7M/8A]%:^[#B M[F'RI_PU%7]VOZ;(]H[7"']JAR+;&'0NNA#D*K8RBTQM?? MT-OV076VO_[Z.GNG;S"=/2:,SJZ\\WO1V4_X-#K[U[[P.GNK3]+9SN'J;&[= MOT!G__[X#>ELU_'KZNP;S3=TK-?D&TZME_,-G>OE?,.9]4/+-_RM_1KY!L=Q M3;[A)H,VWS _99CYA@7'E7R#Y[B2;V@Z3O(-:X>2;^A:?[U\PV#^>6V*[LUN(SQ<-Q3=6[-Q>/[RNH;K MZ]ZD8X/IWH0PNO?OR=^+[NTYJM&]$X^%U[TQQR3=NWZXNG=CP[] ]TYIO2'= M.[+UNKKW>F\EYVR6L9VW.4R>:$&K!MOCM-B^=](PL3VM587MFE8%VV6M!-M/ M#^G>>_/UL7W--T4+MJC?%"W:(K\I6K(E_)NB>U_5W);?;-"\*8J?.,PW16-? ME=\4V5Y5[,><5XG]V# 4^[%\RXV]*>)4>I$;Y)T1X9^=\,\DE"2Z&W8"_QR- MY $*>\M\T+NND3XWPK?,A[P;2:V5SV_W;B'%#K[DE+>ID5UR)>$EU[.DUD7N MP,Y[MS>RZ_1DO$[W-++32<'3V='(;KM2$;\[26U *$KCB^",=LKOXG:+/SF, M9[379]U'SVC_CU0VSHYGM-H\S#.J/BR?T?[#[*TTE' MD_JM]&;R5AH/;%2N]F>B77/I6.A=LV^Y&8MMR0]]*;[_V.TXGDW^*>.\< ME_R6,\\E@WV>2PUV?"K@[/)9SU/N24"_TZ"Z.4S#F\,?W(XWAS*@M'GJ<.NW M*^MW*.N?NI'U[PI9_X4)ZO65F$FZ42CI]LYIDA[X8/2$,^>+H-;HE%+PE*J> MV8S_F>1Y$_"1_WFU3QOT%H0;["XW"6]Q=S6I;W%WDUJ7=R_Y/>_=UT2OCZQNE@U$3?,-O!^98M"^'QDS7O5^).3>.QPFNIIE3)QOEC'1 MW1R,B2WA,'%/"";^3Y(6$X/JL@R5+<#7\HNVJI_R+-DJOY9?OE5^+5^VE1U# M(NH[?_"K^7$O:6[W[E/I'?)JOO^V8>J=*RVRWDE_2=$[*2\1O?-O_[3>L6\- MKW=6;Y7U3F*PWCFD>GNGR%ZV]#:H%=\&M=)\18?H_PMRYM3_LO8T4%)5Y\W" M@(,9G471H-V6UY2>L%6"-)Y63H(08 DT0;<0%FTE\G;FSO'(-^!+ZWD<- _D--"!VX' MRLSQGT^_;M-\>M;LBKY_F9I /Y"<#W*.EI*09-/\K[J/JU]-'E>/4+_7.D>]U")P0^G5+G#-#345'2\3]4 _CO$W[.$^N+\[%>9G+1AGG=>[S MXKS']_G/"SVPC_AQOXF?Z_-"4E'\O-#4HO>\4&.0%SV?#VF5.(,/O&B3I^*^ MO4G@ [>^R%%N?9SS@;\R>90^\,P7&5[-ONC[P*M>)+3[;7P$/G#KIOH^\)GH M<4/)H\=-)0$]YN[EZ%'@Z?$77QPE/?YR+T./F_;Z]&C=2^CQP4CHL:ITYI@@ M(92ES&:Q+%V[AZ/ !EZ6FBX=I2Q-V>/)TDU[?%EJW4/F7SEG6/?-_9KG_;E?^3R9 M^XXZ3F=D9JB-[X[46CU!O'GF7T MQM3G?+F9_!RAR?%SEINM6\1R<^\63VXFG4%NZN8=WAQ@\PYO#7AN[]L#XKS# MR\]P>8>-<2[O<._$4?J6]S_C^99'GO'S#F\^0WS+$_&1Y*T':N<=$F?YLZ %>/<&;![&T9\\]/$U[ZG_BYG@$[>:?X#-BI M.\_Z#%CB+')[TEV>'9]ZET >>W9S\KB)M^-MB5'*XXV[&7GWXV=#CJJT>/:[>*J!'YBF.'B6>'@LO'"4]%C_%/O_VE$^/GJ<( M/7X_$GI#:U2>X#W2DLOI)3I]LCOM/_1!Y6G2!/_MO MG8L\?>M)3YXV/AE\YJ?G23+_D_'1/_.SX.XZS_PD1,_\-#K/_$P*/O-S-K'# MAGL\GMIXCX"G)CW!\529YZF/OC!*GOK3XPQ/7?6$SU-3GR T_<-(>&KS/6OG4;36HM/[K]WFV4XU:>V/[ -N>!EDEHVA[>1G,G M$. N&2ZU-!4.G-RTI&GCDJ'"T+BN"4XJY?AX\C*3=<[+3%Y[C'N9R1UQ[V4F M;E+EH?-]DBX<(4G)NTP>>/;O/U* M*;A?^0J[!M4P3S:"]U%> \+'R6TQ?WO1WV?HN=1XE/\<20^ MA71?R*L(N3W0'>7_V[V"B?@YRUBY%=:Q?1 MB3M=G9C:1?CM5)R\/_$V/T>UGGU_8@_Z&J5+#WXX9=U'#>BZ)M#=6-1_V%I M^.M:PG"+8([V5TE!#!ENWH"[3]EH-VU:*$5/?GU<=[3_L)W -^E$JM7$[(C4 MX+T_\6+"E* ?$_NZ))37F:@H'6K[M)[ YK\IK?<#K7??3]+?Q>5O8YZ:^&\' M*I_N0.K^V,]2W^E1=Q&U-T?&C])_>W>'9V\F[_3E.+Z3T/5/9^>_+0K[;\_= M+_;?]M[/^F\3!/[;[I'X*^\]X+'HT0<$M@7?^1O@SW_E;0^CW1R?:XPC4P!K?2!5 G'Z^L M8BK4G_M5#]7HL[?O_^&N:.LA]Z[HPH$#A:&8=U,T?6U_W+\I^OQ:]T2W3BH< M.E >@Y4GE*)W-\YS[XEFW\"Y "X3A5E>O\6!3^P[=&6# U\7:00GL[Q^\C#>4YWLOJ!X MB#0:._Y/>&?W^@.?L.5SH7P>*;]J*UN^#LK_AI23FV^@?$+QT+J?S44GL[R^ MYP0MBSEM3\+WID^;,V-.L_NN]O+*V++*%_%NC"6Q@Y]:O8\MC!#R\O M?#IG;;P<73HKWG_#XH;(VMC^7S],[D^$LM*D_E505HXN/OC>F%)T#*$J:5BR MM4Y-[]8DQ3!T0S)[34O)18*%23VE>/=]E.U86^7NST4C**V)]7U0G0,_83'' MX^K!F&Z+[?_Z=AC'=W$=>OYT=N:ML^%I89FB^-+!827%L1BI>A^JC-7;&=NKF?><4]NRG"WQ?6#(WIFHE7(XS9L0J'/"^Z(T4^8SLR^+EDR'\]'*W] M1#3BW:T#PWD'?E9RU_AE9.,S7EHCK6!OL"N>_.M_^ZQ:)5,'1 M3[\^-X*'C6:?!WK:;B[^L>_7B#H0J+\,*]Y!*Q)$Z[W3K^,I27O&['&HUZ=A MO5>#]59'2+453C7$L]YG*._0IXG<=Q$K34GL>ZVUVAVKC&EP+JE(E'$'O=P] M>>S::''-\*S/$X5WBJ$2+!POO-Q27G/AXX5C)NBSQ4EL4[%KB MI87C2]=!^'FR\'K\^%^1N[J&$OLN A 0-+'O&PWITC^.Z?MO\BZ^Y8 4+:TY MF7AVJ#!XWL'?CRT,CBU\,%Q887JJ#+LX= M?9]!:>.M7^K[#!B^<>V%;94%M.%CJX 44 J,G=CP'?C>5GD4IK&B\O V>MG. M*7;SVI?/->3.U)6-R]I65)H?(MJ 2E\,2W[Z&^0#OJI;GYYK6!E?UE;Y_(?D MJA1:]3PH>/$#_^K"0'_QDHTY86@=!?+GI%XCK?<%IW#<1X)>Q?4O%=7O?;I. M?6:^QQ[DYUMZIMY\W;N38OW5M?'M%C#6L0UT__P"_#&67DVU9+CXQJ)BR_#, MPZ?)G56)9\GU+U!2^G-$*PXU')G5,FS.PYL[AYN/%#]I/EA\H[5L#[3)IG+E/QQKHP5?S66 MW(9S?7'('4UQ,/$L*2M=0L9,[JG!EP&])1[SK$%S8O-0ZPIG#/O0O6J:M6;8 MO&PUS.0*,"6,.;D![W\ZV/_O]OE%,E7R;JE=BI'.ZMV"6O"_K0C*26>",M5;Q# @DV[ TMJY=H=6/(:>5PS21P!*/R75!&+:EI0" MMU4$=Y<9&@G"D81V,N/@!4!>AU*W;F=34CM,LC. D9&-5+=L*#@SGU%L3>V! MAA4%R&M;&5@R54YZ Z=0%^!0C:^L:G(>UB]OJ+*E2&DUJTA6;UZ1P!M/ZT9. MMAC021QZ@2CMWD^ 2!,[2TV2RUP^)"?TDE!6N'7>"O M#D/.<7A.J03\;!+"&+K6P>$L;9WOX>&0:O6)>*9EV$D+5P]&P,$M79=RLM8K M994N)0MZ)0U,D@.>1EG-RU:&F:!IR4"BZQ8NH[3*R%J*Z:]9^IZM6S*PKS\8 M*:6:G8[T*#U)6*P Q;P*E"&Q<]N$29\E+J&E:2I"_)0*S&ZAW,"\D4)*+N_H M48H K&$H%"@9N@TSMG1?/U,<_(DH'L,[S(#3=]0?=FPZ(1U0LD?-V3DIJ^94 MMAT!E7+N>59. JW6:#&Y2US1'HW3+)JQ&&FB2$B-8:@[X'P8OZ@MJP@PU M(-'7P))H7[9@(;*N^#E-T6)% R%*6T!5$QA8L8B4R+L(4JDI? )-&86E([F%5%,0+]I2VB%QS3Q-0): BK6SCZ )+EM"[!A5+8&DTAFN'$Q"!R!*"UETU0[L-WOV8J)@V)UOZ.5: E+*) U M6&0!3EK.J5F/A4T[GZ=316J Y=&3>M;!82ISD%!M!M77OJ$NH(RNJ!E>8Z(F MZS3KC>"<$"D_J$'"AS!5#6P9RCC1I'1@#'X.R =&'S%1(K*L"D6#95J@_LG, MF?7 90.](>!JGU"R9:$JH132=&VZB]&^&@93B[;,2A.U'60);AFZSX@&?QV; MRUM-B@D5[2R115 .1*G+6D> P1P_QZ,/%+#P=D/O5& 0:EX1ZC%.:>'DIJ/C M0G6CD^%B3&TVJW3(65 U2J=+P:!2\+1!5DE;_OQXK5MCN$J/DK0M8G+H.E . MX:3*!Q$VDRRK=WI6[53"?;F*W#2')ONFJ\[013A)0PW@167H9X)-4),J9==/]X"8R#7PX8/X98"O127+<*.PW#7R6"L/=.5#O M*P1%1XLX'1D%-&T*B%(#R9&.7HC[3 ]%T;INSG48S:[:4;4.G"5Z[P8(DF9G MLQ+:)2E<@Q33A8=(+1M&<#G3=RH"W@R/[H5WT'N7"EX]50(\FDMY[#X,)=& M$ZBD(=B'Z$78F0L1$!X9.M6,7-Q)0DDE!$(W'*-!"%' H^G&H-&SMSQNDE@@ MTHNJ.6(%!#;LP#)1J1:&Y6&DL*(,X[ AM /%3,;-.1G$Q&#:<#S">CBK]7:I M X* ?'TT9&\E&UP7(2(62FKJ#$BYFPE>[>:^V7)=R]+%\Z66I4NO7^K3 ,(V MH G(,\U\D.)4 .QVT:%HGHIFP)YHDU:0E0)@HAR)AB-JGC$U#!+HU+3:$[)U M@D%03 X$K*):) @&%SZ%,IG5]3R:;&20+$GEB"H8"@ZY+JZO[YBPCVV+L[$, M*&1;!=.A>3&6$A E,_J>;0Z54FT(;XYYN$!C,N-PPV\&).8756<]1T-934(R M8((4*,"D#3(-=FOQC.LQ3R!;2D=OH*;;75U@CE@'42V2B1( ]'2:1%X,2#QZ MS.'0A3$54+,IF5D6"DO9&-9B"B>P-#R0$4<*0C8/"KU?GL>O1.\)!I(WU%QX M&%A-, ":]%&[< @!2:=@\:1MD_$I'9^ 6&;7G2/^I?1D C'M !)"C!E2D\R M:YMJE^(E4!D@X7L_6<9H$X12F?-C(P;DY>;"@^1"/@X22*$Q,)(Y8?(Y#(AF M@(0@SZ@H/1G9-OE&.;+N?T!]=@4(/8)G<:(0 1=!=O)O"#XEZF*STN1C$!*I)2<=\'W8, M]BH7PDHIZ.!Z_H998_A^]M;6PGX>@Q7(W^94$YB'AHPU4+D4+H)G\6(-:68PQ-3(ZO+*?0BG9 OLI(0PWB%:=X,10R,:6H#/QQ- $Y)%NF*92 MY,Z\#K92\DI%>%ZNN"Z6 K-W1*P>&@165@86&[1*73S7#*@:W8$Y QIG2!B, M&DX"1.+3,=LL9VG -MUE1EHH_>W9H\X4HW9#0*=W$[,(T3=-(8KP0(W1O!_Y M+<:!@->RH2LY*QLY,8K3QBV*P,JS>,F\3;1736^!1<:T2KUQ658O*L$\ZR_Q M<%6K":;Y)K#HN%4F1-!!?%*+4AMM%!4K@S]+J-6S7Z MKK,2F/>M2S4G&<6Y$"Q&IYJM4=?3FF(PN)DU:.UEP\1@9%"[!JG$(M1#(WIJ M*G ?( P)[FGS4&;;7 !5NG!Y:C@YH3:4+B?+%AH<=4[10($CP5!5, QQ"U[* M@57''M0QNK;6KFJIFF GUA8U#BQNXO1@LN(FP(D+9M \2/UU$:ZE0$/RAJ.& MH>3="-;W#<9E;&#*AMC"/(W?3-IL%J2JN(19*%47RF9&IH$[,0/=*7\?B]'! M*:D[@YJR72'>EIXG48U?A>SGNO48KJF#X>RG>VBHOEUR+5X0KI]2+)KTXN=(FW3&+VR!)-K)S@,;ZGB[R[CZ:3FI^#5\ MRC+<)V11LV-Z1D%]50M*U34K5JYDY773I)%= J5'&LA:M*K:]04)?>08!A* M%XJOBQT*-4P-U>&VQNZ_UQJ/+PX!E214*9H>DNMV/=4;*J3T%NL ]W!BL#2E M!@0[/+A <8C$?D..9@E4$JD.EZ2\R-<3=9KY$.@FCEBN[N'% )?#T'O=8RN@ MH:V,)YT"D0! <.=Y'="AZ#VQH0 )D(FX/R MFQ0!,"4(\\R1:;<+G?5Z*([J![U6%\U)8,"RT/)ZR.+S^)G'O]L0J?S9C9%( MN:6Q=5DF' 0&ELX;5H]:W" MUR+VJ=+*X>*)E8'S\\M*E_P8*WQ:M2^?>;@P^PU2+[$?/P<*!Z+S"M=$[-/% MM_H/6)/+3?V(BVU"@Z\-]WV&/^T_9-;]/!*IS*#/Q[$=X+GUV:EO-^"5DH/C M\ L^AE7IKU:K!(WTOS)6NF0(VND_;$]Y>6M[0V1P'/[$;^2A->9/X9;HE-N^ MDOF_]KX%NJDJW?^<)&W3$IJ 0I6J%H<.B"T/(3XHE!21 ST85I'+8A !!10 M. =0FCXFS97-,=JY(W>X]\(,<]4[W!GNR,R ( *F!0D@8H&J+6VQ(..W_[VZ]OHX([66>#0&K!4Q+; M.(_G<#Q3-1CM;]$_41$:K#150Y[\N38X59/E[B7_[-C@(CQKY#RI?]T]')4^ M\^Z\@GQYOYKC8IRS??B&B,X *W&+?0GFZ%D]I>6OQE-$# MYY&<8IP\M9CC;(ZU.DZ\U>;)T:5Q69T>'8D?YTY.JV06"A7%>/)'8UC M;1JGW^#6O].N?W]F,K&T.X_8^SL[A60I)S5/RDD+UF5U@K-%[_!X;B>0!WG) ME[?CZ6X/'@ +VL>!XS&_'9$-Y>OV.OS\ZCNB?,9Z>U'Q9I#ZHGMBZ0"_NK!S MB*8"4F\'$T.>G+:0GD_QY-"#,)X<2G6/FGVP8_@Y1O9(H?JCUV9RPJVNG&Q3 M3B8&FIDGMRQ0@LAD[L8S=],XX18I9UJ>O _L/3G3J"DZ>PC?($NI2#Y4_]%! M:$*SW+XG(O7#WLZ5#C/9VX4ADJ4]OU@N5(YZN4L3B^5#$N6 M/C]Z9>*$T5EI(Z8N7/'LPN<6OIB1-G[,V'%C3)E49_>T=(UD3"<&\IB&/*4E MBW3D>0-98VQUDI+=-(*@_22L>F+QB5XZ57I 9P#>7N36O8 DG3U+C'>)V'6T-F&!*CS9. M4 ?-LF26T'[+/ MZ-4>Z8=[*:Y//.]'\_%,;)PJRK_/<843XNB5X-T.\!0"(;7K'TG79;FKUP^9 MU"BJ2-W4JB;QVR>BSO_I%%VM=J/#;E )M\)_?K4&JE(_2BKO3'9/._X4&A?) MZD=9 RRC]38WVY2+]387ZNWPIUF]S67U-C>%/6@+T+\_1U?5!&TD%]I(8![3 MUO[%D]_""\9L#1W4+)*_R..XQ .TD8I)'C,]H2S9 PX[,(B28CES'IZ1U^%I M-;?X,*0*$VJR!R -]D"QW$^Q1M>C*CY4V<@/:/^KH&DR$#*C)T'M,*(S@.\<(L2HE1D[#I- MBE)\@ZNK29G6US\J/,6))VX+L+GL,4I]+;QN?5VY^)F5(@SNEBV@M79L=*W-&CLF:R*MM@-I0+3= M%>!9:/3A^,VZ/&C0>:P_?R\^IHO!_LBJQ0X>2 9DVA1K'>DOUSS. M;4LI338]I M2O6.-5!E&J5LK2\9[::+5OZ-2RI_UQY(9 M&RLG#'6>%%3KDL#=T*G$@%6PN_]X#XV9GL[OD0,F/Y7@\<#UZIS[5PA#RW7W MSQ,>\MF8__M7"ZGTP+SRVXW-..MDUA&?E7UC]=Z#0;_+05'X)G>+/\I>"QP+ MU>O%_#QQV$4-I&3RI4'[NV^DT*?BOJ=%0\5:?B1(+MA7[D%>EWB4#*1'*[O+ M)S3]3'*XG06'&CH8Y_H?+LRYHN2'(87RM-F4?9%#/GV,/8@+(%(( Z*[=>@S MXO9C<%']>W8).]C:L]N^JR2ZVZ;]M8'VUWU+POTUZZ%CA0/2WC-WT%]\7J*T MO[A>VU^4/HFU6DY(*\R3%]_:/>@HCJ28A*LSO0_D,0V[#\2NE2PZFU2LJSCW MO8U8=]BDZEZ:.(N=[EW'H5>>M68M[M,6]'J=!CWLL>;LH- MK8:"?)>XM4CFU$Q+B<[95*HODBLMR'F$N/>0E)WF'=G V&;KLD&">&O357J[ M1>_M"_@74SLC&E ;-^3T6I+PD_(!CFM:?=4K2"-/I)0=UPSZJE^AX9^IH>-R MXNH^,RMJ,M?U\6X'D\K+$'GYJMMG[O[HV+%C76=K+JA=FG_EW<0(Y6_7J- 5UHQ';?T-CV(,]\**;&*F>8 MPY2)G'.U8*%+5GJMN#E5LAN<3:O[Y145%.?+'E0F-)YVVHXK2<+(\L&.*T K M+!YO'SXF?,<5H-=G:/$-I1<$DBK&(=4&S%["+4DJS)<34SD.\IG@105RE5D]&[*C:6WGQW:18+/6&;C9LV; MQ65FC1TW?L(]$R>9YCT]?\%"&S<"-_IF1)E/F9HSS9S+97*9H[G1W>MO95NJ MBK4O*"^+MG,*<*!XQXL&U!N.7>V[N9050=/HSYA6TL!(DL"#39JALSG.#K$Y M+B>)P\"+S?%2,E9>2UTQ9 V_#8B_)9^+4A_AYPY M:-8M@4JJG?CN<+TJQS\.G M\I[F!;L;P/7"[8XZ<%M]@;V[+_3B)BJLNJ^ND]9+D7?WI1N/>SN$_9D2__8+ M+/X*Q2SDIEIY3X.X/P,\=9'CMBAF6RZRY\2H..LNQ7; %?MH4>F=LZ^%RBW- MB_]#]BXLZX3C\D_%>T(A/QX@F[$B@8RH=[W[/=:Z4+WR_O[[<,)"\D&31)L(DQZA M7T[]3[(9(Y-H^*XG?U8G;6!1]F>-28FRMLYQ)7%5751<3\?&54CC8OFI\&8J M,6.P[VUL7\VWPNF.^T[S;E6^7*R_,'Q2*K2\( M> \F*,6J^)?HH[,F37@07&F1K@_[B4N'#?#A '$9: ,WT*)WE:$*I\UHY]A MC;HVX\/W-);7!AI0K4$80*.S&*09X!^+W#+P$$UMT)**3MHZ4@)$BT.+()??CNHCP07SDA0:F8BE,8 MDE(WJ"6%9MAB:)GB;]F;!RC3*\*$QHO-U/[SUHKS9C%!28K' MB:3==I[CWL?9(6]I?$R#B0EL;CBP%.9M>]B;6?%629.)XP[7AFGP5L#J3+YK MPT/XY7)AN\MG5 0[S$-^3!S_B2IY:.".@VF,)S\C)+*7Z>+#CGT83J L6=J M?DTTV+*,W69*1NI:C-N-VJ<(9;R^E&[R/C5])NQZ87E)T/70M5#=AI2Q=%K\ M^7([34H*UC^/>M\TFB2=@[[P^M=PMB-4&WA]U>^1"F]V%_>5/LPF3F<)Y\I& M2_1%*5>Q3ZCF\L*S+$NNTGMYU!BH]+_4G<.C\CW"OIWHV^3$1)3W)YZ(]U&^ M##K>*D^5*.4=M2KRV4@:F<]0'0D/[:97[)O-.CL7",Y*3?!6:B(Y2A.&A^K_ ME("T 3M(N'VC<=7WKO487*O7N@ M=/SH<0: %^XX'R)OQ;G/*XZJ"'UG%7(-AM+.T\8<]C^>23E)K*U]<#[$*+C2 M&:RJ%"P!F0/M\N7T_O0R4FB:1N(9N0\-3=2QWO4&)(Y5(^]&5??ZF>F6J./ MN]@)?/-'9XC)$WW"U&*JP&RG?3S90^N8#*2+T#=>' =U)Q>BK MV&>'[?6[P@[Z]T(_RBD_#;OH,T6Q R&3Q M[]/1QGVKTN6(_7V#POS &,W/56'1,9UVI&/JJ4IHV^<:'^1\D MS)$(74)49[Z>"@[K-J#)^S@_HU""[--@"V%BFF!PS>9CYI1"I%8)B:[9*N)" MQ](&)!O9P%$JH8GIJ#V>N/"[DXKP57KGZT@8*IB,W(P6SB;]JQ78#5PUE)E1 M7_&$)WB<)3;0'K7#$#-\H*.5 KH*T^=2>/AP7$N'#XX#[1!(^3X61"^#CRC? M'UT,^ZYFOD,YO<>U(8>.7B -2(Z@.2H0_:L2)C\RBO$]6QW+?U7"U"XK RIF^.)-]\8;=_^*AS/BH1NM#7_7=J^$/$]7DGE M9BU-C::W\K[!--T:"?5,_(].4TM;V/>6^"C*=1[B12-K1R29E&EX>X=W5APP M.44JT;]Z ,2JQHLM3A2*3GM19IM6T9&M=S:%Y45.Z!-F/.(@3WS+>;K,H50> M[U-JY)F>^,^9<:]E'#4L'A=):6><0CT4%68BX5HTC'#3_@[=HL+[PA<.[[_C MKDLW[YYN/9(B)NE?^Q;[S1M-_*I(9*90XC&>_CLC07ZI MN;%RC_+]UPMAWUN9[U!A,^&,%&DD%[YXK>H8 D3+=_K7KE%NSF8UF'LR2\-" MX*W7C7Q1)/*1FBAJC*0%"LVR_$>6Y:!(@*?5/YH6C=ZP[TUJA1:*T K=@@J+ M^5QLU9T6J13A.9U<(!AF@K=9Y&D;W6*Z7W)]&0OE*U4O1 MC:1A0@'&E(#^U7?Y& [M_3?QZ)S,PB_@A!AO8MC;_*Y\!H[Z@,M<+1I6XSI3?8VF;\=AMLU34O; M)+NQRX.E+^23T_Q1&O;0"E.F. AJ=Z1>)U*Q,>-S\J!Z8./%2!\I&HG5'XI5 M,OL/<9E!L]]D]:_XQJ=J:9#L_HR/I9)TF0G7XQ] 2CD:[5*N)U7$TL*ZBNGK$;UVVZ?+ADTQ"U9.,\ M#*3,.$ VXW,]_=)DKN/)*?!7?G1&Q8',=8--WI5#UO/KXJ?DFKPK.MGXYE!\ M9BY:#LTE[1E^UUM[K\6N5$7V.]'%,\>+J"_X?Z%(.J?3:?YR R?V*Y8_&:W, M\>N=O\;AH$4G)1*+'_\%)'B^H''4:,$ ?*F$9WVW1?A!+XZ1;WVK MI033=,/*#-.95<,5%_M/Y[N/MV#61ZFIGIYBFF%TW[]AFQ7N*Z-)6OGPO M$ ]WU0E&R1QX**.66-NCFIAK%D\LN!.):E,_J"/M)K%]I5HRMP,%U7.-TB!3 M,=*GH8S1IT >DAVFS]Q,A3[B&M\#2OD#?1I*!_=*G[("WR!R($R/$Y,C],@H M:1>-Q7)R.,"?*)GL2:@K3(6_D@5^PA.OA=."]H:T(4?L%L?W@C3>BT7G$/JCKM.,$U]4( MU"66#LIIZ'T5[#LKZ.RT&TDC^;:KT7&*ZVIR=/%437@UFF'J"O.#8D=0;)?_ M8,(E:3^0R!D4$D*AUI&CO6<0TI-UTB:9DVW#V\MM#[27B\8NLPYD04Z,1V7@ M0AS=S !,(_4O636#<=ET0QG[J"Y=F M,^X>S,/UU^'WXS9/R"!Y6$,>URK7."B7.I ZJ<3?8_\)!#I0FJJ1-$X,E:AP M!ZB1O?>V?RBT/ZS,0.P!UQRC4I@-(PFXJTY6.E7$UVGJS!+7D' M7#-UKC*=5&1P:3;0W1-N;5YQOMQU/ZW91?*#Z.H,3AK9 ^31_<;I!)+4WFT_ M55@/--6:;<2]-FXM,0?VF%[]8E+7A1-7H-W2GB'KB,<<8+<>\&50N4XL#$PQ M60.E7?FRB#),+5EA!&JBB_V);)>E(YA8-LIQ(+%:OU_M<-?EY2Q)*I ;J&-( M8*[I6NF7.;ZLZ/[^0)+O]JCO:'];(OY$0_E?25UDZ3EF?Y%5F^7NJ@5A+"AJ MZ7Q7S3D#?G-!J)-N;NPW MQJ)>PLNUJ##^,:,GV\!';;-F]T<4A_8X23D&4ZZA3$O ^EM)#$@Y&FFF 7OB M(@.(XOP)8-ZFF5H[#U7R!0S0'" >AP?85[M+]QJQG#=]O#+9DT#KID=CLI]? M_8WC@)&4G <6XS+^DEA;'8>,1&R6+!TNW:O$T@#5W5$+ E&]Z;C><9%-HTJ6 M9OTNZ&ADYQ&A1+*?E\1ZC[F-]4?Z70G0CF3]KH%\G=K"85M[$/^ *2!-#)K&YFCLDG6.AL9B-<9V%M7[X 1DZ592J3VLO!43$S2 MT'!<2GBQL;&@BE0V,A1O9PC%K=^5S!^62MI8U*?!([&V861_ 7?F9HW#7*^1 M+ TFR.'/!Z L:VT'QN02?F%TGBQ+=QP*.![DQ-2'@8O#M]&75!VTH!#.E6F9 MG7")^2#Y!FBEKH7N7MH#TX=/_(Y6M3 8.A>-\_DG>9" 4)ZVT+U)6FA3-4&5 ML$*:L !9:*>8NN@%J)/R<9"DWT C94QQ M3BHY/5!=G&$UMDDWKZ$DW_OI\U8X0N>;+KKWJM5)$,86*02X .0/)!;K+KW MPI)&>+T_5Y,G+V2!D,=TM!/T0RMW&??C=29V'; ')";(-@6A?HOW$W,;5&,H MPJPF:&?Q>+W)KLD9?KZ!F,^3 S57#7B;H $K>W]H1!EU?(/#W*Z!ID8M;60* M-&;[>1LQ.6HT$C0Q:_N*W2:Q8Q4>]X#PNH4#OGOU"3Y6GV #F=!ZLL7OJ DX M3)SP'4I%T(T6LY;6\ /[[W![\G"4;5SKH&,).(^4I= ;R_QT<^'*&/Y\N*L! M>,AEH^/R+>5W[.$X+7?J"KU FSG.[;[_DVW1=]2T.2X/+;]]SS <4AXE)V@= M.'4.1Y*WQ+KWHTV+V1_5W^-X&!O>0WC[I)0-8H?*)6@#TM!">2\6G.==; <9 MEW$3=Y(CF%0^X]T^U( TG,(K@]HGXY4/8L?*?E)N((9D"/N/T[S+MK-71(>&\D2F)Z#OJZRH4ZE%:ASM=9"H"0X#Q':2 MJZ'%B)L^Z2P%U#7H+GR94?3%R0CY91H'> *OGNFLG9K;J&1V( VE+IPT&8Y] M:M7@CX##2Z*!Q.^?@&DY@[<79OG&A,*K/' <'5@,9+ D0A-LEZ;]"7*QLQ-B M^*;F7%Q&+8B$9"#Q]YQZB-3WE-"1,G8482/P^Y:2=DQJH2S1#QFXQ4AH/[F& MD3E0W>+X.J>[[)::5B-O[HB9H0"C#'-;B[F]691IE+$Q9K-'^_OLV3IYPX0M MKP>#GT^>\->W)T2^/YX<,S^"I[N@B)4-M[C]ECYVLX>?/6B[@FP0<0>6BWV' M?O\@QY6[]2]?II<6;:CNB^?4'@-J5R3_,)[O!17_)/R8L(J59UXRST7XP6XV M3[E#$G=4@' QU/MU]* ?++P@.(>GX:BK3!P.[T5_N81]]\$ [#LJ)F<"7Z0! MZ:N>ZH,G3G80^W:/LS08VG.X)O1F/D@W4C?I]RH'V5.QW%57WZ+M*^46K_/K/$CA^5 OS\> BO?24H.._RC M]4[9FBD>;-'>4K4[CDROL8-_J^?)0+I5P2W;QX4*DH MX![&'GJ\VABLW;S]X+NTI[UL-U>3TSG@M3PMG'+^)-FP)G1J,&H\<]50WB^< M?G2$KU-,%G?Y7B6,U$CNC7E*(,.B_?>/Y!\=X'LXA4IV7'FXE4W_+S.H73UE MJ?Z%0J+#;]8[48R&SCW=87=#>3OL>SDQ!00K8M_AW9;8;<('@B.BUF.NXY32 MIK0:*6@=_KM%7=!<%Z:N$N7+ZQ4*ZZMCB/L-(^[J.:Z'ZBAMMTTGU!\6_JVT M[ >XC,3U2%Y=3%%^*5EWC+1N0\)H*R\/F\5Q97T@1_CBBX/^TE+OL-=QPFU= M)?4X Z=D%J^"9.FG^8++YDA MU,.0JR $,&OMZ^V^WS0.^M?/8L]4(WCK%[H&Q5' MB3^]'6RK?@=-X0'<,U\VBATBN0.)-6#+7*!%WS?GXFU1>$VK]^'8--3X-?JJ M9WD\$^/P\V7#WIU40IG35E[08BR)$(&C1COUA!^LR[V5R):W!VC\GZ!3L 8A MK/)O*%T1VBPJ@;UL*=6_O$IYKRY=-02X>3!XJ1QX.]TJ>C4B?] \]1>63&" MK+B:<7]E0U16Q\=F%;L+2#=+\6WO/H4IODYZP:C%*K/DHCLHDL:++6=#4_TM MC>*RQIHSM8U'P"+B)&HM8')L?Q0AK9>G.Q;QYD6+OR!?_B4(*\T06PD>$_;N MBE-R&/+'Q#Z?IJ6AI8%581P%'BZ6Q.U%?);/Z4S2BYK>X'+VE$03L6^3GJV!82G-R[A MVR;'P12LUZ4_R7)'>@&HU&0?IH'8FR.BA\)OZKO.$-IX)"?C;,VQ'0<*,Z7 MKSIX6MR^@=W\=V30[#$>2>P-DK5#;6UW/1RLO*R"6F#O"P:5M>,T0 T8-^ZY M!T=XUG:>LE&>\F%[[;XR7Z-%D:[&H8F8/LKL^@]AG4/ .,W&7#\R1Q M4Y'\FW::9\F^M3A/KD6B'BB6C_IP$+S5<=#HH$GBR@8RYE"$[N1;OZ84P\L M[VL",""THKZ6\/\@?47$6M[ _77 !:;(+YVA? P9GR3 MQ3$(MTJ9-TJ/Z3S9[" HI#9/WH)1UT"I.X_8IV/G6*E&\OJ!.:Z&MRYL-'KX M6 (?2WC)OK%87DH#WPB>YW]-;YMSNLN?]85. *^$L(/B4FJ,[;6R%N7ER.#&RZM[\"L#&C,X<@0CZQWY# MGZ9J;)7$0.67E/G1NE%Y#83>V*5B:5-X9RAW#?97VFR5\@E M4(I-2RO.'&&L(TQ>R&G3TE>PW'Y3NFID2T.EO0T9*&9$#NJKAES!AAG#4P

    -]@'9KF]IWLL]T']U]$9V;:@)8#S_JTJ8C[/'R*B#)(5SMP%ZZA=1EG>SJ)&;:26Z+'DLIZX,PH,3)50A-OZM6_[891M4=? U.@GZJ?QO& MNW3QXQLH(E)7(QN(N4._:Z)^UXF,3Z'4^:_Q""$8^J6)-1<-^EW6UHQ/R3=\ M+;BEQC92K+(1O<.CD439)+:MJD:%)"-8,AT' J:KJ_JC25_(B>]29+XQ@$)@ MK@&/0TMXU?-ZVO6=ASR\XJ$B=7ML-D@7SF?C';9&G*2*R5,X/\1ZRU^Y:6!\YF(<: M_%]DI_.4FN&?/"]G^?S?O7QR\E\./R6-6']H\M47?Y-WR[13RM@Y71EKIRI/ M8W9HS-WCO%X%IYS72W4\D#H?M;W<+0W E]^FX=SQ5,U^NOB!4R KM 7RUO/ M3>*H0V65"&JU?8!'C0;*9(M/IXQ7U>R,K$[I0J[0)7"#MJ36CIP_JK27,<' MD 6_20<[+T:GWZ^V!EQ_'@OR#1'K'-?2RD;MQI+*:,?;Q)'DXKK*VOX:-O@Y M<>HB^::/=1T[S(GC"3KC;:F#N$^=RSH2'N&4M%=B]3=<@ZAQ"@FBIO.(<8]" M)IN7MK?$/9F*_5)+W )\UK3$/0?/TY:Z,\#N7&IW&1U-RYMBVRR M&=ID=D=M]NH7M+A#9R>?A2I(Y:#Q'(,STC'SO?N8%0QJJUNUPH>Z@01CQ'K06\SK<"X3!.GY]&QQBX:.._^ M"CR<^1H<^_*Z]U]F=U>#<"^IQ9@@5)TRP-7B;+]&N%T)DH;9!\)$-TE@'0KY M;[1#'=\H-Y=H684= 9GERNYPV ]R^E=QKDRBA(=ZVQ(G8&.P0&O1LJ!.6]:U MQ)6R!E'26FD^C]/_Z%^<[C%O9!4'-_9#.ZH"5YB+LRU6;;.UE<:EKVJ)P[GZ MUL961<+05^T#$^]+X8[:8=\!]/YO&L0K$ 30N'G\=VL@C\T+6R%.9>8&I4Y, M'.5?,>V1"5M/0)L$JT(F#4'Z*PYD2I;J=8.G$ OZ:2YI#;4V?=5&+018T[PP MUO0;.M56!PDPB75ZURFZRM#:< 02 0'@4^NKA+!:) MX:\WFCZQ&K>5B=!FCYDL=>(TC*X&XSI!4]72J*^"P@4Y&$BAT$_,F04><,:R M+_:5U1+]$+X+ J__ &A]+AB[!9&.GRVO %7H H(6!I/$JI/$O41T M2Y;#4!&HJ/_*-)ZRK&3]:_?RE,.T:.@T##9<^[U8!I?]N/,=!D]!7;4>E)%$Z%B#O)DNU,"(D<" ]0G0T"6>ASESC ML 6^I,,R_:,C^DXO0"3 M+9B039:!)%)5)%DVYLNV5C9 %[? R)I@F >*Y%\TX<3!%L=!HU32,+*D2AA8 MZ-/08;YE2[X\KE69L\&]&_?09+Q.D[&-*S-(XC8(R-"JF%)53.7W4:%H=$@H M&MZ%2J':RX74H+D9V-%6.D$TL,?ZXE9&[&V<,$ZRO([+Y$87H\SKTJ-C#07R MOS=3A2VNXK2,VAC=353>*>8=YX:A3(.SM'U"X@64#AAHRM(5 '2T=&YA:CB@7!X\K10OM/"#T&_2=OL< MJMHJL^%[Z5AP&H=AR[=0IZ_GT4AR:21&I[O\]A[SO=!;=YT ><7;!]LSBH_5 MA^*SL&5"6_%V=C]/0FOY0!46P7;,M&5[/AW]?1&J>2 0;22630[[5DZ8(N5K M"F1_ [-R0ZHW.0[I),NF2+'A!![4C?,#Z03>$IX&]F^AP'0A_A*FUX M*IDKG&YQ$NI>$L=VFK6\.,IAKSI37K>VA\HI.&IT-Q-39AX93-B^<,@C1MU^)GU'2V1Q%R34M M; G;X&PJ'R0^H-!R EVQ5OJ#E$@?\%6X#_"-BO!_6L%]M](^UU*-F^%UW?I? M6ITV?\K40MDW<@+4D4TP2F-D$W24*G9FS^8_V'OT[I90_PRY*_P4ITE>,8G5 M8C)N0H?H0PJ6L&#AOWL*C-Q(,AVU02."M*219,G\BNLM(3)UHNPG=94$"N5V MZ%:6Q!?*(^*P? N7J.5?QZ.)/"8>E9HDQF.32EN")N:PD[7,B8XZ^1*->?EW M$1T%ROZ[B!K/M< 54,F6F ?_#:*>J1Y=$Z5_2R-D]:(VZU*_:+59%?-U38JJ M*BG'0-05,W5:QUIH-)!\$T=C0/U[3,N55(CZ]PI3D))9;K!2B6HIQTARM+WJ M,X6A*]T.2!VFATY#%,HOX$CK$*K[E$\:E+8G#H.85:Z<'*(F.09/#E,9F!VM MORRDV*_R.$X;4'>X"2+'B/-Q0C_]^SG)>;)50[=!J!W'>5OB2AW=Z!G9O_14 M9'^BW6!SK$WF2ON[S%ORF-]?]*%J*P>PO5]4RT#D9Y/,6VW#N7;; UR:_G4W M+OKP1.^PMP(_\\3CT8#='!#)-R$\GF@E\?@OYY&0USWH /Q7B,F5:ZEN3S%N M#_K$#:FO]SR?P1+KTCQ1TZK*:'!I/L EO#SYUWI%VZPNRQU1 ^>:JD\/>%1T M%/NXADS5=M, 1SS[%\%(+/ NJH#[]BV'^[&9+_HPXH[K[D?O%;G%XR+$F2\2P 43,=2\G2K;Z3T?M[?"4Q M]/1DZWB.[>WS9#,E:ME,>6LV&T&S#62>[!2FR"T[&8:YV4S59?9X]IC&'E0A M:T]]OX7RYRHEV2/CGH3_P+.'X&Q7HG3KR!Q(8_DW8*+-DZMQ?[ Z-@#POZ@. M:IO\2TTOVORH?:1*>N*04#%Z_YB^0JC8 UDPCVAB=]EV9NM2A*0\.5WQU$VA M7F_[9=CA%_W[TW5;M<+/I-4&9Z=0( W+^)9,W*H6ATK3C62ZUG=_M_,%RBYI MSW1*X[ 46U@4/N5 U2F4'<\XP!\"QOTE[OKK62D4_8L(]GA.\)3[]K]C[U3I-S 5R9'VG<(T?!)S1^QJJ.OAH!*K M,ZX-]40G@(6*:JR5@2EUY#$]G$YWJ5913UO=O11H^*.H2LQZU_HJ^@1']ZZ?=GG(?OAU]-^&[(W7T7\;LO_9#^D+QP/*0S] MJP[E@D?2M8[+G)CDF99.3R3ZXJ5$ H:[,Z/"/P7.=.!,4!$^I$FT6_V4)E - MVIU":K4T1Q/97S'MU]I@W6J* 3YACW_T,<58G'_!45,\,'\9!UKRR2Z9.%$9>V (]) M6'0%^2R%\\$+.4%JJ1ISQ^6@.( %V4UCJ*URIHXSD,(\,O-1/"73FSYP,S3V M;$C%QEY84/C\1=;)]Y'#.8-"IK1:*\W5,,9O6%,>5_H! 9']&WX5<)(GRF<_X)%1F%4163& MH /Q.CGP/A.]"N13$'%PLB^@O54Y-'8XM%$:/4/L/H*2Q:)6@J2B0[U7W MUCX5]ZC/.E"P:+6 9V,,5&]UJ5%1V1NK7[4G/T!Z98^([#^GW^E1WRPQ4T?\ M #]$^_2_8S^B-RB@[C3^4?7OO]4>+I1EAE15#XJ$Y+%HK<&F%LEI%!W[ Y(1Q*+MA2\$_^2B/ M(NNBEZBK%I[R0<$ _7N_'O222CJB]LM">L'?'/"7)[_%=RN4Z/+#N@+U!ZM1 M2F@CL\.OCJD_RHFBJL9NI$C^EP = R,%'W)<58N)+O/7O@26GO;UW#KSJ?N#0K\EO,M\"EQO MYQBQ;P-B#[VN?M](^XC.A"N.C_!Q,/5>BE?ZCY+>^Y>/0_;W]&[_=L@^OG?[ MUT+VFNOT?R%[]77ZOY#]ONOIXZ7ZF8V4_9IU!5!!\X'(**'(O^K9);/Z_D/G M'W'76?3Y1_Q6SC^>)E\KSB+G'\$,8BP(BH&@Z)=1AP!R_1YG']L4-N4MCU/R M<^AZ^5'2A^F]7OZH>;UO6[ILU129; *;\M ML8Y>(L [:E3$XL\!;^6?Z7=IYH"S5AO1S(DDH6=]%L+G.>A$R7TXZ2Q.D/I6 MS<-K%S92F2GK9-?7Q%Q/S T.>PJGKUJ#*X*6%))%7M1XG]6$.FV3W;@Z0@01LK6%#*6O*2AJVU[:)E.#3NO=EDZB*7.996)]9@+YVX/$[&>V!ML M=/5GIL""[ DUBO@H-Z&9XFMX+P>Z@.Q MPKB^(<;1!7 $OBUMDK4^)MB+X !\XXT&5-^VS6&_P.F=],B?9;?#OIO7.]^@ M,P'']+M^!MRI3K]KJ@HH\BWYU$;,VVJ^-!#Q=C)HUK3O@ M8_<,L#CFJ%45R!I4SFG>SN9;CMFD&2HHEX/Z72>(=2LE.Q#6\J9D/4RL6R2< M#]Z$:]>;;-(0R;(=UAEDX2'-393R4$QA<[=\)Q^5X-O4LSXMQ%H-YP= MD07"BUN)V4U.2>8W]6^;W5 N^EW'$T^8#J^ZB^Z-<*M+MJ(&9LC; ,D*;JQN M&H!^UZ'$&M/1U2U939*XV]E9E@WY<-V_ L?[V_EV6KBZ*?I=@]!'QHF,1O(A MTIZD3JGQ&4C)QCV8MHS3^EVG'9YKLYR=Y8;CI=EOX=\9V3)#B"P M2[-"OTL+ JIE!QXP8I7ZD1>ND:.D$<\-L;;4Q_*ZC6BQSIC$O:7'L6 \FA70 MHB1+)Z6;U4^K,'Q?8=\!_*ZG];T>ZWL#J^]GF&UKR/4Y]GV>N39#"V]P+:SH MR=%PO#.?WEIT_1L]WL NDG:/],!;#$,LP@/C.DE(-\ 0QVCJ6CDP4.-5??L6 M?CG.JK]]$\^2SYUS@/^8/_X]&,R>!49@!XX<%]6.2VIP2ET$NL\4_+_Y47JL M$#)'S^\^\)LP)FL\4N/Z/_XZYEO3.4X[7/E(XV[^HGXRB$EK[KUQ]V.6C;'- M6RF,$5>N&//XTX# M#@.V 38 *@&+ /F 28 [ 7T!5_^'X\X#/@+L!&P&5 &> >0!3( TP,IMX!=P M#V @H!/B:0"\ _@/@ "8 ^C: _P7\$O "H 3P & PX.([''<$L 6P"O 8 M(!MP!Z!C)_@%[ '\>B?S\Q(\'P=,!J0 O- =O@_X=P#P4.XQ@ DP&+M)P(6_ M<-Q1P/\ R@&/ >X&?/MGB!?P!\!:0#Y@!( 'G/@3Q_TW8#' #$@%J !GH9O\ M"\ %6 +( =P&N/HVQ]4!W@0X 0L DP )@/8_!OP"\!=(,+A+&S%5)X; N^HJK05WF_9'2G^1'C/ MAZ! P') $N@7CR,6 GX-\ :P%/ :8!?@K0 SH@ MCD\![P+> C@!2]['X3BD#S !T!=P%KJ:6L"_ 5X S 2D :Z 'L*\+\ "; 8 M,>1 M;@-NV(%WW&[7#N\=QYCY)#//?0GO.(.?!^^GC[$V(\#[T6/,?3V\_T5QGYK+ M%\"[WVQO<'[>\>AG $( ">!)@!/P'$ M ;R0+@_@+< *P"P%L E@*F '( /0!U(.?;^N WP#^!-@(> $P&W W MX"MP8SK!<7@4I'XZSXTYP?*G>8CGAI]@]!L![QM/0ED!%@"R3[*TA=*5 =\& MP#?@OAZP\P3+PR9XE@&>!DP#?' *V@V@&E *6 "8!9@(& Q0 2Y". V &L V MP.9Z<%O/TOX$/"?61](^$(_W 1I.L3ST@\_G'F)Y0'IN5_* O.P\O%=\ FD! MF %W C2 <^"_!O";3UC99,[@:3U)^13*:1I;\/D:[$KA'07FX_!N!#IA_?DC MO#_T4.1=-X.YQ_='9O W!::;O_\O?\IF?N[Y1_B_._Z8)RQM6+C\^87+;L@#3<]S\U8LO;'@0^E9%4I0[-I9 MUIBL>V+]*.MM\YKUD>V]/]\RL6+Q-^3'Y_A =T+\Q[^KF%O:9E(G5> M("Y;:)GWS.)ERY5BX7JGX1LZ#%':/YQZ.(X M'J "J $:0!P@'I T (2 3\41A*)X_H =("^@&2 GN"ZG^:?B^O%/QCB!^@ M?0') #V &ZSYYZ)[W*J;_._FC\G$6!50MD%Y"&],C.>8C(0R(KKX2QP< $; *L!J %Z2\"'@)\ 3@ M20"NT,T!S 4\]7\Q_K4X1P2P _ NJ7*< \"C=H"?XZ0Q #>_X]YZG$1^&<=6 MN! &0.T>>)<#[M;%_<1X:<)KN% *^ 7@7W%N (!'&E"I!>I*P64[W++_[\H* MV7\"<"?_9H R3<5MP4O5 3@5A4LS>+#M+0">;/D=SE$"\#)2U$>-2ZUXQ@H7 MY_X(>!OE?L"? 'AKY5_8% V'"@O> >S",2"]894M6+T'0!T.N ()PWL.E0?A MSE 80G.URA70J)SF [S5 Y?0<=P(@&$LAZIA8.C)P? -AXL<#'DX&$YQ># MAAW<2=R.Q(8H' P).+SY!:^'Q(-FC8#3 +P" <^EM0#.L&Z8P[LA4<'&.0#J MJ#D/^"L -0O_#>^!Z"&_N#-]D_;_Q1%I,D!X!9$O),K%S =@'L1 M9P >!LS$\3S I@%F(US QR;)RO .\,!N._,BNL/N/T=\!@ =W0]_@/M__]6 M_#?;_\WVWUO[_Z%?^BPVSX'C#QQ7W.!PBXUOGIOWS,H?,3ZSS7]N^L5B8>$-C\?$IX_Q'!4_>+ M5RY>9OLQXV%AA;!\P?4]Q"F\VQ[VU=Y-)\#/V#/[-?9<=X ]E_CILZ)J-+(V MKJ[_?/JL^NQ7]+GPHX_PF39WBPK9GKSJH8GX_*_7ARR%9_9?-V7^%SRKAQ[< M^RD\Q]_UW;.Z'*ZB=>*+!Z;D<%L:G,7C5^5PAV<]L[3F#SG< []XZOQC9W.R M7]FYYK:W!TS+NW3NT_-#9D[[UT\L\1^W5TP+^1NT+&[GSMV_S/WN\F2O>O8D MR]C;,B\_M/KGC]___LKREMD#Q+VDX5=_/KGI_G&_V_K)G9TS3 _\KF/:]_JW MQF[^U2L?:_<\,3QG^;8%(^(/)\7,/SR]?(7P(^B]>N5"07S^QLMSZ;QG%][H M! JMOXN7+; ]W\OT!CH?S]QA7^V>'SO7H^F6UKPY/.<>!QC+=[Z3PHWJ?O =>X_'NZT.6Q.%_/<@YZVY\25BVZ4X]'V4=YM_@A*?/GS M-\(#%??+YCWW8]K[/$%X\<;=W_CL78@_+%B\_,?P[]7SGGOV1[@7%JY8NGCY MRIX5=NR8L5GA&AMQ_]S*A0M[#3]K8J_Y_1'LEKI_ 3RL6+CTQQ3XS=_-W\W? CS=_-W\W?S=_-W\W?S=_-W\W?S=_-WS_U]W\ J(WH9P!@ 0#T end From lites-readers-request Thu Jul 13 18:49:05 1995 id SAA21694; Thu, 13 Jul 1995 18:49:03 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 14 Jul 1995 03:23:57 +0300 id SAA21346; Thu, 13 Jul 1995 18:23:54 -0600 id SAA05464; Thu, 13 Jul 1995 18:23:52 -0600 From: sclawson@schnapps.cs.utah.edu (steve clawson) Subject: Some new releases for the summer. To: lites@cs.hut.fi, mach4-announce@schirf.cs.utah.edu Date: Thu, 13 Jul 1995 18:23:50 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1854 I just put some new files up on jaguar.cs.utah.edu. There should be enough there now to actually put together a semi-functional Lites system with binaries only. There is also a version of Lites-1.1 tweaked to easily build with mach4 and the Utah i386-mach cross tools. Here's a list of the new files: in /flexmach/lites lites-1.1.u1.tar.gz Lites-1.1.u1 is bascially lites-1.1 with some changes to make it compile more cleanly with mach4 and the i386-mach cross-build tools from Utah, and to make the configure script work somewhat more sanely. This is not meant as a major release, and as such has been mainly tested on the x86. However if you've got the PA snapshot, you be able to compile this version of Lites and run it on your system. Jeff Law fixed a filesystem race, and Mike Hibler fixed some parisc console problems. Also, the --target= and --host= configure options now work as normal. A diff against Lites-1.1 should be appearing shortly. README.lites-1.1.u1 A short guide to building/installing Lites-1.1.u1 with the i386-mach cross-build tools and mach4. MAKEDEV.lites A script to build the Lites devices. Run this from /dev. patch-i386-UK02pl13-lites Very small patch so that Lites can compile with mach4-i386-UK02pl13. Also fixes a thinko in the old ns8390 driver. in /flexmach/binaries/ README.user22-bin-i386 user22-bin-i386.tar.gz USER22 binaries, including ps, machid, mach_init along with man pages for all binaries. Look at the README file for more information. emulator.Lites.1.1 startup.Lites.1.1.STD+WS+mach4 startup.Lites.1.1.STD+WS+mach4.unstripped Lites-1.1.u1 emulator and server. These should go into /mach_servers/{emulator,startup} along with mach_init and a paging_file. steve -- // stephen clawson sclawson@cs.utah.edu // university of utah From lites-readers-request Fri Jul 14 22:18:51 1995 id WAA11737; Fri, 14 Jul 1995 22:18:49 -0600 (5.65c8/HUTCS-S 1.4 for ); Sat, 15 Jul 1995 07:00:19 +0300 id WAA11628; Fri, 14 Jul 1995 22:00:15 -0600 id WAA16502; Fri, 14 Jul 1995 22:00:13 -0600 From: Jay Lepreau To: lites@cs.hut.fi, mach4-announce@schirf.cs.utah.edu Subject: Re: Some new releases for the summer. In-Reply-To: steve clawson's message of Thu, 13 Jul 95 18:23:50 MDT Date: Fri, 14 Jul 95 22:00:12 MDT In case it wasn't clear, thanks to Steve we now provide all the binaries you need to run Mach and Lites on a PC: the Mach kernel, Lites server and emulator, and Mach/Lites-specific user programs. The kernel, emulator, and server are currently separate. The rest you just untar. In addition, we provide most of the build tools necessary for *bsd and Linux, and the full Mach and Lites sources. Sources for the user programs will follow some day. It's one stop shopping on the Utah Free Shopping Network. Send bugs and fixes. Stand by for an August release of our new IDL compiler with takes MIG and CORBA and spits out Mach IPC. A real compiler, not that MIG printf nonesense. /mach_servers: emulator, server ("startup"), mach_init /usr/mach4/bin: Flags, hostinfo, ipc_test, mach3, macherr, machipc, massign, mcreate, mkill, mnice, mpolicy, ms, mt, snames, stacks, swapon, thstate, vminfo, vmread, vmsearch, vmstat, waitfor, xptest, zprint, ps, hash_info, machid, netmemoryserver, pinfo, top, w, envmgr, uptime. /usr/mach4/man/man1: man pages for all of the above. From lites-readers-request Sat Jul 15 08:35:58 1995 id IAA15583; Sat, 15 Jul 1995 08:35:57 -0600 (5.65c8/HUTCS-S 1.4 for ); Sat, 15 Jul 1995 17:23:38 +0300 Date: Sat, 15 Jul 1995 10:18:39 -0400 From: Michael I Bushnell To: lepreau@cs.utah.edu Cc: lites@cs.hut.fi, mach4-users@schirf.cs.utah.edu In-Reply-To: Jay Lepreau's message of Fri, 14 Jul 95 22:00:12 MDT <199507150400.WAA16502@mancos.cs.utah.edu> Subject: Re: Some new releases for the summer. X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv+ b+++ !D B-- e+ u++(*) h* f? r n y++ X-Tom-Swiftie: "Condensed chicken soup," was Tom's canned response. From: Jay Lepreau Date: Fri, 14 Jul 95 22:00:12 MDT Stand by for an August release of our new IDL compiler with takes MIG and CORBA and spits out Mach IPC. A real compiler, not that MIG printf nonesense. Need I remind you that even GCC uses prinf for output? ;-) Michael From lites-readers-request Mon Jul 17 20:33:06 1995 id UAA19509; Mon, 17 Jul 1995 20:33:03 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 18 Jul 1995 05:17:42 +0300 id UAA19259; Mon, 17 Jul 1995 20:17:38 -0600 id UAA12456; Mon, 17 Jul 1995 20:17:37 -0600 From: sclawson@schnapps.cs.utah.edu (steve clawson) Subject: lites-1.1.u1 diffs against lites-1.1 To: mach4-announce@schirf.cs.utah.edu, lites@cs.hut.fi Date: Mon, 17 Jul 1995 20:17:36 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 281 For all you who were waiting for the diff between lites-1.1.u1 and lites-1.1, it's finally out there. It can be found at: jaguar.cs.utah.edu:/flexmach/lites/patch-lites-1.1-1.1.u1.gz steve -- // stephen clawson sclawson@cs.utah.edu // university of utah From lites-readers-request Wed Jul 19 22:24:55 1995 id WAA09312; Wed, 19 Jul 1995 22:24:51 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 20 Jul 1995 07:14:25 +0300 (5.65c8/HUTCS-C 1.3 for lites); Thu, 20 Jul 1995 07:14:23 +0300 Date: Thu, 20 Jul 1995 07:14:23 +0300 From: Johannes Helander To: mach4-users@cs.utah.edu, lites@cs.hut.fi In-Reply-To: Ching-Ming Shu's message of 19 Jul 1995 21:38:24 +0300 Subject: Re: Problems with booting! Ching-Ming Shu wrote: > ld.so: getty: libutil.so.2.0: Bad address Has somebody looked into what changed in the FreeBSD 2.0.5 shread libraries compared to the 2.0 ones? My guess is that the problem would be easy enough to fix that it'd be worth doing. The previous sources of problems with shared libraries have come from the fact that Lites' mmap is totally different from the BSD one. It implements the same interface but since the interface is unusually vaguely defined it is common that programs expect more than is actually part of the interface. Also I might not have implemented everything -- the code was written more on a demand basis than a completeness basis. That is, whenever something was needed I implemented it. Implementing features just for fun would have required writing test programs etc. Besides implementing useless bloat isn't very motivating :-). So take a look at emulator/e_bsd.c:e_mmap() and ld.so and find out why the dynamic linker fails. If gdb doesn't work for you, it is easy to add a few printfs here and there to track down the cause (e_emulator_error is printf in the emulator). The NetBSD 1.0A and Linux system call convention could be added as an alternative to the kernel's system call redirection code. A faster alternative for any shared library is to do a direct subroutine call to the emulator instead of doing the useless trap in the first place. That would make the Lites library behave more like what it is -- a shared library. In order to be binary compatible it is, however, convenient to support the trap redirection stuff. Johannes PS. I could look at this myself but then I'd have to install the new BSDs somewhere and I don't have time right now and so on... From lites-readers-request Thu Jul 27 09:26:51 1995 id JAA10855; Thu, 27 Jul 1995 09:26:49 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 27 Jul 1995 18:13:42 +0300 Date: Thu, 27 Jul 95 11:13:45 -0400 From: "Stephen D. Smalley" To: lites@cs.hut.fi Subject: "Upcalls" from the Lites server to Unix processes We would like to be able to have the Lites server perform "upcalls" to a negotiation server (which runs as a Unix process) to establish security associations for network communications. In soconnect() and sosend(), we check a security association database to see if an association exists for the destination. If not, we use Mach IPC to request a negotiation from the negotiation server. Theoretically, the negoation server should perform the negotiation, update the security association database, and return a SPI (security parameter index) to the Lites server as a response to the Mach IPC. However, when the negotiation server attempts to invoke any Unix system call, the system appears to enter deadlock. We do NOT call splnet() before performing the "upcall". Is what we are attempting feasible? From lites-readers-request Fri Aug 4 05:36:12 1995 id FAA08916; Fri, 4 Aug 1995 05:36:11 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 4 Aug 1995 14:24:23 +0300 (1.37.109.16/16.2) id AA264615565; Fri, 4 Aug 1995 13:26:05 +0200 (1.38.193.5/16.2) id AA06525; Fri, 4 Aug 1995 13:16:30 +0200 Date: Fri, 4 Aug 1995 13:16:30 +0200 (METDST) From: "Josep M. Blanquer" X-Sender: tete@pollux To: lites@cs.hut.fi Cc: "Josep M. Blanquer" Subject: NE200 on Mach/lites ?? Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I've just built lites1.1 and Mach4 on a i386 running FreeBSD and I have two questions: -Is it possible to use Mach/lites with a NE200 compatible ethernet card ?? if not, what are the ones supported ? -I have been trying to run the user22 binary tools provided with the last version announced, and I've realixed that some of them need some servers like sname,machid...to run. Are there any domcuments about configuring the system or someting close to that?? Than you very much!! Josep --------------------------------------------------------------------------- Josep Ma. Blanquer Gonzalez (tete@els.url.es) Computer Science Department La Salle University (Catalonia -Spain-) --------------------------------------------------------------------------- From lites-readers-request Thu Aug 10 07:25:58 1995 id HAA05912; Thu, 10 Aug 1995 07:25:56 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 10 Aug 1995 16:15:55 +0300 (5.65c8/HUTCS-C 1.3); Thu, 10 Aug 1995 15:38:15 +0300 Date: Thu, 10 Aug 1995 15:38:15 +0300 From: Jukka Partanen To: lites@cs.hut.fi Cc: jtp@cs.hut.fi Subject: Lites 1.1.950808 snapshot Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hello! I've made a new snapshot of Lites available in ftp.funet.fi:pub/mach/lites/lites-1.1.950808.tar.gz. Binaries can be found in i386-bin. There are versions linked in leia, and in a NetBSD machine. This snapshot includes the patches from University of Utah (patch-lites-1.1-1.1.u1) and some of my own, most notably ppp support and a new sysctl implementation. I've also written short instructions on how to build Lites on NetBSD (doc/README.netbsd). NOTE! This snapshot is incompatible with previous versions, so be careful when you upgrade the emulator. Using the old server you can just follow these magic footprints (at least I did this) 1. move the old startup to startup.old 2. copy the new startup to /mach_servers/startup 3. move the old emulator to emulator.old = 4. copy the new emulator to /mach_servers/emulator (make sure you have the execute bits on) 5. sync; reboot Any program that uses sysctl will not work with an incompatible server and emulator. Enjoy! jtp I want the presidency so bad I can already taste the hors d'oeuvres. From lites-readers-request Mon Aug 14 15:46:48 1995 id PAA13865; Mon, 14 Aug 1995 15:46:47 -0600 From: gback@facility.cs.utah.edu (5.65c8/HUTCS-S 1.4 for ); Mon, 14 Aug 1995 23:54:39 +0300 id OAA12611; Mon, 14 Aug 1995 14:54:36 -0600 id OAA04545; Mon, 14 Aug 1995 14:54:35 -0600 Subject: Alpha testers for EXT2FS support wanted To: lites@cs.hut.fi Date: Mon, 14 Aug 1995 14:54:34 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 457 Hi, we have implemented support for EXT2FS file systems in Lites. Before we officially release it, we would like a few people to test it and give us feedback. Please send mail to gback@cs.utah.edu if you're interesting in getting a copy. Also integrated is support for MSDOS file systems (taken from FreeBSD), so you might test this as well. - Godmar -- // Godmar Back (gback@cs.utah.edu) // University of Utah, Center for Software and Languages From lites-readers-request Mon Aug 14 17:05:14 1995 id RAA15147; Mon, 14 Aug 1995 17:05:13 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Aug 1995 01:32:39 +0300 (5.65c8/HUTCS-C 1.3 for lites); Mon, 14 Aug 1995 23:25:24 +0300 Date: Mon, 14 Aug 1995 23:25:24 +0300 From: Johannes Helander To: daver@cs.pdx.edu (Dave Roethig) Cc: lites@cs.hut.fi Subject: Re: X under Lites question In-Reply-To: <199508141847.LAA23186@sirius.cs.pdx.edu> References: <199508141847.LAA23186@sirius.cs.pdx.edu> Organization: Helsinki University of Technology, CS Lab. Dave Roethig wrote: > I was incorrect in stating that we had Lites 1.1, we have > Lites 0.6. Due to modifications that have been made, it > is not possible to upgrade to 1.1. Is it possible to > upgrade selected pieces that have changed between 0.6 and 1.1?? > > What exactly changed between 0.6 and 1.1?? I can't remember exactly without diffing them. But Lites 0.8 and 1.0 are almost the same thing and between 0.6 and 0.8 there might not be so much difference. One significant difference is that Lites 1.0 is known to be legally clean, but any version before that is not. The pre-release (0.X and earlier) versions were just internal developer alpha-versions and not published software. If you plan to distribute your software you really should make the effort to upgrade to at least Lites 1.0. I'll rephrase this to make it clear: I do not distribute, nor approve distribution or redistribution of any pre-1.0 versions. Also my formal permission from Carnegie Mellon to distribute the code owned by them included in Lites as part of Lites does not apply to pre-1.0 versions. Basically any version of Lites before 1.0 does not exist and has never been distributed and never will. But I would really recommend you to go all the way to Lites 1.1 or better, the current snapshot available in nic.funet.fi:/pub/mach/lites > >> Is it possible to take a binary compiled under > >> NetBSD 1.0 and simply run it under Lites? > > > >Compiled _under_ NetBSD yes, compiled _for_ NetBSD no. > What do you mean? Do you mean that X should be compiled > for Mach under NetBSD?? > > Why doesn't a NetBSD X run under Lites? I thought that Lites > provided compatability with all *BSD binaries? With almost all. Programs using custom interfaces such as certain ioctls, /dev/kmem, etc. might not work. The X server is one of them. It needs support for mapping the frame buffer, the video chip, and keyboard & mouse input. But the interfaces are custom made for the X server and everybody does them differently. I implemented one way (the 'Mach way'), but only one. If you or anyone else has time and interest to implement other ways, such as NetBSD, they'd be happily included into Lites 1.2. > >Each system does basically the same thing: provides a way to map the > >frame buffer, get access to the i/o ports, and a way to get mouse and > >keyboard input. Each system does it slightly differently, however, > >and currently only the "Mach way" is supported. If you want to add > >the support, I'll try to answer your questions. > I read somewhere that the virtual terminal support is missing from > Lites 0.6. Is this impression of mine incorrect? It is still missing in Lites 1.1. > Interestingly enough, we ran X compiled for NetBSD under Lites > and received the error "console driver not found". > Comments? Well, this seems to be the error message resulting from the above mentioned missing interfaces. > >> How would I compile X to run under Lites? > >> With the MACH option or the BSD option?? > > > >The MACH option (for now). Cheers, Johannes From lites-readers-request Mon Aug 14 17:44:10 1995 id RAA15806; Mon, 14 Aug 1995 17:44:08 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 15 Aug 1995 02:07:06 +0300 To: gback@facility.cs.utah.edu Cc: lites@cs.hut.fi Subject: Re: Alpha testers for EXT2FS support wanted In-Reply-To: Your message of "Mon, 14 Aug 1995 14:54:34 MDT." <199508142054.OAA04545@lal.cs.utah.edu> Date: Mon, 14 Aug 1995 16:05:59 -0700 From: "Jordan K. Hubbard" > Also integrated is support for MSDOS file systems (taken from > FreeBSD), so you might test this as well. Just a cautionary note: Our current MSDOS filesystem has been known to scribble on random parts of the disk when used heavily for writing. Until we find it, the FreeBSD installer currently configures any DOS partitions as read-only in fstab.. Jordan From lites-readers-request Tue Aug 29 11:59:49 1995 id LAA16464; Tue, 29 Aug 1995 11:59:44 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 29 Aug 1995 20:44:57 +0300 Date: Tue, 29 Aug 95 12:49:06 -0400 From: "Stephen D. Smalley" To: lites@cs.hut.fi Subject: Lites 1.1-950808 on MK83A We're having frequent yet non-deterministic system lockups in running Lites 1.1-950808 on MK83A. Previously, we were working with Lites 0.6 on MK83A, and we hadn't seen the problem in that environment. A typical lockup point occurs while updating /etc/motd in /etc/rc.local: T=/tmp/_motd rm -f $T sysctl -n kern.version | sed 1q > $T echo "" >> $T sed '1,/^$/d' < /etc/motd >> $T cmp -s $T /etc/motd || cp $T /etc/motd rm -f $T By adding some printf's to cmp, we found that cmp calls read() on /tmp/_motd, then read() on /etc/motd, and then read() again on /tmp/_motd. The last call to read() never returns. It should simply return 0, because all of /tmp/_motd should have been read in the first call. Has anyone else seen this problem? From lites-readers-request Tue Aug 29 12:56:09 1995 id MAA17788; Tue, 29 Aug 1995 12:56:05 -0600 (5.65c8/HUTCS-S 1.4 for ); Tue, 29 Aug 1995 21:48:26 +0300 Date: Tue, 29 Aug 95 14:48:19 -0400 From: "Stephen D. Smalley" To: lites@cs.hut.fi Subject: Lites 1.1-950808 on MK83A (followup) We added a printf immediately after the START_SERVER() macro and another printf immediately before the END_SERVER_DEALLOC_ON_ERROR() macro in bsd_read_long() [server/serv/bsd_server_side.c]. Just before the lockup, we see: bsd_read_long(): entering datalen 16384 bsd_read_long(): exiting error 0 *nread 0 *data 7ba000 *data_count 16384 From lites-readers-request Tue Aug 29 17:27:50 1995 id RAA24072; Tue, 29 Aug 1995 17:27:44 -0600 From: benson@cs.ucdavis.edu (5.65c8/HUTCS-S 1.4 for ); Wed, 30 Aug 1995 02:19:48 +0300 To: mach4-users@cs.utah.edu, lites@cs.hut.fi Subject: gdb on Mach4+Lites Date: Tue, 29 Aug 95 16:19:30 -0700 X-Mts: smtp Has anyone built gdb (with mach support) in a Mach4+Lites environment? I grabbed gdb-4.8.tar.Z from mach.cs.cmu.edu. It looks like it might build, but libmachid and libnetname are needed, which come from the user22 files. Is anyone working on modifying the user22 files build in the Mach4 (gnu) environment? Thanks Greg Benson benson@cs.ucdavis.edu From lites-readers-request Wed Aug 30 13:45:29 1995 id NAA09483; Wed, 30 Aug 1995 13:45:25 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 30 Aug 1995 22:29:53 +0300 Date: Wed, 30 Aug 95 15:29:40 -0400 From: "Stephen D. Smalley" To: lites@cs.hut.fi Subject: Lites 1.1-950808 on MK83A (correction) Either I was misread the original output from cmp, or the point of the lockup has changed slightly [it is now the first read() on the second file which never returns]. In any event, typical output before a lockup is: cmp(): before read(fd1,buf1,16384) bsd_read_long(): entering datalen 16384 bsd_read_long(): exiting error 0, *nread 36, *data 7ba000, *data_count 16384 cmp(): after read(fd1,buf1,16384) cmp(): before read(fd2,buf2,16384) bsd_read_long(): entering datalen 16384 bsd_read_long(): exiting error 0, *nread 0, *data 7ba000, *data_count 16384 The cmp() output is from the cmp command. The bsd_read_long() output is from the Lites server. From lites-readers-request Thu Aug 31 09:11:16 1995 id JAA24544; Thu, 31 Aug 1995 09:11:13 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 31 Aug 1995 17:58:14 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Thu, 31 Aug 1995 17:57:20 +0300 Date: Thu, 31 Aug 1995 17:57:20 +0300 From: Jukka Partanen To: "Stephen D. Smalley" Cc: lites@cs.hut.fi Subject: Re: Lites 1.1-950808 on MK83A (correction) In-Reply-To: <9508301929.AA02499@medusa.epoch.ncsc.mil> References: <9508301929.AA02499@medusa.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Stephen D. Smalley writes: > = > Either I was misread the original output from cmp, or the = > point of the lockup has changed slightly [it is now the first read() = = > on the second file which never returns]. In any event, typical = > output before a lockup is: > = > cmp(): before read(fd1,buf1,16384) > bsd_read_long(): entering datalen 16384 > bsd_read_long(): exiting error 0, *nread 36, *data 7ba000, = > *data_count 16384 > cmp(): after read(fd1,buf1,16384) > cmp(): before read(fd2,buf2,16384) > bsd_read_long(): entering datalen 16384 > bsd_read_long(): exiting error 0, *nread 0, *data 7ba000, = > *data_count 16384 > = > The cmp() output is from the cmp command. The = > bsd_read_long() output is from the Lites server. = > = You could try setting the EMULATOR_DEBUG environment variable and see what happens. For example EMULATOR_DEBUG=3D3 cmp -s $T /etc/motd || cp $T /etc/motd should produce a fair amount of debugging output from the emulator. This way you'll see at least if the emulator gets the reply message and the return value. BTW, what binaries are you using? jtp Either CONFESS now or we go to ``PEOPLE'S COURT''!! From lites-readers-request Thu Aug 31 13:18:03 1995 id NAA29479; Thu, 31 Aug 1995 13:18:01 -0600 (5.65c8/HUTCS-S 1.4 for ); Thu, 31 Aug 1995 22:08:41 +0300 Date: Thu, 31 Aug 95 15:08:32 -0400 From: "Stephen D. Smalley" To: Jukka Partanen Subject: Re: Lites 1.1-950808 on MK83A Cc: lites@cs.hut.fi >>BTW, what binaries are you using? NetBSD 1.0. >>EMULATOR_DEBUG=3D3 cmp -s $T /etc/motd || cp $T /etc/motd Prior to the lockup, the emulator prints: emulator [117] emul_syscall[3] e_read(x3, x819c, x4000, x19d8, x4000, xbfffdfe4, xbfffe013, x170d) However, for that call to read(), the emulator does not display the typical 'emulator [117] return[3] e_read = (...)', so it doesn't appear to be receiving a reply. In ux_server_loop(), I added code to print a message before and after the reply call to cthread_mach_msg() if the request msgh_id corresponds to bsd_read_long [101029]. It appears that the server never returns from the reply call to cthread_mach_msg(). Hence, I added some printf's around the calls to mach_msg() within cthread_mach_msg() if the reply msgh_id is (101029+100). Based on the output, it appears that the server never returns from the reply call to mach_msg() with: header->msgh_bits = 0x80000012 header->msgh_size = 56 header->msgh_remote_port = 0xaee7 header->msgh_local_port = 0x0 send_size = 56 rcv_size = 9216 rcv_name = 0x1200 Of the three cases where cthread_mach_msg() calls mach_msg(), this happens to be the second case. From lites-readers-request Sat Sep 2 10:39:47 1995 id KAA01722; Sat, 2 Sep 1995 10:39:46 -0600 From: agl@sequoiap.com (5.65c8/HUTCS-S 1.4 for ); Sat, 2 Sep 1995 19:31:44 +0300 To: lites@cs.hut.fi Subject: __udivdi3 and all that stuff: Date: Fri, 1 Sep 95 21:06:22 PDT Sender: agl@sequoiap.com Source-Info: From (or Sender) name not authenticated. I'm sorry for asking the same question again, but could somebody possibly remind me how these errors could be avoided when linking startup.Lites ? I asked it a couple of months ago and somebody pointed out how to fix it, now I'm stuck essentially with the same problem :-( kernfs_vnops.o: Undefined symbol `___divdi3' referenced from text segment nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment nfs_nqlease.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment Thanx for any pointer (including ftping startup binaries from jaguar.cs.utah,edu ;-) AGL From lites-readers-request Sat Sep 2 11:02:34 1995 id LAA01900; Sat, 2 Sep 1995 11:02:32 -0600 (5.65c8/HUTCS-S 1.4 for ); Sat, 2 Sep 1995 19:55:45 +0300 by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id SAA19055 ; Sat, 2 Sep 1995 18:55:43 +0200 by excalibur.ibp.fr (8.6.12/jtpda-5.0) id SAA29192 ; Sat, 2 Sep 1995 18:55:42 +0200 From: card@excalibur.ibp.fr (Remy Card) Subject: Re: __udivdi3 and all that stuff: To: agl@sequoiap.com Date: Sat, 2 Sep 1995 18:55:40 +0200 (MET DST) Cc: lites@cs.hut.fi In-Reply-To: <9509012106.aa15714@sheba.sequoiap.com> from "agl@sequoiap.com" at Sep 1, 95 09:06:22 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1613 > > I'm sorry for asking the same question again, but could somebody > possibly remind me how these errors could be avoided when linking > startup.Lites ? I asked it a couple of months ago and somebody > pointed out how to fix it, now I'm stuck essentially with the same problem :-( > > kernfs_vnops.o: Undefined symbol `___divdi3' referenced from text segment > nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment > nfs_bio.o: Undefined symbol `___divdi3' referenced from text segment > nfs_nqlease.o: Undefined symbol `___udivdi3' referenced from text segment > nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment > nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment > nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment > nfs_serv.o: Undefined symbol `___udivdi3' referenced from text segment Well, I don't know on which system you are trying to build Lites but I had the very same problem when compiling it on FreeBSD. Apparently, the FreeBSD maintainers decided to remove some symbols from the libgcc library and to move them to the C library. If you use FreeBSD, you can either try to link Lites against libc.a (and hope that no user mode function will be linked into the binary...) or recompile libgcc to include the missing symbols. To do so, go to /usr/src/gnu/usr.bin/cc/libgcc, edit the Makefile to add the missing objects (_divdi3.o and _udivdi3.o at least) in the LIB2OBJS definition, and run ``make all install''. > Thanx for any pointer (including ftping startup binaries from > jaguar.cs.utah,edu ;-) > AGL Remy From lites-readers-request Sun Sep 3 19:42:22 1995 id TAA16964; Sun, 3 Sep 1995 19:42:19 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 4 Sep 1995 04:28:35 +0300 Date: Mon, 4 Sep 1995 10:59:06 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: Signals Reply-To: dall@hfrd.dsto.gov.au I have found a problem in signal handling in lites. I also think I have fixed it, but may be missing something and would welcome any comments. In send_signal() there is code: siglock(p); p->p_sigmask |= mask; if (ps->ps_flags & SA_OLDMASK) { returnmask = ps->ps_oldmask; ps->ps_flags &= ~SA_OLDMASK; } else returnmask = p->p_sigmask; p->p_sigmask |= sigmask(sig); sigunlock(p); sendsig(p, thread, action, sig, code, returnmask); Now, return mask seems to be a vestigial argument. sendsig() does nothing with it. Later on in bsd_take_signal() there is code: if (ps->ps_flags & SA_OLDMASK) { returnmask = ps->ps_oldmask; ps->ps_flags &= ~SA_OLDMASK; } else returnmask = p->p_sigmask; siglock(p); p->p_sigmask |= mask; sigunlock(p); . . . *old_mask = returnmask; It seems that SA_OLDMASK flag never gets set. Consequently, old_mask actually is set to the new mask (ie with the currently being handled signal set). When the users signal handling function completes and the emulator does a bsd_sigreturn, the signal mask gets set to this wrong value in old_mask. Consequently, it seems that if signals are being caught, after the first catch, that signal remains masked. I see this with a small test program, but at least some programs which catch signals *do* work properly currently (eg emacs) and I don't really understand why. Programs which longjump out of their signal handler would work because they install a new mask. Maybe the vast majority of programs either just exit once they have caught a signal or else use longjump. Maybe re-installing the signal handler (which a lot of programs do for sysV compatability) also fixes the mask, or maybe not. Anyway, I have tried code which essentially does in send_signal(): siglock(p); ps->ps_oldmask = p->p_sigmask; p->p_sigmask |= sigmask(sig); sigunlock(p); sendsig(p, thread, action, sig, code, /* unused */ 0); and in bsd_take_signal(): siglock(p); returnmask = ps->ps_oldmask; sigunlock(p); . . . *old_mask = returnmask; This seems to work so far (and is simpler). Can anyone see any problem with this? Any problems with sysV or linux support? Ian From lites-readers-request Mon Sep 4 01:25:16 1995 id BAA19391; Mon, 4 Sep 1995 01:25:12 -0600 (5.65c8/HUTCS-S 1.4 for ); Mon, 4 Sep 1995 10:13:02 +0300 (5.65c8/HUTCS-C 1.3 for lites@cs.hut.fi); Mon, 4 Sep 1995 10:12:57 +0300 Date: Mon, 4 Sep 1995 10:12:57 +0300 From: Jukka Partanen To: card@excalibur.ibp.fr (Remy Card) Cc: agl@sequoiap.com, lites@cs.hut.fi Subject: Re: __udivdi3 and all that stuff: In-Reply-To: <199509021655.SAA29192@excalibur.ibp.fr> References: <9509012106.aa15714@sheba.sequoiap.com> <199509021655.SAA29192@excalibur.ibp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Remy Card writes: > Well, I don't know on which system you are trying to build Lites but= > I had the very same problem when compiling it on FreeBSD. Apparently= , the > FreeBSD maintainers decided to remove some symbols from the libgcc li= brary > and to move them to the C library. If you use FreeBSD, you can eithe= r try > to link Lites against libc.a (and hope that no user mode function wil= l be > linked into the binary...) or recompile libgcc to include the missing= symbols. > To do so, go to /usr/src/gnu/usr.bin/cc/libgcc, edit the Makefile to = add > the missing objects (_divdi3.o and _udivdi3.o at least) in the LIB2OB= JS > definition, and run ``make all install''. NetBSD-current also had the same problem. I just took NetBSD 1.0's libgcc and linked Lites with it. jtp If I pull this SWITCH I'll be RITA HAYWORTH!! Or a SCIENTOLOGIST! From lites-readers-request Tue Sep 5 22:29:34 1995 id WAA13749; Tue, 5 Sep 1995 22:29:32 -0600 (5.65c8/HUTCS-S 1.4 for ); Wed, 6 Sep 1995 06:26:27 +0300 (5.65c8/HUTCS-C 1.3 for lites); Wed, 6 Sep 1995 05:45:35 +0300 Date: Wed, 6 Sep 1995 05:45:35 +0300 From: Johannes Helander To: dall@hfrd.dsto.gov.au Cc: lites@cs.hut.fi Subject: Re: Signals In-Reply-To: <199509040129.KAA06398@hfrd015.dsto.gov.au> References: <199509040129.KAA06398@hfrd015.dsto.gov.au> Organization: Helsinki University of Technology, CS Lab. Ian Dall writes: > I have found a problem in signal handling in lites. I also think I have > fixed it, but may be missing something and would welcome any comments. Your fix looks fine but as always with signals and other messy stuff you never know before some testing. Of course the entire signal stuff is wrong. All the mask handling etc. should be done in the emulator rather than the server. The current implementation (on the server side) is a result of CPR that got the code somehow to work but broke a few ribs. Johannes From lites-readers-request Fri Sep 8 06:54:43 1995 id GAA00166; Fri, 8 Sep 1995 06:54:42 -0600 (5.65c8/HUTCS-S 1.4 for ); Fri, 8 Sep 1995 15:43:56 +0300 Date: Fri, 8 Sep 95 08:43:12 -0400 From: "Stephen D. Smalley" To: lites@cs.hut.fi Subject: Lites 1.1-950808 on MK83A Since I haven't been able to resolve the frequent yet non-deterministic lockups in read() with Lites 1.1-950808 on MK83a, I tried regressing to Lites 1.1 and then to Lites 1.0. I encounter the same problem with Lites 1.1, but I haven't seen it occur in Lites 1.0 yet. From lites-readers-owner Mon Sep 18 23:29:22 1995 id XAA04514; Mon, 18 Sep 1995 23:29:22 -0600 Date: Mon, 18 Sep 1995 23:03:40 -0600 From: mike@cs (Mike Hibler) To: dall@hfrd.dsto.gov.au Subject: Re: Signals Cc: lites@cs.hut.fi Sender: owner-lites-readers@cs Precedence: bulk Reply-To: mike@cs (Mike Hibler) > Date: Mon, 4 Sep 1995 10:59:06 +0930 > From: Ian Dall > To: lites@cs.hut.fi > Subject: Signals > > I have found a problem in signal handling in lites. I also think I have > fixed it, but may be missing something and would welcome any comments. > > In send_signal() there is code: > > siglock(p); > p->p_sigmask |= mask; > if (ps->ps_flags & SA_OLDMASK) { > returnmask = ps->ps_oldmask; > ps->ps_flags &= ~SA_OLDMASK; > } else > returnmask = p->p_sigmask; > p->p_sigmask |= sigmask(sig); > sigunlock(p); > > sendsig(p, thread, action, sig, code, returnmask); > > Now, return mask seems to be a vestigial argument. sendsig() does > nothing with it. > > Later on in bsd_take_signal() there is code: > > if (ps->ps_flags & SA_OLDMASK) { > returnmask = ps->ps_oldmask; > ps->ps_flags &= ~SA_OLDMASK; > } > else > returnmask = p->p_sigmask; > siglock(p); > p->p_sigmask |= mask; > sigunlock(p); > > . > . > . > > *old_mask = returnmask; > > It seems that SA_OLDMASK flag never gets set. Consequently, old_mask > actually is set to the new mask (ie with the currently being handled > signal set). When the users signal handling function completes and > the emulator does a bsd_sigreturn, the signal mask gets set to this > wrong value in old_mask. > > Consequently, it seems that if signals are being caught, after the > first catch, that signal remains masked. I see this with a small test > program, but at least some programs which catch signals *do* work > properly currently (eg emacs) and I don't really understand > why. Programs which longjump out of their signal handler would work > because they install a new mask. Maybe the vast majority of programs > either just exit once they have caught a signal or else use > longjump. Maybe re-installing the signal handler (which a lot of > programs do for sysV compatability) also fixes the mask, or maybe not. > I think the answer for why some things seem to work is that there are two paths to bsd_take_signal and only one of them goes through send_signal/sendsig. The "forced" signal delivery from the server does go through send_signal and will have the problem you describe. The more common (I think) path is that when a signal is posted, delivery is postponed until the process itself notices there is a signal (on the way out of the emulator trampoline code). In this case we haven't gone through send_signal and screwed up p_sigmask. > Anyway, I have tried code which essentially does in send_signal(): > > siglock(p); > ps->ps_oldmask = p->p_sigmask; > p->p_sigmask |= sigmask(sig); > sigunlock(p); > > sendsig(p, thread, action, sig, code, /* unused */ 0); > > and in bsd_take_signal(): > > siglock(p); > returnmask = ps->ps_oldmask; > sigunlock(p); > > . > . > . > > *old_mask = returnmask; > > This seems to work so far (and is simpler). Can anyone see any problem > with this? Any problems with sysV or linux support? > Unfortunately since send_signal is not always called, ps_oldmask is not always set correctly. Hence, you cannot just use it unconditionally. What I did was (ab)use the SA_OLDMASK flag. In send_signal, if SA_OLDMASK is not already set (SA_OLDMASK is used by sigsuspend, so don't clobber the existing ps_oldmask value if SA_OLDMASK is already set), I set the flag and set ps_oldmask to the "correct" value (as you do in your fix). Then in bsd_take_signal you don't need to do anything special. It will see that SA_OLDMASK is set and use the (correct) ps_oldmask value if we came through send_signal (or are sigsuspend'ed), otherwise it will use the p_sigmask value. This fix will be in a Lites release we will be making tonight or tomorrow. From lites-readers-owner Tue Sep 19 16:34:07 1995 id QAA22772; Tue, 19 Sep 1995 16:34:07 -0600 From: Jay Lepreau To: lites@cs.hut.fi Cc: mach4-announce@cs, mach3@cs.cmu.edu Subject: Utah Lites Release 1.1.u2 X-Url: http://www.cs.utah.edu/projects/flux/lites/html/ Date: Tue, 19 Sep 95 16:23:53 MDT Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Jay Lepreau This release of the Lites single server for Mach includes a number of enhancements made by the Flux (aka Mach4) project at the University of Utah. The release is based on Lites version 1.1.950808 from HUT. Significant Utah additions include: - Support for the ext2fs (Linux) and MS-DOS filesystems (x86 only) - Debugging support using ``Mach native'' GDB 4.14 (x86 and PA-RISC) - A good start at full Linux host support (x86 only) - HP-UX emulation (PA-RISC) - Support for using the Flux RPC prototype (PA-RISC only) - An assortment of bug fixes Source and binaries are available for the i386 (Lites, NetBSD, FreeBSD) and the PA-RISC. Full details are available off the Web page http://www.cs.utah.edu/projects/flux/lites/html/ For those who don't have convenient Web access, the main Web documents are also available in text form at ftp://flux.cs.utah.edu/flux/lites/lites-1.1.u2-html.shar Please report problems to lites-bugs@cs.utah.edu. Finally, thanks to the folks at HUT for the Lites 1.1 base, and to the main Utah contributors to this release: Mike Hibler, Godmar Back, and Steve Clawson. ----- ftp info ------ Complete ftp info and links are in the Web documents; a summary follows. On the host flux.cs.utah.edu (same as jaguar.cs.utah.edu): Lites server and emulator, sources flux/lites/lites-1.1.u2.tar.gz (1.8MB) "" Intel x86 binaries flux/binaries/i386/lites/*1.1.u2* "" HP PA-RISC binaries flux/binaries/parisc/lites/*1.1.u2* GDB 4.14 with Lites support, sources dist/gdb-4.14.u5.tar.Z (7.8MB) "" Intel x86 binary flux/binaries/i386/*gdb-4.14.u5* "" HP PA-RISC binary flux/binaries/parisc/*gdb-4.14.u5* Ext2fs utilities, sources flux/lites/mount_ext2fs.tar.gz and ftp://tsx-11.mit.edu:/pub/linux/ALPHA/ext2fs/e2fsprogs-0.5c-WIP.tar.gz "" Intel x86 binaries flux/binaries/i386/e2fsprogs-bin.tar.gz flux/binaries/i386/mount_ext2fs ------------------------------- Jay Lepreau, University of Utah lepreau@cs.utah.edu, http://www.cs.utah.edu/~lepreau/ From lites-readers-owner Tue Sep 19 21:43:25 1995 id VAA29694; Tue, 19 Sep 1995 21:43:25 -0600 Date: Wed, 20 Sep 1995 13:00:22 +0930 From: Ian Dall To: mike@cs Cc: lites@cs.hut.fi Subject: Re: Signals In-Reply-To: <199509190503.XAA03776@venus.cs.utah.edu> References: <199509190503.XAA03776@venus.cs.utah.edu> Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Ian Dall mike@cs.utah.edu (Mike Hibler) writes: > Unfortunately since send_signal is not always called, ps_oldmask is not > always set correctly. Hence, you cannot just use it unconditionally. > What I did was (ab)use the SA_OLDMASK flag. In send_signal, if SA_OLDMASK > is not already set (SA_OLDMASK is used by sigsuspend, so don't clobber the > existing ps_oldmask value if SA_OLDMASK is already set), I set the flag and > set ps_oldmask to the "correct" value (as you do in your fix). Then in > bsd_take_signal you don't need to do anything special. It will see that > SA_OLDMASK is set and use the (correct) ps_oldmask value if we came through > send_signal (or are sigsuspend'ed), otherwise it will use the p_sigmask value. Right. I have also noticed what appears to be another signal bug. The emulator, on receiving a signal notify, or returning from a system call goes into a loop calling take_signal until there are no signals left. However, in the server, bsd_take_signal doesn't check if the signal is masked or not. Thus masking a signal will stop delivery only until either an unmasked signal is delivered, or a system call completes, and then all the signals, whether masked or not, will be taken. I believe this can be fixed in bsd_take_signal() by sig = ffs(p->p_siglist & ~p->p_sigmask); instead of just sig = ffs(p->p_siglist); Ian From lites-readers-owner Wed Sep 20 19:01:40 1995 id TAA21643; Wed, 20 Sep 1995 19:01:40 -0600 Date: Thu, 21 Sep 1995 10:14:45 +0930 From: Ian Dall To: mike@cs, lites@cs.hut.fi Subject: Re: Signals In-Reply-To: <199509200330.NAA01754@hfrd015.dsto.gov.au> References: <199509190503.XAA03776@venus.cs.utah.edu> <199509200330.NAA01754@hfrd015.dsto.gov.au> Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Ian Dall I, Ian Dall wrote: > Right. I have also noticed what appears to be another signal bug. > The emulator, on receiving a signal notify, or returning from a system > call goes into a loop calling take_signal until there are no signals > left. However, in the server, bsd_take_signal doesn't check if the > signal is masked or not. Thus masking a signal will stop delivery only > until either an unmasked signal is delivered, or a system call > completes, and then all the signals, whether masked or not, will be > taken. > I believe this can be fixed in bsd_take_signal() by > sig = ffs(p->p_siglist & ~p->p_sigmask); > instead of just > sig = ffs(p->p_siglist); I think my above analysis of the problem is correct, but my solution is not. The correct solution is not obvious. The difficulty is that depending on how we got to bsd_take_signal(), there is no reliable mask to apply. If we came from send_signal, p->p_sigmask already has the "current" signal added to it. ps->ps_oldmask in this case has the mask which applied at the time the signal was posted. However, in the case of coming through sigsuspend, the new mask is the one which is relevant. I think that p->p_sigmask should not be automatically changed until the process has actually taken the signal through bsd_take_signal, however, when I tried that I got into problems. Ian From lites-readers-owner Sun Oct 8 21:52:37 1995 id VAA26558; Sun, 8 Oct 1995 21:52:37 -0600 Date: Mon, 9 Oct 1995 12:32:24 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: Signals Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Ian Dall I have been trying to track down a bug in the signal handling code in lites. I have already found and fixed a few things, but not the bug which is especially troubling me! The problem is that I have a test program with a floating point signal handler. The signal handler decodes the floating point instruction to emulate correct divide by zero and underflow behaviour etc. This actually works most of the time. The trouble is, I can run it repeatedly (all data for now is hard coded) and occasionally, the program counter in the signal state is not at a floating point instruction. It is usually somewhere in the emulator code. The signal handler does some printf's and the traps with the bad addresses seem to occur during the write system call. It looks like either the trapping thread did not properly block in exception raise, or else it got resumed prematurely somehow. The latter seems more plausable since system calls are also traps and if MK was somehow not blocking the thread properly, I would have guessed I would have seen more problems than I have. The test program is essentially single threaded, except for the signal notify thread, so it is hard to see how any floating point instruction could be executed while in a write system call! This is difficult to debug. I can put a breakpoint in lites in thread_signal when a SIGFPE occurs and it is already masked. This coincides with the bad address OK. The trouble is, it is too late. Whatever has caused the thread to resume has already done it by then! Observing this problem seems to coincide with running it in an emacs shell window. Running it with output to /dev/null, to to a normal tty seems to be OK. (Difficult to be sure since it may take many tries before it happens anyway). A possible theory is that action on the master side of the pty generates some sort of event which wakes up threads on the slave side of the pty. Is this possible, can anyone think of a mechanism? Any clues, even wild speculation, gratefully accepted since I am just about out of ideas. Ian From lites-readers-owner Wed Oct 11 12:44:28 1995 id MAA02622; Wed, 11 Oct 1995 12:44:28 -0600 Date: Wed, 11 Oct 1995 18:02:37 +0100 (MET) From: "Josep M. Blanquer" X-Sender: tete@scorpius To: Lites mailing list Cc: "Josep M. Blanquer" Subject: Multiprocessor? Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-lites-readers@cs Precedence: bulk Reply-To: "Josep M. Blanquer" Hi, It is possible to have the mach4 system running on two machines to have a distributed system? (through an ethernet card) Does lites support it? if not, there is another solution? Hurd.... What has to be done? I have tried to compile the mach system, but there are some functions not defined in a multiprocessor mode, like cpu_number......etc Where have to be defined ?? Any clues ? Any help would be very appreciated! Thanks. --------------------------------------------------------------------------- Josep Ma. Blanquer Gonzalez (tete@els.url.es) Computer Science Department La Salle University (Catalonia -Spain-) --------------------------------------------------------------------------- From lites-readers-owner Thu Oct 12 20:24:22 1995 id UAA06343; Thu, 12 Oct 1995 20:24:22 -0600 Date: Fri, 13 Oct 1995 11:42:14 +0930 From: Ian Dall To: lites@cs.hut.fi Subject: lites available with signal fixes Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Ian Dall I have spent quite a bit of effort fixing signal bugs in lites. I will include differences against lites-1.1-u2 at the end of this message. Also, I have made both the differences, a tar of the complete changed files and a tar of the entire lites distribution available for ftp from: augean.eleceng.adelaide.edu.au:pub/mach/lites (You only *need* the diffs, but some people find it more convenient to not have to run patch). Here are the main problems which have been fixed: * There was a race where a thread which experienced an exception could be unblocked before it was suspended in the emulator. * There was some code commented out preventing the delivery of asynchronous signals. This appears to work now. If it still doesn't work for some architecture it may be an achitecture specific problem. * In many places, p_siglist was consulted without applying p_sigmask. When a process got a signal, or did a system call, all signals, whether masked or not, would be taken. If this is fixed in just some places, it can result in bigger problems. There are macros for these things (HAVE_SIGNALS and CURSIG) so I used them. * With the above fix, the "abuse" of oldmask in a previous patch breaks badly. p_sigmask must not be set until the signal is actually taken or else the wrong mask will be applied in bsd_take_signal and the signal will never be delivered. * Use ffs() rather than find_first_set_bit(). The former can be inlined by gcc for many achitectures and is already used in the ufs code. * Some pc532 specific patches to make the sigcontext compatable with netbsd. Where (or who) is the "central repository" for lites now? It would be nice if someone could continue to coordinate various patches and maintain an "official" source. Thanks to Johannes for useful discussions on the signal handling code. Johannes would like much of the signal handling code to be moved to the emulator. This seems like a good idea (especially for trap handling), but for now, I was more interested in making it work better. Ian *** ../../../hut/src/lites-1.1.u2/./conf/MASTER.local Sat Mar 4 10:51:33 1995 --- ./conf/MASTER.local Fri Sep 22 21:28:21 1995 *************** *** 1,4 **** /* jvh 941014 */ ! options standard TIMEZONE 420 timezone.h ! options standard DST DST_USA dst.h --- 1,4 ---- /* jvh 941014 */ ! options standard TIMEZONE 570 timezone.h ! options standard DST DST_AUST dst.h *** ../../../hut/src/lites-1.1.u2/./emulator/ns532/e_machinedep.c Thu Mar 23 10:45:37 1995 --- ./emulator/ns532/e_machinedep.c Thu Sep 28 07:33:44 1995 *************** *** 17,22 **** --- 17,25 ---- */ /* * HISTORY + * 02-Sep-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Make sigcontext conform to the netbsd definition. + * * $Log$ */ /* *************** *** 53,72 **** * Set up registers for child. It resumes on its own stack. */ - #if 0 - /* Prevent caching of caller saved registers. They are destroyed */ - asm volatile("nop" - : /* no inputs */ - : /* no outputs */ - : "r0", "r1", "r2", "cc"); - #endif x = emul_save_state(&state); - #if 0 - asm volatile("nop" - : /* no inputs */ - : /* no outputs */ - : "r0", "r1", "r2", "cc"); - #endif if (x != 0) { *ischild = TRUE; *pid = x; --- 56,62 ---- *************** *** 227,243 **** sc.sc_mask = old_mask; sc.sc_pc = state->pc; ! sc.sc_psr = state->psr; sc.sc_sp = state->sp; sc.sc_fp = state->fp; /* Then just call it */ (*handler)(sig, code, &sc); state->pc = sc.sc_pc; ! state->psr = sc.sc_psr; state->sp = sc.sc_sp; state->fp = sc.sc_fp; } } --- 217,249 ---- sc.sc_mask = old_mask; sc.sc_pc = state->pc; ! sc.sc_ps = state->psr; sc.sc_sp = state->sp; sc.sc_fp = state->fp; + sc.sc_reg[0] = state->r0; + sc.sc_reg[1] = state->r1; + sc.sc_reg[2] = state->r2; + sc.sc_reg[3] = state->r3; + sc.sc_reg[4] = state->r4; + sc.sc_reg[5] = state->r5; + sc.sc_reg[6] = state->r6; + sc.sc_reg[7] = state->r7; /* Then just call it */ (*handler)(sig, code, &sc); state->pc = sc.sc_pc; ! state->psr = sc.sc_ps; state->sp = sc.sc_sp; state->fp = sc.sc_fp; + state->r0 = sc.sc_reg[0]; + state->r1 = sc.sc_reg[1]; + state->r2 = sc.sc_reg[2]; + state->r3 = sc.sc_reg[3]; + state->r4 = sc.sc_reg[4]; + state->r5 = sc.sc_reg[5]; + state->r6 = sc.sc_reg[6]; + state->r7 = sc.sc_reg[7]; } } *************** *** 262,280 **** struct ns532_thread_state state; volatile int x; - #if 0 - asm volatile("nop" - : /* no inputs */ - : /* no outputs */ - : "r0", "r1", "r2", "cc"); - #endif x = emul_save_state(&state); - #if 0 - asm volatile("nop" - : /* no inputs */ - : /* no outputs */ - : "r0", "r1", "r2", "cc"); - #endif /* * Check for longjmp or sigreturn out of handler. */ --- 268,274 ---- *************** *** 342,348 **** emul_save_state(&state); state.pc = sc->sc_pc; ! state.psr = sc->sc_psr; state.sp = sc->sc_sp; state.fp = sc->sc_fp; state.r0 = 1; --- 336,342 ---- emul_save_state(&state); state.pc = sc->sc_pc; ! state.psr = sc->sc_ps; state.sp = sc->sc_sp; state.fp = sc->sc_fp; state.r0 = 1; *** ../../../hut/src/lites-1.1.u2/./emulator/ns532/e_signal.c Fri Mar 3 08:19:29 1995 --- ./emulator/ns532/e_signal.c Thu Oct 12 05:50:45 1995 *************** *** 145,151 **** * the sp. The only thing saved by the call instruction is the pc. */ *(int *)(sp-4) = sp; ! *(int *)(sp-8) = 0; /* frame pc */ sp -= 8; /* Go to trampoline */ --- 145,153 ---- * the sp. The only thing saved by the call instruction is the pc. */ *(int *)(sp-4) = sp; ! *(int *)(sp-8) = 0; /* frame pc doesn't matter since we ! * long jump out of e_i_got_a_signal ! */ sp -= 8; /* Go to trampoline */ *** ../../../hut/src/lites-1.1.u2/./emulator/ns532/emul_vector.s Fri Mar 3 08:19:29 1995 --- ./emulator/ns532/emul_vector.s Thu Sep 28 07:33:25 1995 *************** *** 42,60 **** */ .globl _emul_trampoline _emul_trampoline: - #if 1 save [r0,r1,r2,r3,r4,r5,r6,r7] - #else - movd r0,tos /* save registers that C does not */ - movd r1,tos - movd r2,tos - - movd r3,tos - movd r4,tos - movd r5,tos - movd r6,tos - movd r7,tos - #endif sprd fp,tos sprd sb,tos lprd sb,0 /* the C-compiler may need this */ --- 42,48 ---- *************** *** 69,87 **** _emul_exit: lprd sb,tos lprd fp,tos - #if 1 restore [r0,r1,r2,r3,r4,r5,r6,r7] - #else - movd tos,r7 - movd tos,r6 - movd tos,r5 - movd tos,r4 - movd tos,r3 - - movd tos,r2 - movd tos,r1 - movd tos,r0 - #endif lprd us, tos /* load psr */ ret 0 --- 57,63 ---- *** ../../../hut/src/lites-1.1.u2/./include/ns532/signal.h Fri Mar 3 08:19:37 1995 --- ./include/ns532/signal.h Wed Oct 11 07:55:02 1995 *************** *** 38,43 **** --- 38,48 ---- * * Author: Ian Dall * September 1994 + * + * HISTORY + * 11-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Make sigcontext conform with netbsd. Add more FPE codes. + * */ typedef int sig_atomic_t; *************** *** 48,53 **** --- 53,59 ---- #define ILL_PRIVIN_FAULT 0x1 /* privileged instruction fault */ #define ILL_RESOP_FAULT 0x2 /* reserved operand fault */ + #define FPE_INTOVF_TRAP 0x1 /* integer overflow */ #define FPE_INTDIV_TRAP 0x2 /* integer divide by zero */ #define FPE_FLTOVF_TRAP 0x3 /* floating overflow */ *************** *** 58,63 **** --- 64,73 ---- #define FPE_FLTOVF_FAULT 0x8 /* floating overflow fault */ #define FPE_FLTDIV_FAULT 0x9 /* divide by zero floating fault */ #define FPE_FLTUND_FAULT 0xa /* floating underflow fault */ + #define FPE_INVALID_FAULT 0xc /* floating invalid operand */ + #define FPE_INEXACT_FAULT 0xd /* floating inexact result */ + + #define FPE_FLG_TRAP 0xe /* flag instruction trap */ /* * Information pushed on stack when a signal is delivered. *************** *** 67,85 **** * a non-standard exit is performed. */ struct sigcontext { ! int sc_onstack; /* sigstack state to restore */ ! int sc_mask; /* signal mask to restore */ ! int sc_r0; /* 8 */ ! int sc_r1; /* 12 */ ! int sc_r2; /* 16 */ ! int sc_r3; /* 20 */ ! int sc_r4; ! int sc_r5; ! int sc_r6; ! int sc_r7; ! int sc_sb; /* 40 */ ! int sc_fp; ! int sc_sp; /* 48 */ ! int sc_psr; ! int sc_pc; /* 56 */ }; --- 77,88 ---- * a non-standard exit is performed. */ struct sigcontext { ! int sc_onstack; /* sigstack state to restore */ ! int sc_mask; /* signal mask to restore */ ! int sc_sp; /* sp to restore */ ! int sc_fp; /* fp to restore */ ! int sc_sb; /* sb to restore */ ! int sc_pc; /* pc to restore */ ! int sc_ps; /* psl to restore */ ! int sc_reg[8]; /* The registers */ }; *** ../../../hut/src/lites-1.1.u2/./include/sys/signalvar.h Fri Mar 3 08:19:34 1995 --- ./include/sys/signalvar.h Thu Oct 12 07:18:54 1995 *************** *** 32,37 **** --- 32,43 ---- * * @(#)signalvar.h 8.3 (Berkeley) 1/4/94 */ + /* + * HISTORY + * 11-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Add SAS_NOTIFY_DONE flag. + * + */ #ifndef _SYS_SIGNALVAR_H_ /* tmp for user.h */ #define _SYS_SIGNALVAR_H_ *************** *** 62,67 **** --- 68,74 ---- /* signal flags */ #define SAS_OLDMASK 0x01 /* need to restore mask before pause */ #define SAS_ALTSTACK 0x02 /* have alternate signal stack */ + #define SAS_NOTIFY_DONE 0x04 /* signal notify already done */ /* additional signal action values, used only temporarily/internally */ #define SIG_CATCH (void (*)())2 *************** *** 169,174 **** /* * Machine-dependent functions: */ ! void sendsig __P((struct proc *, thread_t thread, sig_t action, int sig, unsigned code, int returnmask)); #endif /* KERNEL */ #endif /* !_SYS_SIGNALVAR_H_ */ --- 176,181 ---- /* * Machine-dependent functions: */ ! boolean_t sendsig __P((struct proc *, thread_t thread, sig_t action, int sig, unsigned code, int returnmask)); #endif /* KERNEL */ #endif /* !_SYS_SIGNALVAR_H_ */ *** ../../../hut/src/lites-1.1.u2/./server/conf/MASTER.local Fri Mar 3 09:59:32 1995 --- ./server/conf/MASTER.local Fri Sep 22 21:50:08 1995 *************** *** 1 **** ! makeoptions LOCAL_DEFINES="-DTIMEZONE=420 -DDST=DST_USA" --- 1 ---- ! makeoptions LOCAL_DEFINES="-DTIMEZONE=570 -DDST=DST_AUST" *** ../../../hut/src/lites-1.1.u2/./server/kern/kern_sig.c Sat Sep 9 02:27:48 1995 --- ./server/kern/kern_sig.c Thu Oct 12 07:45:05 1995 *************** *** 17,22 **** --- 17,32 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Use ffs() instead of find_first_set_bit() since the former can be + * inlined. + * + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Ignore value returned by send_signal(). + * + * 30-Sep-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Re-enable direct signals. Race appears to be fixed. + * * $Log$ * */ *************** *** 266,272 **** * and are now ignored by default). */ while (p->p_sigcatch) { ! nc = find_first_set_bit((long)p->p_sigcatch); mask = sigmask(nc); p->p_sigcatch &= ~mask; if (sigprop[nc] & SA_IGNORE) { --- 276,282 ---- * and are now ignored by default). */ while (p->p_sigcatch) { ! nc = ffs((long)p->p_sigcatch); mask = sigmask(nc); p->p_sigcatch &= ~mask; if (sigprop[nc] & SA_IGNORE) { *************** *** 744,749 **** --- 754,760 ---- #define SIGX1 1 #define SIGX2 0 #define SIGX3 0 + #define SIGX4 1 void psignal(p, signum) *************** *** 977,983 **** } #endif } ! #if 0 /* XXX there is apparently a race here. With this defined we (on the PA) get regular segmentation faults from various programs. What must be happening is that we mark the signal, send a message to the signal thread, the --- 988,994 ---- } #endif } ! #if SIGX4 /* XXX there is apparently a race here. With this defined we (on the PA) get regular segmentation faults from various programs. What must be happening is that we mark the signal, send a message to the signal thread, the *************** *** 994,1000 **** unsleep_process(p); #endif else ! send_signal(p, p->p_thread, signum, 0); goto out; } #endif /* 0: avoid race */ --- 1005,1011 ---- unsleep_process(p); #endif else ! (void) send_signal(p, p->p_thread, signum, 0); goto out; } #endif /* 0: avoid race */ *************** *** 1053,1059 **** /* * Send signal to user thread. */ ! send_signal(p, p->p_thread, signum, 0); break; } } --- 1064,1070 ---- /* * Send signal to user thread. */ ! (void) send_signal(p, p->p_thread, signum, 0); break; } } *************** *** 1084,1090 **** mask &= ~stopsigmask; if (mask == 0) /* no signal to send */ return (0); ! signum = find_first_set_bit((long)mask); mask = sigmask(signum); prop = sigprop[signum]; /* --- 1095,1101 ---- mask &= ~stopsigmask; if (mask == 0) /* no signal to send */ return (0); ! signum = ffs((long)mask); mask = sigmask(signum); prop = sigprop[signum]; /* *** ../../../hut/src/lites-1.1.u2/./server/kern/subr_xxx.c Fri Mar 3 08:19:45 1995 --- ./server/kern/subr_xxx.c Thu Oct 12 07:47:03 1995 *************** *** 15,20 **** --- 15,24 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Remove find_first_set_bit() function since we can use ffs(), + * which can be inlined, instead. + * * $Log$ */ /* *************** *** 69,89 **** #include #include - - unsigned int find_first_set_bit(unsigned int mask) - { - unsigned int bit; - - if (!mask) - return 0; - for (bit = 1; ; bit++) { - if (mask & 1) - return bit; - mask >>= 1; - } - panic("ffs"); - return 0; - } /* * Unsupported device function (e.g. writing to read-only device). --- 73,78 ---- *** ../../../hut/src/lites-1.1.u2/./server/ns532/ns532_exception.c Fri Mar 3 08:19:42 1995 --- ./server/ns532/ns532_exception.c Fri Sep 22 21:50:04 1995 *************** *** 16,21 **** --- 16,27 ---- * JOHANNES HELANDER AND IAN DALL DISCLAIM ANY LIABILITY OF ANY KIND * FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE. */ + /* HISTORY + * 07-Apr-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Add subcode handling for fpu traps. Make sure unix_code doesn`t + * get altered unless machine_exception succeeds. + * + */ #include #include *************** *** 27,70 **** machine_exception(integer_t exception, integer_t code, integer_t subcode, int *unix_signal, int *unix_code) { ! switch(exception) { ! case EXC_BAD_INSTRUCTION: ! *unix_signal = SIGILL; ! switch (code) { ! case EXC_NS532_ILL: ! *unix_code = ILL_PRIVIN_FAULT; ! case EXC_NS532_UND: ! *unix_code = ILL_RESOP_FAULT; ! break; ! default: ! return(FALSE); ! } ! break; ! ! case EXC_ARITHMETIC: ! *unix_signal = SIGFPE; ! switch (code) { ! case EXC_NS532_OVF: ! *unix_code = FPE_INTOVF_TRAP; ! break; ! case EXC_NS532_DVZ: ! *unix_code = FPE_INTDIV_TRAP; ! break; ! case EXC_NS532_FLG: ! *unix_code = 0; ! break; ! default: ! return(FALSE); ! } ! break; ! ! case EXC_BREAKPOINT: ! *unix_signal = SIGTRAP; ! break; ! ! default: ! return(FALSE); ! } ! return(TRUE); } --- 33,104 ---- machine_exception(integer_t exception, integer_t code, integer_t subcode, int *unix_signal, int *unix_code) { ! integer_t return_signal = 0, return_code = 0; ! switch(exception) { ! case EXC_BAD_INSTRUCTION: ! return_signal = SIGILL; ! switch (code) { ! case EXC_NS532_ILL: ! return_code = ILL_PRIVIN_FAULT; ! break; ! case EXC_NS532_UND: ! return_code = ILL_RESOP_FAULT; ! break; ! default: ! return(FALSE); ! } ! break; ! ! case EXC_ARITHMETIC: ! return_signal = SIGFPE; ! switch (code) { ! case EXC_NS532_OVF: ! return_code = FPE_INTOVF_TRAP; ! break; ! case EXC_NS532_DVZ: ! return_code = FPE_INTDIV_TRAP; ! break; ! case EXC_NS532_FLG: ! return_code = FPE_FLG_TRAP; ! break; ! case EXC_NS532_SLAVE: ! switch(subcode & 7) { ! case 1: ! return_code = FPE_FLTUND_TRAP; ! break; ! case 2: ! return_code = FPE_FLTOVF_FAULT; ! break; ! case 3: ! return_code = FPE_FLTDIV_TRAP; ! break; ! case 4: ! return_signal = SIGILL; ! return_code = 0; ! break; ! case 5: ! return_code = FPE_INVALID_FAULT; ! break; ! case 6: ! return_code = FPE_INEXACT_FAULT; ! break; ! } ! break; ! default: ! return_code = 0; ! return(FALSE); ! } ! break; ! ! case EXC_BREAKPOINT: ! return_signal = SIGTRAP; ! break; ! ! default: ! return(FALSE); ! } ! *unix_signal = return_signal; ! *unix_code = return_code; ! return(TRUE); } *** ../../../hut/src/lites-1.1.u2/./server/serv/select.c Fri Mar 3 08:19:48 1995 --- ./server/serv/select.c Thu Oct 12 07:45:11 1995 *************** *** 15,20 **** --- 15,24 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Use ffs() instead of find_first_set() since the former can be + * inlined. + * * $Log$ */ /* *************** *** 192,198 **** for (i = 0; i < nd; i += NFDBITS) { bits = iset->fds_bits[i/NFDBITS]; ! while ((j = find_first_set_bit(bits)) && (fd = i + --j) < nd) { bits &= ~(1 << j); --- 196,202 ---- for (i = 0; i < nd; i += NFDBITS) { bits = iset->fds_bits[i/NFDBITS]; ! while ((j = ffs(bits)) && (fd = i + --j) < nd) { bits &= ~(1 << j); *** ../../../hut/src/lites-1.1.u2/./server/serv/sendsig.c Thu Mar 23 10:46:58 1995 --- ./server/serv/sendsig.c Thu Oct 12 06:30:53 1995 *************** *** 15,20 **** --- 15,23 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Make sendsig return notified/failed. + * * $Log$ */ /* *************** *** 32,40 **** #include #include ! /* Replaces the code in i386/machdep.c */ ! ! void sendsig( struct proc *p, thread_t thread, sig_t action, --- 35,46 ---- #include #include ! /* Return TRUE if the message was successfully sent to the task. ! * This is needed at a higer level by catch_exception_raise() ! * so it can know not to reply if the task will unblock the ! * exception its self. ! */ ! boolean_t sendsig( struct proc *p, thread_t thread, sig_t action, *************** *** 45,58 **** kern_return_t kr; if (!MACH_PORT_VALID(p->p_sigport) || !MACH_PORT_VALID(thread)) ! return; /* Add a send right. signal_notify consumes it. */ kr = port_object_copy_send(thread); assert(kr == KERN_SUCCESS); kr = signal_notify(p->p_sigport, thread); ! if (kr) ! printf("signal_notify failed pid=%d: %s\n", ! p->p_pid, mach_error_string(kr)); } --- 51,67 ---- kern_return_t kr; if (!MACH_PORT_VALID(p->p_sigport) || !MACH_PORT_VALID(thread)) ! return FALSE; /* Add a send right. signal_notify consumes it. */ kr = port_object_copy_send(thread); assert(kr == KERN_SUCCESS); kr = signal_notify(p->p_sigport, thread); ! if (kr) { ! printf("signal_notify failed pid=%d: %s\n", ! p->p_pid, mach_error_string(kr)); ! return FALSE; ! } ! return TRUE; } *** ../../../hut/src/lites-1.1.u2/./server/serv/serv_synch.c Thu Mar 23 10:46:51 1995 --- ./server/serv/serv_synch.c Mon Oct 9 17:31:19 1995 *************** *** 17,22 **** --- 17,25 ---- */ /* * HISTORY + * 09-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Use CURSIG and HAVE_SIGNALS rather than test siglist directly. + * * $Log$ */ /* *************** *** 256,262 **** p->p_flag |= P_SINTR; /* must ttysleep but not sigpause on exit */ if (((p->p_flag&P_WEXIT) && ((pri & PRIMASK) == PPAUSE)) - || (sig = p->p_siglist) != 0 || HAVE_SIGNALS(p)) { int ret = 0; thread_unsleep_internal(pk); --- 259,264 ---- *************** *** 265,271 **** if (p->p_stat == SSLEEP) p->p_stat = SRUN; p->p_flag &= ~P_SINTR; ! if (sig != 0 || (sig = CURSIG(p))) { if (p->p_sigacts->ps_sigintr & sigmask(sig)) ret = EINTR; else --- 267,273 ---- if (p->p_stat == SSLEEP) p->p_stat = SRUN; p->p_flag &= ~P_SINTR; ! if ((sig = CURSIG(p))) { if (p->p_sigacts->ps_sigintr & sigmask(sig)) ret = EINTR; else *** ../../../hut/src/lites-1.1.u2/./server/serv/serv_syscalls.c Sat Sep 9 02:29:25 1995 --- ./server/serv/serv_syscalls.c Thu Oct 12 06:27:14 1995 *************** *** 17,22 **** --- 17,37 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Allow for sendsig to return a "task notified" status. + * + * 11-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Use HAVE_SIGNALS and CURSIG instead of testing p_siglist + * directly. + * + * 30-Sep-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Use SAS_NOTIFY_DONE flag to indicate that the process has already been + * told there are signals waiting. + * + * 30-Sep-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Removed definition for SIG_CATCH and SIG_HOLD and SA_OLDMASK. + * These are defined in sigvar.h + * * $Log$ * */ *************** *** 50,62 **** /* XXX */ extern int sigprop[NSIG+1]; - /* signal flags */ - #define SA_OLDMASK 0x01 /* need to restore mask before pause */ - - /* additional signal action values, used only temporarily/internally */ - #define SIG_CATCH (void (*)())2 - #define SIG_HOLD (void (*)())3 - #define ps_onstack ps_sigstk.ss_flags /* end XXX */ --- 65,70 ---- *************** *** 346,352 **** * Send the signal to a thread. The thread must not be executing * any kernel calls. */ ! void send_signal( struct proc *p, thread_t thread, int sig, --- 354,360 ---- * Send the signal to a thread. The thread must not be executing * any kernel calls. */ ! boolean_t send_signal( struct proc *p, thread_t thread, int sig, *************** *** 354,359 **** --- 362,368 ---- { register int mask; int returnmask; + boolean_t notified = FALSE; register struct sigacts *ps = p->p_sigacts; register sig_t action; *************** *** 363,374 **** mask = sigmask(sig); /* - * At this point, thread is in either exception_raise, - * or emulator::take_signal, waiting for a reply message. - * There should be no need to suspend it. - */ - - /* * Signal action may have changed while we blocked for * task_suspend or thread_abort. Check it again. */ --- 372,377 ---- *************** *** 380,427 **** */ psignal(p, sig); (void) task_resume(p->p_task); ! return; } - /* if (p->p_flag & SOUSIG) { - if (sig != SIGILL && sig != SIGTRAP) { - ps->ps_sigact[sig]= SIG_DFL; - p->p_sigcatch &= ~mask; - } - mask = 0; - } - */ - siglock(p); - /* - * In Lites we have a problem with the signal mask when we go - * through this path. When we go through the signal thread to - * deliver the signal (i.e. sendsig) the returnmask is not passed. - * The signal thread just redirects the main thread to a stub routine - * which calls bsd_take_signal to get the mask (and other signal state). - * bsd_take_signal wants to use p_sigmask as the return mask but - * that won't work since we have masked the current signal before - * calling sendsig. The result is that the handler would take the - * signal but then return with that signal improperly masked. - * - * So, we (ab)use the ps_oldmask field. If SA_OLDMASK is set, - * bsd_take_signal will pull the return mask from ps_oldmask. - * We just set ps_oldmask here (if it isn't already set due to a - * sigsuspend) and bsd_take_signal should return the right mask! - */ - if (!(ps->ps_flags & SA_OLDMASK)) { - ps->ps_oldmask = p->p_sigmask; - ps->ps_flags |= SA_OLDMASK; - } - p->p_sigmask |= mask; - returnmask = ps->ps_oldmask; /* XXX not used */ - sigunlock(p); ! sendsig(p, thread, action, sig, code, returnmask); /* ! * At this point, thread is in either exception_raise, ! * or emulator::take_signal, waiting for a reply message. ! * The reply message should resume it. ! */ } /* --- 383,404 ---- */ psignal(p, sig); (void) task_resume(p->p_task); ! return FALSE; } ! if (ps->ps_flags & SAS_NOTIFY_DONE) ! return FALSE; /* ! * At this point, the thread may be in exception_raise, ! * waiting for a reply message. A reply message should resume ! * it. We don't want a reply if the task is handling it its self. ! */ ! notified = sendsig(p, thread, action, sig, code, /* unused */ 0); ! if (notified) { ! ps->ps_flags |= SAS_NOTIFY_DONE; ! } ! return notified; } /* *************** *** 493,501 **** sig_default(p, sig); } ! void thread_signal(struct proc *p, thread_t thread, int sig, int code) { int mask; mask = sigmask(sig); --- 470,479 ---- sig_default(p, sig); } ! boolean_t thread_signal(struct proc *p, thread_t thread, int sig, int code) { int mask; + boolean_t notified = FALSE; mask = sigmask(sig); *************** *** 506,517 **** * Save the signal in p_sig. */ p->p_siglist |= mask; ! return; } while (p->p_stat == SSTOP || (p->p_flag & P_WEXIT)) { if (p->p_flag & P_WEXIT) { ! return; } sleep((caddr_t)&p->p_stat, 0); } --- 484,495 ---- * Save the signal in p_sig. */ p->p_siglist |= mask; ! return FALSE; } while (p->p_stat == SSTOP || (p->p_flag & P_WEXIT)) { if (p->p_flag & P_WEXIT) { ! return FALSE; } sleep((caddr_t)&p->p_stat, 0); } *************** *** 529,546 **** sleep((caddr_t)&p->p_stat, 0); if (p->p_flag & P_WEXIT) { ! return; } if ((p->p_flag & P_TRACED) == 0) { continue; } ! sig = p->p_siglist; ! if (sig == 0) { ! return; } mask = sigmask(sig); if (p->p_sigmask & mask) { continue; --- 507,524 ---- sleep((caddr_t)&p->p_stat, 0); if (p->p_flag & P_WEXIT) { ! return FALSE; } if ((p->p_flag & P_TRACED) == 0) { continue; } ! if (!HAVE_SIGNALS(p)) { ! return FALSE; } + sig = CURSIG(p); mask = sigmask(sig); if (p->p_sigmask & mask) { continue; *************** *** 568,583 **** siglock(p); p->p_siglist |= mask; sigunlock(p); ! send_signal(p, thread, sig, code); break; } } /* * New thread_psignal. Runs as part of the normal service - thus * we have a thread per user exception, so it can wait. */ ! void thread_psignal( task_t task, thread_t thread, register int sig, --- 546,562 ---- siglock(p); p->p_siglist |= mask; sigunlock(p); ! notified = send_signal(p, thread, sig, code); break; } + return notified; } /* * New thread_psignal. Runs as part of the normal service - thus * we have a thread per user exception, so it can wait. */ ! boolean_t thread_psignal( task_t task, thread_t thread, register int sig, *************** *** 585,590 **** --- 564,570 ---- { register struct proc *p; proc_invocation_t pk = get_proc_invocation(); + boolean_t notified = FALSE; /* * XXX port_object_send_lookup will consume the task reference *************** *** 598,608 **** SD(printf("%8x[%d]: thread_psignal %x\n",p,p->p_pid, sig)); if (p == 0) { (void) task_terminate(task); ! return; } if (sig < 0 || sig > NSIG) { mutex_unlock(&p->p_lock); ! return; } /* --- 578,588 ---- SD(printf("%8x[%d]: thread_psignal %x\n",p,p->p_pid, sig)); if (p == 0) { (void) task_terminate(task); ! return FALSE; } if (sig < 0 || sig > NSIG) { mutex_unlock(&p->p_lock); ! return FALSE; } /* *************** *** 612,618 **** mutex_unlock(&p->p_lock); unix_master(); ! thread_signal(p, thread, sig, code); unix_release(); --- 592,598 ---- mutex_unlock(&p->p_lock); unix_master(); ! notified = thread_signal(p, thread, sig, code); unix_release(); *************** *** 620,625 **** --- 600,606 ---- if (p->p_flag & P_WEXIT) wakeup((caddr_t)&p->p_flag); + return notified; } /* *************** *** 689,717 **** /* * Get pending signal. */ ! sig = ffs(p->p_siglist); ! if (!(sig > 0 && sig < NSIG)) ! sig = 0; ! if (sig != 0) { ! p->p_siglist &= ~sigmask(sig); ! } ! else { ! /* ! * If no pending signal, get from signal masks. ! * Yes, this can happen. ! */ ! mutex_lock(&p->p_lock); /* XXX Entire funct should be locked */ ! sig = issignal(p); ! mutex_unlock(&p->p_lock); ! } if (sig == 0) { /* * No signals - return to user. */ unix_release(); return (end_server_op(p, 0, (boolean_t *)0)); } action = ps->ps_sigact[sig]; switch ((vm_offset_t)action) { case SIG_IGN: --- 670,688 ---- /* * Get pending signal. */ ! mutex_lock(&p->p_lock); /* XXX Entire funct should be locked */ ! sig = CURSIG(p); ! mutex_unlock(&p->p_lock); if (sig == 0) { /* * No signals - return to user. */ + ps->ps_flags &= ~SAS_NOTIFY_DONE; unix_release(); return (end_server_op(p, 0, (boolean_t *)0)); } + p->p_siglist &= ~sigmask(sig); action = ps->ps_sigact[sig]; switch ((vm_offset_t)action) { case SIG_IGN: *************** *** 741,757 **** sig = 0; break; } ! /* if (p->p_flag & SOUSIG) { ! if (sig != SIGILL && sig != SIGTRAP) { ! ps->ps_sigact[sig]= SIG_DFL; ! p->p_sigcatch &= ~mask; ! } ! mask = 0; ! } ! */ ! if (ps->ps_flags & SA_OLDMASK) { returnmask = ps->ps_oldmask; ! ps->ps_flags &= ~SA_OLDMASK; } else returnmask = p->p_sigmask; --- 712,720 ---- sig = 0; break; } ! if (ps->ps_flags & SAS_OLDMASK) { returnmask = ps->ps_oldmask; ! ps->ps_flags &= ~SAS_OLDMASK; } else returnmask = p->p_sigmask; *************** *** 774,779 **** --- 737,744 ---- break; } + if (*o_sig == 0) + ps->ps_flags &= ~SAS_NOTIFY_DONE; unix_release(); return (end_server_op(p, 0, (boolean_t *)0)); } *** ../../../hut/src/lites-1.1.u2/./server/serv/syscall_subr.c Wed Sep 6 09:47:40 1995 --- ./server/serv/syscall_subr.c Wed Oct 11 07:54:54 1995 *************** *** 17,22 **** --- 17,26 ---- */ /* * HISTORY + * 11-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Rely on HAVE_SIGNALS and CURSIG instead of using p_siglist + * directly. + * * $Log$ * */ *************** *** 122,128 **** mutex_unlock(&p->p_lock); /* XXX */ return (MIG_NO_REPLY); } ! if (p->p_siglist && syscode < 1000) { mutex_unlock(&p->p_lock); /* XXX */ return (ERESTART); } --- 126,132 ---- mutex_unlock(&p->p_lock); /* XXX */ return (MIG_NO_REPLY); } ! if (HAVE_SIGNALS(p) && syscode < 1000) { mutex_unlock(&p->p_lock); /* XXX */ return (ERESTART); } *************** *** 209,220 **** if (p->p_flag & P_WEXIT) { int sig; ! if (p->p_siglist != 0 || HAVE_SIGNALS(p)) { unix_master(); mutex_lock(&p->p_lock); ! if ((sig = p->p_siglist) || (sig = issignal(p))) psig(sig); ! if (interrupt && p->p_siglist) /* user should take signal */ *interrupt = TRUE; mutex_unlock(&p->p_lock); unix_release(); --- 213,224 ---- if (p->p_flag & P_WEXIT) { int sig; ! if (HAVE_SIGNALS(p)) { unix_master(); mutex_lock(&p->p_lock); ! if ((sig = CURSIG(p))) psig(sig); ! if (interrupt && sig) /* user should take signal */ *interrupt = TRUE; mutex_unlock(&p->p_lock); unix_release(); *** ../../../hut/src/lites-1.1.u2/./server/serv/ux_exception.c Thu Mar 23 10:47:00 1995 --- ./server/serv/ux_exception.c Thu Oct 12 06:20:35 1995 *************** *** 25,30 **** --- 25,34 ---- */ /* * HISTORY + * 12-Oct-95 Ian Dall (dall@hfrd.dsto.gov.au) + * Make catch_exception_raise return unsuccessful status if the + * exception is handled by the task (caught signal). + * * 20-Jan-94 Johannes Helander (jvh) at Helsinki University of Technology * Default to signal zero on unknown exceptions and EXC_SOFTWARE codes. * *************** *** 115,121 **** * Send signal. */ if (signal != 0) { ! thread_psignal(task, thread, signal, ux_code); } } else { printf("catch_exception_raise: task %x thread %x\n", --- 119,131 ---- * Send signal. */ if (signal != 0) { ! if (thread_psignal(task, thread, signal, ux_code)) { ! /* The tasks signal thread has been notified and ! * it will unblock the thread which got the exception ! * so we don't want exc_server() reply. ! */ ! ret = MIG_NO_REPLY; ! } } } else { printf("catch_exception_raise: task %x thread %x\n", From lites-readers-owner Sun Oct 15 00:34:48 1995 From: gabor@galactica.it X-Mailer: UUPlus Mail 1.52 To: lites@cs.hut.fi Subject: help Date: Sun, 15 Oct 95 07:20:19 EST Sender: owner-lites-readers@cs Precedence: bulk Reply-To: gabor@galactica.it help From lites-readers-owner Fri Oct 20 10:47:00 1995 id KAA28215; Fri, 20 Oct 1995 10:47:00 -0600 From: Jay Lepreau To: Ian Dall Cc: lites@cs.hut.fi Subject: Re: lites available with signal fixes In-Reply-To: Ian Dall's message of Fri, 13 Oct 95 11:42:14 +0930 Date: Fri, 20 Oct 95 09:17:26 MDT Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Jay Lepreau Where (or who) is the "central repository" for lites now? It would be nice if someone could continue to coordinate various patches and maintain an "official" source. I assume HUT/jtp still runs the "central" repository, but we'll definitely be incorporating your fixes (assume they also work on x86 and PA) into a new "u3" snapshot when its time comes. p.s. turns out they have problems on the PA (might be our bugs, might be yours, probably both). Don't think we've tried them on the PC yet. From lites-readers-owner Sun Oct 22 19:08:42 1995 id TAA04254; Sun, 22 Oct 1995 19:08:42 -0600 Date: Mon, 23 Oct 1995 08:56:12 +0800 From: "Arthur S.L. Hsieh" To: lites@cs.hut.fi Subject: Mailing list archive Sender: owner-lites-readers@cs Precedence: bulk Reply-To: "Arthur S.L. Hsieh" May I know if there is any place that keeps the archive of this mailing list? Thanks Arthur Hsieh slhsieh@cs.cuhk.hk From lites-readers-owner Mon Oct 23 11:15:41 1995 id LAA17115; Mon, 23 Oct 1995 11:15:41 -0600 Date: Mon, 23 Oct 1995 13:03:42 -0400 From: Roland McGrath To: lites@cs.hut.fi Subject: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) X-Nsa-Fodder: AK-47 cracking Marxist Clinton PLO plutonium SDI Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Roland McGrath Hi there. I am not (yet) on the list, so please make sure your replies go to me directly as well. I am running lites-1.1u2 from Utah on an i386 with a stock netbsd-1.0 userland. I am having two problems so far; perhaps someone can offer some advice. 1. ftpd does not work. If I ftp to the machine (or "ftp localhost" on it), I get connected and then immediately dropped. It worked fine under netbsd, and other inetd things (telnet, rsh) work fine under lites. Any clues? 2. nfs is flaky. I have some filesystems nfs-mounted from an hp300 running netbsd-current. They work for a while, but eventually lock up with perpetual "nfs server not responding" messages. I have tried tcp nfs, and it takes much longer to lock up, but still eventually does. Thanks for any clues anyone might have, Roland From lites-readers-owner Mon Oct 23 11:43:05 1995 id LAA17817; Mon, 23 Oct 1995 11:43:05 -0600 Date: Mon, 23 Oct 95 13:25:40 -0400 From: "Stephen D. Smalley" To: Roland McGrath Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) Cc: lites@cs.hut.fi Sender: owner-lites-readers@cs Precedence: bulk Reply-To: "Stephen D. Smalley" >>1. ftpd does not work. We had problems with ftpd on Lites until I commented out the calls to setproctitle() and rebuilt it. >>2. nfs is flaky. We haven't seen this problem, but we only use NFS between i486 or i586 systems running Lites. From lites-readers-owner Mon Oct 23 12:46:46 1995 id MAA19393; Mon, 23 Oct 1995 12:46:46 -0600 Date: Mon, 23 Oct 1995 12:29:45 -0600 From: mike@cs (Mike Hibler) To: lites@cs.hut.fi Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) Cc: roland@gnu.ai.mit.edu, sds@epoch.ncsc.mil Sender: owner-lites-readers@cs Precedence: bulk Reply-To: mike@cs (Mike Hibler) > Date: Mon, 23 Oct 95 13:25:40 -0400 > From: "Stephen D. Smalley" > To: Roland McGrath > Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) > > >>1. ftpd does not work. > > > We had problems with ftpd on Lites until I commented out the > calls to setproctitle() and rebuilt it. > Ugh! setproctitle() seems to be a NetBSD special that tweaks the ps_strings structure at the top of the user stack. Unfortunately, the top of the user stack in native NetBSD (0xFDBFE000) is way beyond what it is in lites (0xC000000?). Someone who understands the x86 should determine whether it is possible to allocate a page out there for the sake of NetBSD compatibility. At least then those NetBSD binaries won't crash (though setproctitle will have no effect on Mach's version of "ps"). From lites-readers-owner Mon Oct 23 12:59:15 1995 id MAA19688; Mon, 23 Oct 1995 12:59:15 -0600 Date: Mon, 23 Oct 1995 14:48:06 -0400 From: Roland McGrath To: mike@cs Cc: lites@cs.hut.fi, sds@epoch.ncsc.mil Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) In-Reply-To: Mike Hibler's message of Mon, 23 October 1995 12:29:45 -0600 <199510231829.MAA04057@venus.cs.utah.edu> X-Nsa-Fodder: jihad Croatian Kennedy Uzi Waco, Texas KGB PLO Peking Mossad Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Roland McGrath Nope, no way. VM_MAX_ADDRESS is 0xc0000000; the higher portions are used by the kernel. From lites-readers-owner Mon Oct 23 14:05:14 1995 id OAA21850; Mon, 23 Oct 1995 14:05:14 -0600 Date: Mon, 23 Oct 1995 21:53:58 +0200 From: Johannes Helander To: Roland McGrath Cc: lites@cs.hut.fi Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) In-Reply-To: <199510231703.NAA02586@churchy.gnu.ai.mit.edu> References: <199510231703.NAA02586@churchy.gnu.ai.mit.edu> Organization: Helsinki University of Technology, CS Lab. Sender: owner-lites-readers@cs Precedence: bulk Reply-To: Johannes Helander > 2. nfs is flaky. It doesn't work with Alphas either. Most likely the situation would improve if somebody would merge the NFS code with NetBSD/FreeBSD current. I merged in bugfixes from NetBSD 0.9 (?) a year ago or so and got it to work with Sun 4s but since then it has gotten out of sync. There are some unfortunate differences that make it impossible to use the NetBSD/FreeBSD codes directly. The most visible difference is the split proc structure in Lites that makes it possible for a single process to do multiple system calls concurrently, thus facilitating multithreaded apps. Johannes From lites-readers-owner Mon Oct 23 14:23:58 1995 id OAA22274; Mon, 23 Oct 1995 14:23:58 -0600 Date: Mon, 23 Oct 1995 14:12:05 -0600 From: mike@cs (Mike Hibler) To: roland@gnu.ai.mit.edu Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) Cc: lites@cs.hut.fi, sds@epoch.ncsc.mil Sender: owner-lites-readers@cs Precedence: bulk Reply-To: mike@cs (Mike Hibler) > Date: Mon, 23 Oct 1995 14:48:06 -0400 > From: Roland McGrath > To: mike@cs > Subject: Re: nfs, ftpd on lites-1.1u2 (i386, netbsd-1.0) > > Nope, no way. VM_MAX_ADDRESS is 0xc0000000; the higher portions are used > by the kernel. > Then there are a couple of other choices. Either: - don't provide compatibility for binaries that use setproctitle and provide replacement binaries for critical applications that use it (e.g., /usr/libexec/ftpd), - "ignore" accesses to the particular ps_strings addresses by tweaking register state (i.e., the PC) in the exception handler. The latter can be a tough thing to pull off correctly depending on the architecture and the OS.