On Sun, Jan 31, 2010 at 1:12 PM, Mark Duckworth
<mduckworth@atari-source.org> 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