Re: [MiNT] AES features as plugins.

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

Hello

Look my answer at the end!

> 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.
>
...

For zview plugin made with ldg, in fact you are not in userspace (totaly share
with no memory protection), ldg manage memory protection, and only software
using it have acces to it, it's manage with SHM. I know it because I write it!
So in fact ldg library if need and if coders have think about this of course,
are more protect than the AES itself that can be access for all in supervisor
mode! (perhaps not for XAAES I don't know).
MyAeS use for it work a lot of dynamical library (4 or 5), and next version
should be highly extensive, with plugin, because it will be possible to patch
AES itself by plugins! So wait for next version! (probably near october). This
is condition to put most of MyAeS code in public domain, because I have to clean
code and explain it, I have take 2 years to code and correct bug without really
looking how it was code, now I should clean it!


Olivier