lance@motcsd.csd.mot.com (lance.norskog) (03/22/91)
(I posted this from Portal before, but it hasn't made it here. I assume it disappeared.) The Mach 3.0 release kit from CMU appears to have almost everything you need to cross-compile a micro-kernel from 386 UNIX, and test your own raw Mach programs. Except: what's the Boot File System? Is it the BSD 4.2 Fast File System format? If so, can you just download 'mkfs' from the BSD freed sources, build a boot floppy disk from UNIX/386 using the 'proto' option, and then reboot Mach from that floppy? If not, what else is missing? I don't mean UNIX. I don't want UNIX, I just want to write raw Mach. Thanks, Lance
jds@cs.umd.edu (James da Silva) (03/23/91)
In article <3444@engadm3.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: >The Mach 3.0 release kit from CMU appears to have almost everything >you need to cross-compile a micro-kernel from 386 UNIX, and >test your own raw Mach programs. Except: what's the Boot File >System? Is it the BSD 4.2 Fast File System format? If so, can you >just download 'mkfs' from the BSD freed sources, build a boot floppy >disk from UNIX/386 using the 'proto' option, and then reboot Mach >from that floppy? > >If not, what else is missing? I don't mean UNIX. I don't want UNIX, >I just want to write raw Mach. The /boot program (and the initial boot sector, too) are not supplied with the FTPable distribution. The Mach kernel expects to be loaded at 1 Meg, with protected mode on, paging off. Also, Mach is normally built at CMU with their own version of Make. Their compiler also understands the environment variables CPATH and LPATH as search paths for include files and libraries, respectively. The Makefiles take advantage of these features, so you can't build Mach with a normal make and cc. As has been remarked here, Gnu Make has equivalent (but different syntax) functionality, so the Mach sources could be converted to it. Has anyone done this successfully, and if so, are you willing to post your diffs? It would save a fair amount of duplicated busy work by others. Jaime ........................................................................... : domain: jds@cs.umd.edu James da Silva : path: uunet!mimsy!jds Systems Design & Analysis Group
thinman@cup.portal.com (Lance C Norskog) (03/23/91)
James da Silva writes (in response to my questions): > > The /boot program (and the initial boot sector, too) are not supplied with > the FTPable distribution. The Mach kernel expects to be loaded at 1 Meg, > with protected mode on, paging off. The current DDJ has a series of articles on this; the source came from the BSD386 project. It's available on Compuserve via "GO DDJ". (I'm quoting from memory here.) I loaned my tapes out, so I can't verify it, but I could swear I saw some boot loader code in there, in the MK42 source distribution. Also, someone recently posted a nice boot loader in comp.sources.unix. > Also, Mach is normally built at CMU with their own version of Make. Their > compiler also understands the environment variables CPATH and LPATH as > search paths for include files and libraries, respectively. The Makefiles > take advantage of these features, so you can't build Mach with a normal > make and cc. > > As has been remarked here, Gnu Make has equivalent (but different syntax) > functionality, so the Mach sources could be converted to it. Has anyone > done this successfully, and if so, are you willing to post your diffs? It > would save a fair amount of duplicated busy work by others. Just use a shell script for CC that hunts for CPATH and LPATH as environment variables; this and some mild editing should do the trick. Lance, posting from my other account
steve@robobar.co.uk (Steve Bleazard) (03/26/91)
jds@cs.umd.edu (James da Silva) writes: > Has anyone > done this successfully, and if so, are you willing to post your diffs? It > would save a fair amount of duplicated busy work by others. > Here are the Modifications required to conf/Makefile.template to make it work with GNU make 3.59. GNU make 3.59 is required for the NOEXPORT hack to work, and NOEXPORT is required on some systems as the arglist + enviroment can exceed the xxK arbitrary limit. ------------------------------ Cut Here ------------------------------ *************** *** 453,459 **** MIGKUFLAGS = $(MIGFLAGS) -DKERNEL_USER MIGDEPS = ../bin/mig ../lib/migcom ! MIG = PATH=../bin:$$PATH LPATH=../lib:$$LPATH mig MACHDIR = mach/ --- 453,459 ---- MIGKUFLAGS = $(MIGFLAGS) -DKERNEL_USER MIGDEPS = ../bin/mig ../lib/migcom ! MIG = PATH=../bin:../lib:$$PATH mig -I. -I.. MACHDIR = mach/ *************** *** 463,469 **** memory_object_data_provided memory_object_data_unavailable \ memory_object_data_error memory_object_set_attributes ! MACH_FFILES = $(MACH_FUNCS/$(REG_EXP)/$(MACHDIR)&.c) MACH_FILES = mach/mach_interface.h mach/mach_user_internal.h \ mach/mach_server.c $(MACH_FFILES) --- 463,469 ---- memory_object_data_provided memory_object_data_unavailable \ memory_object_data_error memory_object_set_attributes ! MACH_FFILES = $(patsubst %,%.c,$(MACH_FUNCS)) MACH_FILES = mach/mach_interface.h mach/mach_user_internal.h \ mach/mach_server.c $(MACH_FFILES) *************** *** 475,481 **** MACH_PORT_FUNCS = mach_port_allocate mach_port_destroy \ mach_port_insert_right mach_port_move_member ! MACH_PORT_FFILES = $(MACH_PORT_FUNCS/$(REG_EXP)/$(MACHDIR)&.c) MACH_PORT_FILES = mach/mach_port_interface.h mach/mach_port_internal.h \ mach/mach_port_server.c $(MACH_PORT_FFILES) --- 475,481 ---- MACH_PORT_FUNCS = mach_port_allocate mach_port_destroy \ mach_port_insert_right mach_port_move_member ! MACH_PORT_FFILES = $(patsubst %,%.c,$(MACH_PORT_FUNCS)) MACH_PORT_FILES = mach/mach_port_interface.h mach/mach_port_internal.h \ mach/mach_port_server.c $(MACH_PORT_FFILES) *************** *** 547,555 **** -$(MAKE_MACH) $(MIG) -MD $(MIGFLAGS) -header /dev/null -user /dev/null -server mach/default_pager_object_server.c $(SOURCE_DIR)/mach/default_pager_object.defs ! LIBMIG_OBJS = $(MACH_FUNCS/$(REG_EXP)/&.o) $(MACH_PORT_FUNCS/$(REG_EXP)/&.o) ! $(LIBMIG_OBJS): mach/$$(@:r).c $(KCC) -c $(CFLAGS) mach/$*.c libmig.a: $(LIBMIG_OBJS) --- 547,556 ---- -$(MAKE_MACH) $(MIG) -MD $(MIGFLAGS) -header /dev/null -user /dev/null -server mach/default_pager_object_server.c $(SOURCE_DIR)/mach/default_pager_object.defs ! LIBMIG_OBJS = $(patsubst %,%.o,$(MACH_FUNCS)) \ ! $(patsubst %,%.o,$(MACH_PORT_FUNCS)) ! $(LIBMIG_OBJS): %.o: mach/%.c $(KCC) -c $(CFLAGS) mach/$*.c libmig.a: $(LIBMIG_OBJS) *************** *** 634,637 **** %RULES ! -include Makedep --- 635,642 ---- %RULES ! #include Makedep ! ! .NOEXPORT: ! ! # ------------------------------ Cut Here ------------------------------ -- Steve.Bleazard@RoboBar.Co.Uk | Phone: +44 81 991 1142 x153 Snr Software Engineer, Robobar Ltd. | Fax: +44 81 998 8343 (G3) 22 Wadsworth Road, Perivale. | Middx., UB6 7JD ENGLAND. | ...!ukc!robobar!steve
jds@cs.umd.edu (James da Silva) (04/06/91)
steve@robobar.co.uk (Steve Bleazard) writes: >jds@cs.umd.edu (James da Silva) writes: >> Has anyone done this successfully, and if so, are you willing to post >> your diffs? It would save a fair amount of duplicated busy work by others. > >Here are the Modifications required to conf/Makefile.template to make >it work with GNU make 3.59. GNU make 3.59 is required for the NOEXPORT hack to >work, and NOEXPORT is required on some systems as the arglist + enviroment >can exceed the xxK arbitrary limit. [Sorry for the delayed reply; I went out of town] Thanks for posting your patches, Steve. Actually, I already got that far by the time I received your stuff. I've found that it takes a lot more than just modifying the Makefiles to get the MK to build outside of the Mach development environment. My goal is to provide a patch kit that will allow the PMAX version of the FTPable MK to compile under Ultrix using Gnu Make. So far I've had to modify several makefiles, write a few shell scripts, and reverse-engineer one CMU library routine (fopenp(), needed by config). I'll make my changes available when I get it working. I'm interested in hearing from anyone else working on something similar. Jaime ........................................................................... : domain: jds@cs.umd.edu James da Silva : path: uunet!mimsy!jds Systems Design & Analysis Group