Re: [MiNT] New kernel features

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

no, I didn't fall into deep despair, I simply had too much other work.  I
couldn't read my mails therefore.  I hope nobody minds if I give once more
a "common reply".

It seems that everybody has missed the most important point in my previous
posting: I will withdraw both SIGPWR and the /kern filesystem.  You will
not find it in future kernels unless you compile your own kernel and set
an additional define.  No need to debate the implementation.  Nobody is
forced to use it.

But I will make the init suite dependent on these features.  And they will
also depend on the text interface of the /kern filesystem.  You have to
understand that.  I have a certain schedule that I follow and the time
that would be needed to rewrite a bunch of tools from scratch is not
scheduled.  Besides, I apparently don't like the proposed alternatives and
that should be enough.  If anybody doesn't like my approach, you are not
forced to use it in any way.  Can I do more?

If somebody really likes the idea of a SystemV compatible init suite but
really hates my /kern filesystem: Fine, the sources will be free, modify
them to grok with a /proc-only kernel without SIGPWR but don't expect me
to do that.

And if anybody wants to turn /kern into a loadable filesystem: Go ahead,
good luck.  Parts of the functionality will not be available in that
loadable module (unless you blow up the kernel again), but that's fine
with me.  Only, this extra work is not on my schedule.

Before you flame me for this lonesome decision: Once again there was no
agreement and I had to decide some way.  I think everybody can live with
this decision.

If there is one thing I have learned from all that, it's this:  I think it
is about time to really split up the kernel development into two different
branches.  One, with minimal functionality, no features other than those
that are strictly required to do multitasking and one which is oriented
towards new developments in other operating systems.

As a matter of fact there are people that are very happy that MiNT offers
a close-to-unix environment on machines that were manufactured years ago.
They accept that hardware developpers mostly abandon them completely but
they seemingly don't expect that software developpers come to a point
someday where they say that it's getting ridiculous to support such
machines.

But unfortunately, if you expect that a MiNT system (not only the
kernel, most resources are always eaten up by custom software) still runs
on a 4 MB STE you also expect that the only benefit of better hardware is
that you can run more applications at once and that they run faster.

I have used a TT with 10 MB for years and I know what it is like to lack
of resources.  But: I also always run a debug kernel which consumes about
100 kB more disk space and probably about the same amount of extra RAM.
It never came to my mind to even temporarily replace my kernel with a
non-debug kernel because that never would have solved any such problem.

However, if these little things really cause such big trouble I would
prefer to make every new functionality available only as an optional
feature.  I can try to write a somewhat more user-friendly build interface
so that everybody is able to build a custom kernel.  Those people that
don't have the resources to build their own kernel will probably be the
same that generally oppose new features, natural selection ... ;-)

Keeping up compatibility with m68000 machines might also offer some
marketing opportunities.  I wouldn't be surprised to see a microprocessor
controlled vacuum cleaner running MiNT soon. If you give it another meg of
RAM you could even browse the cobwebs in your house and the world wide web
at the very same time. ;-)

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:guido@atari.org