Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!sun.soe.clarkson.edu!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:32:12 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> Sender: usenet@rpi.edu Distribution: comp Organization: RPI Public Access Workstation Lab, Troy NY Lines: 183 In-reply-to: jesup@cbmvax.UUCP's message of 13 Mar 89 18:49:20 GMT In article <6237@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>>Distribution: comp >>? > That's what Pnews gave me as a default. Interesting. I wonder what difference it makes? >>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. It ought to. Even though I think the whole structure of the CLI sucks to begin with. :-) >>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). Who said it was easy? I meant I may decide to start working on a file system in several months, not that I'll finish one in several months. (Though I just might, you never know...) :-) >>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...) > Known. Well, do you think maybe someone could write a patch for it and post it to the net? It's a real annoying bug, (well, I consider it a bug, or at the very least, a defect.) and something that really shouldn't be so difficult to fix... >>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? > You believed the name of the field, didn't you? Poor naive boy. :-) >It's really the BPTR to the path list. Figures. What form is this path list in? BCPL array of BSTRs? BCPL array of locks? Something else? >>> 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. Hmm. I'll take a look at 'em. >>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.... Now, who said Alert() would return? Remove the task and maybe dump a "core" file (gee) and release what it can, reasonably. >[tc_Launch & tc_Switch] >>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?) > I suspect in supervisor, non-interruptable (by the switcher, interrupts >will still occur, I suspect). Taking 10 seconds would be very, very bad in >a real-time OS. Even VMS doesn't take 10 seconds to switch! :-) For more >data, ask bryce@cbmvax (I haven't played with it). Ok, good. That's what I figured it would be; just wanted to check. I'm not intending to take 10 seconds to switch in and out; just wanted to give an extreme example... ("Can you say, 'serious system performance degradation,' boys and girls?") >>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. I've thought about it, and I think the best system is to use a setup similar to how a DOS Process is set up, with a structure starting with a task structure. Such processes (damn, need a new term, maybe...) would NOT run as DOS Processes, and as such could not use dos.library calls, but replacements would be provided which would communicate (using message passing, internal to the functions) with the "system" task which WOULD be a DOS Process, and would coordinate calls to AmigaDOS, and my file system, should I ever get around to writing it... In other words, there would be a program which would be run (from the CLI or Workbench) which would initialize the Unix-type system, install the run-time library as permanently ram-resident, You can do this easily, can you not? I mean, without dealing with LIBS: and disk-based libraries and all that? I want the library to be part of the data (and/or code) of this executable program, and have it use that to install it as a permanently ram-resident Exec Library, without any such library in LIBS:... I haven't looked closely at the Library routines, but as I recall, it seemed doable enough. This program would split apart using CreateProc to create a system task which would handle coordination of the programs run in this environment with the memory management routines (probably just calling Exec routines) and the file system, both AmigaDOS and later, should I write it, my own file system as well. It would set up a public message port which would be used for the internal communication for the functions, and also for control information, such as for running that initializing program again with instructions to shut down (Unix-type half of) the system. (de-installing the library, aborting the running tasks, etc.) The original program would return to caller after completing initialization and starting the separate system process, so as to avoid any hassles with having to RUN the program, etc. This seems the cleanest, most efficient and all-around most workable setup to me. What do you think? (i.e. now tell me why I'm dead wrong about this. :-) One more thing. I need a name. "Unix" is clearly out. "Amix" I rather like and would use, but now it's taken, too. "Minix" I don't especially like and would give the wrong impression, as this would not be a Minix port. A housemate suggested "Minisculix", which is sorta amusing, but this is looking to be more than a miniscule project. So, I'm pretty much at a loss for what to call it. It would probably be nice to have it end in "ix", just for consistency. (everyone ELSE does it!!) :-) So... have you (or anyone) ANY suggestions what this could be called? It will (hopefully) be functionally similar to Unix V7 (Don't want to deal with _most_ of BSD/SysV extensions, though maybe some of them, sooner or later.) It may eventually be able to run stand-alone without AmigaDOS, but it will be able to run alongside AmigaDOS from the beginning. (Unlike C-A's Amix...) So? What to name it? >>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? > Two non-BCPL programs can right now. BCPL programs use the buffering >fields in the file-handle, and would clash over them. Ok, that's what I thought. Not that I really intend to share the file handles directly anyhow... Deven p.s. I saw your old address in shell.doc on that shell 1.03 beta disk... 2340 15th Street??? I live at 2346!! Hey, we're neighbors! (of a sort...) :-) -- ------- 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.