🚀 go-pugleaf

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 <DEVEN.89Mar9113018@daniel.pawl.rpi.edu> 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.