So many cookies

[ekl@sdf.lonestar.org (Evan K. Langlois)]

Is anyone working on the system cookie jar function/s that were mentioned?
If not, then I recently came up with something I may test out (no reason
to hack it into the kernel to test it actually).  What is a good gemdos #
to use for a cookie function?

Also, it occured to me that only root should be able to make or delete a
system cookie (I know, kinda pointless if they can use Super() and do it
anyway).  I've really got cookies on my mind since I was playing with file
cookies when the system cookie jar functions were mentioned.   I've got
2 days off so I'm gonna hack a little.
 
How about making Super() and Supexec() a root-only <<would this be euid==0?>>
function once the system cookie calls are in place.  Or, better yet, here's
a new idea .....

how about a new domain where Super() and Supexec() are root-only, Fsfirst()
and Fsnext() are not available (should use dopendir, etc), Dgetdrv and Dsetdrv
are not available (everything should be accessed from U:), Dgetpath is
unavailble (should use Dgetcwd()) and the BIOS and XBIOS calls are not
available (should use /dev/ filesystem).  Otherwise, the domain acts like
MiNT domain only you can't change back to normal TOS or standard MiNT domain
(which completes the security).  This would allow us to have a "Unix" domain
where a remote shell would be started in this new Domain and you get a secure
system after that (gotta figure out what to do about GEM, make AES and VDI
root-only for this domain).  I think this would be the best situation.
TOS for backward compatibility, MiNT domain to use the flexibility of the
new calls, and a third domain that is more Unix-like that removes some of the
TOS calls and improves protection.  You can have all three domains running
at once, but the system is safe if remote users are started in the new domain.

It's an idea, anyway.   Here's 2 more ideas.  If it were possible to specify
a file size during Fcreate, then file systems could use this information
to allocate space on the hard drives more efficiently, and ramfs could allocate
memory more efficiently.  I stole this idea from OS/2, and it makes sense.
It would make a good optional parameter or a new call perhaps.
 
Last idea - memory mapped files (this idea stolen from NeXT/Mach).  In VM
systems, you have to save a page to disk if an application puts data in it.
if you had a memory mapped file, you don't save a page to disk if that page
belongs to the memory mapped file - the page isn't marked as being written
to when the OS reads the file data onto the block.  That way, your swap file
is kept small and you save alot of write operations.  To swap the page back in
you just read from the original file.  You have to use lots of MMu tricks for
this, but ideally, you open the file and get a pointer, not a handle.  The
pointer accesses the file as if you called Malloc and Fread and read everything
in from disk but the Os handles how much to read in.  If you write into the
block, then the page is marked as written and if it gets swapped, then it is
written into its file, NOT the swap file.  When the file is closed it's like
doing an Fwrite and an Mfree too, all changes are flushed to the file.
 
You get a nicer interface to the process of reading and writing files and the
OS decides how many pages it should keep in memory if the file size is greater
than system RAM.  If another application needs memory, then the memory mapped
file's pages can be given to another application without saving them (assuming
the app hasn't written to the memory, only the OS has).  All can be done with
the MMU.  Think of fonts, GIFs, programs like LESS and VI that use parts of
large files.  Even program code can be better managed through a memory mapped
file than the standard swap file because its already on disk .. why write it
twice?

Anyone like these ideas, or should I just go away :-)  Everyone else posts
code not ideas, so I feel like I'm justing wasting bandwidth with talk.
Anyway, email me.  

CYA
Evan Langlois
ekl@sdf.lonestar.org