Re: Domain X

[Juergen Lock <nox@jelal.north.de>]

just a few comments...

Evan K. Langlois writes:

> This is part summary, part reply.  I can't implement it because, well, 
> there are a number of problems.  1 - my compiler is broke for now. 2 -
> the cookiejar calls are required, and I haven't finished those because
> my compiler is broke (hey! what's a good gemdos opcode for a Cookiejar
> call?  I may also need 2 or 3 more opcodes for reading the system tick
> without being in super-visor mode and manipulating the shell pointer as
> I've always like the idea of having 1 shell for all programs to use
> and being able to execute command lines through the shell using _shell_p)

 _shell_p is obsolete.  IMHO.  unless you want to write a shell that
does everything itself again what is and should be the OS' job...
and anyway isn't a shell compiled with -mbaserel enough? :)

> Implementation can begin in the path2cookie() function.  The recent change
> to return EPTHNF instead of EFILNF could be removed for Domain X apps.
> Just test the domain before returning a value I guess.  Where else there
> may be conflicts between domains is over my head.

 don't forget the write permission stuff... :/

>  Or do you have an idea to make fork() work with a pure 68000 system?
> ========================================================================
> 
> Actually, I do have a few ideas.  Since tfork() works, then Pvfork() could
> be hacked up to be non-blocking.

 yes that would be useful.

> Unblocking Pfork() seems to be a problem of pointers.  A pointer in the parent
> when copied to the child will access the paren't memory, not the child's
> memory.  I think that if the code is base-relative, then you can adjust the 
> base register of the child to take care of 90% of the programs data access.
> The rest is what to do with pointers that are "computed", or returned from
> a malloc.  One idea is to use the memory "handle" system that DMJ is working
> on (although he isn't going to do it for MiNT, he doing it for TOS/Geneva).
> Basically, a new call allows you to allocate a block of memory, but instead of
> a pointer to the block, you get a "handle".  To access the block, you must
> "lock" it in place - this call returns a pointer.  When you are done, you 
> release the lock, and your pointer becomes invalid, as the manager can now
> move the block, defragment memory, or swap it to disk.  Your "handle" is now
> the only way to access the block .. again re-locking it and getting a new
> pointer.  Such a system could help in managing pointers when forking a child.

 well.  that would still need major hacking on just about every fork()ing
unix source...  so i think you can forget it. :(

> It would also be useful in a shared memory file, since you can put handles
> in the shared block, but not pointers.  It STILL may not be possible to
> reliably use Pfork() on a 68000.

 if you ask me, the only reliable way to fork (not vfork) without virtual
memory is like minix did it, move around data+bss on every taskswitch.

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA