Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 9 Mar 89 16:30:18 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu Distribution: comp Organization: RPI Public Access Workstation Lab, Troy NY Lines: 147 In-reply-to: jesup@cbmvax.UUCP's message of 9 Mar 89 03:26:54 GMT In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >Distribution: comp ? >In article shadow@pawl.rpi.edu writes: >>In article <6157@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>>In article shadow@pawl.rpi.edu writes: > I'd advise using an extended CLI structure if you want any sort >of compatibility. This may break in 1.4, but it will at least work (please >note in your docs that this may well break in 1.4 in that case). That's one possibility, but I'd like to avoid using the CLI structures, as they use noxious things like BPTRs and BSTRs... I look at it as having two ways to run programs - in a CLI environment, and in this Unix-like environment. New programs could be written to run under the Unix-type environment, and CLI-type programs could be run as a CLI process. A big problem with CLI processes is that they are (quite arbitrarily) limited to 20. That is too few; I want to implement concurrent pipes and simple backgrounding, and I don't want to have them all as CLI processes. Of course, the only real way to break from the BCPL crap is to rewrite the file system, or at least the interface to it. I wouldn't mind doing so, and have considered it a number of times, but don't have the time to do so just yet. Maybe in a couple months. Say I were to replace the interface to the file system? (and rewrite it later sometime. :-) ) Have open(), close(), read(), write(), lseek(), pipe(), etc. and have most of them call AmigaDOS routines and store things in internal tables... If I do that, I could have a single DOS Process to coordinate things and call the AmigaDOS routines, and have the read(), etc. routines send messages to that process. Then I could replace the process structure altogether... but have provisions to create a new CLI environment to run programs which need it... (or take the cheap way out and use Execute()...) Another possibility would be to patch the OpenLibrary call (seems preferable to patching ALL the DOS library calls) to catch any OpenLibrary("dos.library",v) calls and check if it was one of the non-DOS processes I created, and if so, have it open a compatibility library instead... Speaking of Execute(), I have a gripe with it. V1.3 Execute() does NOT use run if it is in the DOS Resident list, but still insists to run c:run... which is a BIG pain if the system disk isn't in the drive. (assigning c: to ram:c or rad:c isn't much help; then you can't be asked for the system disk back to run programs in sys:c which aren't resident...) Say, if I replaced that Command Dir lock that's in the CLI structure for that one CLI process, would it look there without having to assign c: elsewhere? >>So, is there any legitimate way to identify the binaries as "I don't >>need a CLI environment"? Essentially, is there a way to tag the >>binaries with a "magic number"? Such that it won't interfere with >>LoadSeg() or the code itself? Can you set a hunk name on the >>hunk_header hunk? >> >>(The answer looks like it should be "yes", but I don't have any blink >>docs onhand; only this AmigaDOS manual.) > > No. Argh. > I advise against modifying binaries. Use one of the user >protection bits. Not such a good system. user protection bits are all too easily lost. I'd much rather have the binary identifiable. The idea I had to identify it which seems most workable is to have a special startup module which begins with a branch past a magic number (longword) which the shell's loader could check against. Sound reasonable? >>> Tannenbaum has two students doing a port. Tanenbaum, actually. (glanced at his OpSys design book's cover.) >>Nice to hear. I wouldn't relish the task. At least, replacing the >>REAL low-level stuff, like Exec and the device handlers, I really >>don't feel like messing with. Rewriting the file system is as >>low-level as I want to get at this point, on such a scale. (And >>that's no small project either.) > > That's why I suggested a long time ago that Amiga-Minix be implemented >on top of Exec/Graphics/Intuition/etc. This also means you get your >expansion hardware to work without having to hack the kernal for your >specific configuration, and plead for driver source from the HD makers. Yes, when I looked into it, I decided that it would be better implemented on top of Exec and such. However, there are some low-level changes that would be valuable, like sending a signal to a process when it goofs up, instead of GURUing and bringing down the entire system... But Exec is better designed in some ways than Unix. Most notably, it is far more dynamic, with everything in linked lists instead of static arrays. Then there's AmigaDOS, with its 20 CLI limit... *sigh* >>> VERY hard to do without an MMU, since you MUST duplicate the stack >>>and data, and those contain absolute pointers. There is no way to know >>>where these pointers are. The ST/Amiga-Minix gets around this by copying >>>the data/stack of the two processes to save areas, and "swapping" in the >>>data/stack to the original position whenever one needs to run. Luckily, >>>almost all fork() calls are followed almost immediately by exec(), so the >>>overhead isn't too horrible. >> >>Oh, icky. My, I had overlooked that aspect. *sigh* It's a kludge, >>but I guess it'll work. Can the tc_Switch and tc_Launch fields in the >>task structure be used to handle this? Or are they already used or >>not usable as such? > > yes, but respect any values already there (grab the old value, stuff >yours, and after you're called call the old value). An example of stuff >that might use this would be saving '881 registers. That's fine by me. (expected to do so anyhow.) What state do those functions run in? Supervisor or User mode? Can they be interrupted by the timer clock, and end up with Exec trying to switch out when it already was? Or, will they not be interrupted? (i.e. if those functions took 10 seconds to execute, would it break anything other than system performance?) How about using the tc_UserData field to point to an extended structure? Is it used for anything? Or maybe using the name filed in the task's node structure as an extended structure pointer? Or are both these out, too? >>> there is no way to dup a filehandle. >> >>It would be duping handles to a table entry holding the file handle. >>(along with the count.) > > Fine, but watch out: if two BCPL programs try to use the same >filehandle, fireworks will erupt. No way to dup a filehandle? Why couldn't two programs use the same filehandle? Can two non-BCPL programs share a file handle? It is lack of mutual exclusion or something else? -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.