From mint-bounce@lists.fishpool.fi Sun Jan 31 15:35:58 2010 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz; h=Received:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Smtpd:X-Seznam-User:X-QM-Mark; b=VLhSLX/8Fijsu8BGNd4pKAv6VfRGr+Der+GemsO65C6e7UnKnoYe4VDDh+2Ot9ib3 8PUrai/hS1OQhuXXoRFGAMFIPxL5XBQwz/OQUGfAa9kBDkOHKQdP6OMETIxetRmLMX/ g0dNn/JFscxTfL7nLC6Vg2YoCiegkyi7z5n6cHc= Message-Id: From: Standa Opichal To: mint In-Reply-To: <11a6f2b11001311159u4e048ebai4aaad09306c86d5a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [MiNT] mono Date: Sun, 31 Jan 2010 21:34:02 +0100 References: <11a6f2b11001270642j41b73ecepfd4a7a7cbb3fb354@mail.gmail.com> <11a6f2b11001302144r453c353xdb21efddf53b2ee4@mail.gmail.com> <231FB8B6-8A4A-4EE1-A09B-33C8D77817DC@seznam.cz> <4B65D637.9050202@atari-source.org> <11a6f2b11001311159u4e048ebai4aaad09306c86d5a@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Smtpd: 1.1.7@13984 X-Seznam-User: opichals@seznam.cz X-QM-Mark: email-qm1<502129807> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > with the amount of open source kernels available, adding some of the missing parts should not bee to much of a problem. True. > Getting the code to fit with FreeMiNT is another issue. This is the sentence you nailed it in. That's where I think it is faster to do it the other way around. With regards to getting the stuff into FreeMiNT it would either require a) modifying the parts for integration, which then complicates their maintenance.. downstream/upstream contributions.. or b) building a compatibility layer for every outside code contributions to minimize the maintenance part, but that impacts performance Along the way it is about constantly finding issues on how to afix a modern, complex code base from outside to fit our aging, simpler interfaces. Providing simple interfaces (read the ones from GEM world) on top of more complex ones (the modern ones from outside) is less work and that's why I am suggesting to go in that direction. I'll rather stop here as I won't probably be contributing to either of those anyway (at least codewise)... Standa On Jan 31, 2010, at 8:59 PM, Paul Wratt wrote: > On Sun, Jan 31, 2010 at 1:12 PM, Mark Duckworth > wrote: >> On 1/31/10 1:48 PM, Standa Opichal wrote: >>> >>> Hi Paul! >>> >>> I know it is probably not the thing what most people here would >>> want to >>> hear but IMO >>> it would be less time consuming to port FreeMiNT/TOS APIs, VDI and >>> AES on >>> top of the >>> current NetBSD/FreeBSD codebase then trying to implement the >>> necessary >>> functionality >>> into the FreeMiNT kernel itself. We could nicely call it e.g. >>> Mint(Free|Net)BSD! :) >>> >>> There you get all the apps bundled.... m68k specific patches could >>> still >>> be applied from >>> their SpareMiNT RPMs. And you might even get cross-compile capable >>> packaging >>> system. >>> >>> But that's probably way off the discussion here. I am just trying >>> to put >>> man-years quote >>> on the work to be done to reach the goal... >>> >> I often think of this and wonder if the work on freemint is >> worthwhile as >> compared to this solution. Given the large volume of (more >> importantly) >> highly technical work that needs done that none of us seem to know >> where to >> even begin with, I'm not sure of any better solution. If we did >> this, it >> would have added benefit of giving us useful code from others. >> Problematically most of these systems like bsd or linux are pretty >> slow due >> to bloat compared to freemint. >> >> One thing I have looked at is how Haiku does things. Haiku is very >> lean and >> small but does have these problems solved - but using C++. >> >> Thanks, >> mark >> > Yes, I had noticed that too, and I think Haiku's source license is > compatible with the FreeMiNT one too. > > In FreeMiNT's defence, it is kind of unique in that even though it > bridges the gap between TOS and Posix, it does so by itself. That in > itself is a good enough reason to continue iots developemnt. > > That said, I agree that a genuine experienced posix kernel specialist > is sorely lacking, but with the amount of open source kernels > available, adding some of the missing parts should not bee to much of > a problem. Getting the code to fit with FreeMiNT is another issue. > > Particularly virtual memory management, and the couple of missing and > incomplete parts (lost there names atm), along with kernel modules > which needs fleshing out (especially if fVDI is ever to be available > as a KM). I have seen a VMM for mint out there somewhere (which means > I have it) and I am sure there was source too, that and a memory > (garbage) collector (also with source). > > I have checked out the Haiku sources, and although not complex (being > C++) their volume and integration is (being C++). At the moment my > ability to translate C++ into C is almost non-existent, other > languages, yes, but that particular combo, out of my league atm, and I > dont envy those who try. > > I think some of the harder, and (seemingly) bigger additions required > for FreeMiNT are good candidates for do-it-on-paper-1st open > collaboration, where people can throw code at the problem until a > solution is found, only then taking it to a branch and the compilers. > It would also make it easier to allow non-atari and non-mint kernel > guru's to be approached or add there 2 cents worth.. > > I do know there are at least 2 (overly) qualified kernel peeps out > there at the moment, and I would guess there are more from some of the > web sites I have been looking at lately > > The task of kernel additions would be made a lot simpler if it were > documented somewhere. I seek to update Yes Crews 1998 MiNT System > Calls to get an idea of whats going on, and match that to the source > to see how it is put together > > When I find those above mentioned sources, and have an understanding > of the way the kernel is doing things, I will make some more noise on > the subject. That might be a while tho.. > > Paul > >