[MiNT] AES features as plugins.

[Evan Langlois <Evan@CoolRunningConcepts.com>]

Atari users are certainly passionate about their machine and their OS.
This is both good and bad.  I think there is a general resistance to
change (I like it - don't F&^% it up!) and yet there is also a longing
for something new.  Its a rough set of circumstances, and I only hope
people can put their hearts aside and try to stick to the pros and cons
of a particular technical solution.

If it seems I'm pushing for a particular solution, I'm not.  If it seems
I'm trying to put down another piece of work or its author, then I have
been horribly misunderstood!  I tend to play devils-advocate, so don't
take things the wrong way!

On Wed, 2005-07-06 at 17:47 -0400, Mark Duckworth wrote:
> Mikro is working on this.  It was supposed to be done in a couple weeks
> but it's been a long time since we've heard from him.  Last I heard he

Yes, I've been sitting silently hoping we'd see something appear.  He
has a lot more experience with that issue than I, and I'd certainly want
any new code that has to do things like mess with large amounts of image
memory to work properly when that project completes.  I believe this can
open up some really big possibilities for us.  The same for plugin APIs.
The user shouldn't have to change program flags and modify memory
protection due to some ad-hoc designs suddenly breaking in the future.

If there is going to be a plugin API, the kernel should manage plugins,
so it can manage the memory sharing and reference counts so the library
can be safely unloaded even if a program crashes before closing the
library.  Doing this in user-space seems wrong to me.  Likewise their
should be some standard method of getting plugin versions, listing the
functions that are implemented, and things like that.

Anyone want to talk about a kernel plugin API that would be handled
totally by the kernel without any possibility of memory corruption?  Let
me throw something out there off the top of my head.  How about an XFS
driver that lists plugin categories as directories, inside each category
is a list of directories for each available plugin, and inside there is
a list of functions as files.  Categories might be image loaders, AES
themes, or other bits as we see necessary, which would likely have a
"real" directory on disk for the XFS to get the info.  Opening the file
could return a pointer to that function, mapped to the process's address
space, much like the way /SHM works.  The OS would take care of loading
plugins when needed and handling dependant plugins, and unloading them
when no application references the functions in it.  Comments?  Did
anyone finish the loopback device driver they were working on?  There
would be similarities in the implementation.

You could even extend this to put shared data in the system as well as
code, much like the /SHM driver or perhaps just extending the /SHM
driver we already have, providing a global namespace for working with
shared data and code alike. 

Now, for true shared libraries, you wouldn't want to mess with manually
opening libraries and things on a function by function basis, nor would
you want to call through an indirect pointer every time you made a call
to the shared library, however, it would be possible for the program
loader to map function calls in a newly loaded program to the values
give by the plugin API.  This would give many of the features of ELF,
and I don't believe we'd have to change the binary format much, if any
at all.

Of course, for such a plugin API, a generic in-kernel API for mapping a
particular processes address to a real/kernel address would be needed,
as well as a way of mapping particular blocks into specific processes.
This can even be done before virtual address spaces have been
implemented, as the mappings would just be 1:1, but once virtual
addressing and full MMU usage is done, the different systems that
dependend on memory mapping would already be set up.

Something similar exposing the PCI bus (if there is one) would be nice
too if not already done.

> was having problems with ARAnyM MMU.  Evan's ideas are at the Mercy of
> others.  I think my idea with GIM was right for the atari platform.  Get

Its not that I expect everyone else to do the work.  I do expect
everyone to agree on, or at least consider, the direction that things
are going in.  I see so many incompatible APIs, fixes, and different AES
and VDI systems, and they all are a bit different, and none of them
really have very modern features.  This just makes things more and more
difficult for the programmer.  

There are lots of little protocols and sub-projects done in user-space
like AV_PROTOCOL, OGLA, STRINGSERVER, and some attempts at library
sharing/plugins, but just finding information on these can be difficult
and their isn't always documentation available, nor is it clear which of
these are deprecated and might have memory protection issues.  These
sorts of things may not be a part of the kernel, but they are evidently
part of the operating system.  Some of the things I'm working on will
likely need to interface with some of these, but I've yet to really get
a good feel for all of them.

Unfortunately, I don't have the time to devote to MiNT/Atari things
directly at the moment.  What little free time I have is divided between
other projects (some of which I'm going to give up on as I want to
reimplement the whole thing using my EDDON project).  EDDON will likely
see the light-of-day on the Atari platform before the Linux platform
simply because the user interface is simpler to program for and I'm
interested in the performance on older / slower / memory-constrained /
embedded systems.  For now, my only purpose is to try to remind people
that programming shortcuts only lead to dependance on those shortcuts.
We may not want to set a kludge in stone only to may a new version in 6
months.  There are plenty of bloated systems that have been pieced
together, and I'd rather find a single solution that can address needs
far into the future instead of 12 solutions.

At the moment, I'm simply not willing to even look at coding for MiNT
until some basic things are fixed - such as being able to compile MiNT
with a GCC thats not 5 years old (the assembler format is still wrong),
and having the Aranym networking actually work, etc.

> something done with great ideas, and fix it up more properly once you
> have something working.  If we started taking the zview path and figured
> out the compositing was necessary for png or something then we should
> change to using some GPL lib, but for now, it's a quick and easy drop in
> feature.

My only problem with zView is that we're talking about making a standard
AES feature that requires a plug-in format that is implemented in
userspace without any help or direction from the kernel.  It seems like
a kludge to me, and it scares me from a stability stand-point.  A plugin
system, however, would be fine for me we can add functions later for the
features *I'd* like to see, but again, only if the OS were supporting
such a thing.

Like I said, my Linux desktop uses a transparent PNG image that provides
the texture for the chosen desktop color.  Icons are anti-aliased over
that using image compositing.  Same with the fonts - anti-aliased
proportial fonts.  I don't think this is really hard-core technology
either - its not the end of what people might want to do with a desktop.
It is however an example of what you can't currently do very easily with
an Atari operating system.

> But for right now, the path of least resistance is the path we should
> take.  We are underpowered and undermanned, even if it's only 90% a good
> idea instead of 100% the best (full GPL libs).

I'm more worried about everyone doing something different and ending up
with redundant solutions or inefficient solutions (like the fork that
copies data on task switch because no one bothered to consult with
everyone else first) and wasting what little time we have left.

Now someone will yell at me for the really long post - sorry.