cleary@husc9.harvard.edu (Kenneth Cleary) (10/04/90)
Before I start asking a whole bunch of questions, I would like to ask if someone has an FAQ article for this group that they could mail or post. I'm interested in compiling and installing University INGRES on a VMS system, to allow students to experiment with it for a course in DBM systems. I'm trying to find out if someone has done a non-commercial port from the source code, which is aimed at UNIX, to code which will run on VMS. Failing this, I will take a crack at doing a port myself. It would also be nice to try to get POSTGRES running, but the mention of kernel modification to achieve dynamic loading tells me a port should not be considered lightly. As long as I'm on this topic, could someone familiar with dynamic loading give a thumbnail sketch for someone who is a novice? VMS has extensive system service routines, and various run-time libraries that go beyond that available for most UNIX machines, so I may be able to come up with an emulation of this thing. I'm a novice at some of this, but if some of this sounds naive, feel free to flame away, or comment on any aspect, so that I might correct any of my misunderstandings. *DONNING FLAME-PROOF SUIT* Ken Cleary.
mao@eden.Berkeley.EDU (Mike Olson) (10/04/90)
In <4333@husc6.harvard.edu>, cleary@husc9.harvard.edu (Kenneth Cleary) writes: > It would also be nice to try to get POSTGRES running, but the mention of > kernel modification to achieve dynamic loading tells me a port should not > be considered lightly. the kernel reconfiguration we force on you is required to support inter-process communication, not dynamic loading. we rely on shared memory and semaphores a la unix system v, and we rely on lots of both. (there is a mutiny afoot here right now that aims to come up with a standalone, single-user version of the code that doesn't use any shared memory or semaphores. this'll be of only limited usefulness, but it will open up the playing field a little bit). i am unfamiliar with vms, but my guess is that it doesn't support the abstractions we require. given that, a port to vms is likely to be very hard. > As long as I'm on this topic, could someone familiar > with dynamic loading give a thumbnail sketch for someone who is a novice? > VMS has extensive system service routines, and various run-time libraries > that go beyond that available for most UNIX machines, so I may be able to > come up with an emulation of this thing. basically, you need to allocate some memory, copy an object file into it, interpret the symbol table it contains, resolve links from it into the symbol table in the executing program, figure out the start address, and jsr (or whatever your local asm mnemonic is) to it. there are two ways to do this. one is to let the people who sold you the operating system do the work. on unix, this means using something called faslink, where you invode the loader from inside your program on the file you want to link in. the loader staples the two together, and you're more or less done. the other option is to do all the work yourself, by hand, as described above. until now, the postgres dynamic loader was homebrew, and so porting it to new systems was very hard. with the bug fix release coming up in mid-oct, we'll probably be shipping some user-contributed code (for some platforms, anyway) that uses faslink and ld -A, and takes the pain out of dynamic loading. oh, yeah, for the record, university ingres is no longer supported by our group. all the people who know how it works got their phd's already. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu