Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!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: 15 Mar 89 19:49:31 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> <1292@dukeac.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Distribution: comp Organization: RPI Public Access Workstation Lab, Troy NY Lines: 112 In-reply-to: rsb@dukeac.UUCP's message of 14 Mar 89 23:57:33 GMT Grr. Forgot to set the Reply-To field on that last posting. *sigh* Gotta automate that one of these days. In article <1292@dukeac.UUCP> rsb@dukeac.UUCP (R. Scott Bartlett) writes: >In article <6237@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>In article shadow@pawl.rpi.edu writes: >>>In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>>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. >> Agreed, it is too few. This may change. >What about setting the CLI proc number to 0? Will some cli things choke on >this? Lattice's forkv() uses proc number 0. (What do workbench programs do?) I considered seting the CLI proc number to 0 and still using the CLI pointer for an extended data structure, but deided against it. Also decided against using the Process structure... >>>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. >> >> (suppressed giggle) it ain't as easy as it looks. Just ask Steve >>Beats (Mr FFS). >Let me know how you want to eliminate the BCPL stuff. I plan on >writing a ROOT: to allow other filesystems to be mounted onto it. It >would be a great place to eliminate some BCPL garbage (or at least >hide it from those that are in the know). I intend to eliminate it from the programmer's end by providing read(), write(), etc. functions which will communicate with a DOS Process which will convert for BCPL crap and make the AmigaDOS calls. Later, if I write my own file system, I simply won't USE and BCPL for it, and the same interface will be available, unchanged. [stuff about stuff deleted deleted] :-) >>>> 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? >> I've seen it done. Check the arp programmers docs. >Please use the magic number. I think using the file protection bits >is a BIG kludge. If we go ahead and implement magic numbers, programs >that depend on the MMU for different memory setups, etc. can be >identified and dealt with accordingly. For instance programs that are >very time sensitive can be labled with a noswap attribute (are you >happy Peter? :-). And things that depend on having an 881 around can >be identified at load time and the user can be informed about the >problem instead of having the machine go through an F-line trap or >whatever. (this can go on to include 020's and 030's...040's 050's :-) I'm not worried about MMU's for now, but I intend to use the magic number; it's less likely to be lost inadvertantly. >>>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... >> You can trap Alert(). Of course, code that dead-ends may not >>deal well with Alert() returning.... >>[tc_Launch & tc_Switch] >back to the question about having fork() and exec() included as a >linked library or as a runtime library. Well, to put my two cents in, >i think that it should be a runtime library so that your code can >depend on it being there (sorta...) and so that your task does not >have to include all of his extra code. I like the idea of an init >proc. You could send a message to init's port (internal to fork) and >wait for a reply. Init would copy the proc and send a message to the >parent and to the child with the respective returns for each. If i'm >not mistaken there is a field in the Task structure that contains the >pc. Init could use this to set the child up executing at the same >place (offsets would of course have to be calculated). I think I'll go with the runtime library because it will save a LOT of code in other executables and it will greatly simplify writing exec() (and remove some otherwise necessary kludges.) >>>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? >> >> Applications are allowed to use it. The ln_Name points to a real >>task name. >According to John Toebes, he uses tc_UserData for something in lc.lib. >If I remember correctly, he uses it for forkv() and forkl(). I asked >him about it because i was going to use it to store env variables. Oh >well... Hmm. Try something else. I guess. :-) Deven -- ------- 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.