From mint-bounce@lists.fishpool.fi Thu Jul 7 02:05:25 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: [MiNT] AES features as plugins. From: Evan Langlois To: mint@fishpool.com In-Reply-To: <1120686464.8850.59.camel@mduckworth.phillypark.net> References: <42BB46F0.4090206@chello.nl> <1119599743.15790.284.camel@linuxbox> <1119718803.15790.339.camel@linuxbox> <1119779027.15790.442.camel@linuxbox> <1120071508.19330.55.camel@linuxbox> <1120086064.11804.57.camel@taro.coolrunningconcepts.com> <42CAA2C3.9040607@seznam.cz> <1120582072.5673.62.camel@linuxbox> <1120597879.22922.15.camel@mduckworth.phillypark.net> <1120622491.11436.43.camel@taro.coolrunningconcepts.com> <42CC0E1B.7030407@yahoo.fr> <1120673185.11436.63.camel@taro.coolrunningconcepts.com> <42CC4E05.8020509@yahoo.fr> <1120686464.8850.59.camel@mduckworth.phillypark.net> Content-Type: text/plain Date: Wed, 06 Jul 2005 19:02:24 -0500 Message-Id: <1120694547.16851.94.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: 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.