Re: [MiNT] What's in, what's out?

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

Hi,

On Mon, Nov 22, 1999 at 06:19:22PM +0100, Julian Reschke wrote:
> a) by trying to keep things outside the kernel and to move them into
> loadable modules instead (the discussion about a new /kern comes to mind),

This is only a solution for optional features, notably drivers. Not to
speak of the overhead that loadable modules require. If I then think about
the price or RAM and harddisk space, the small size of most drivers, I
currently do not consider that to have top priority.  It's a good idea of
course.

> b) by trying to prevent feature and opcode creep,

And who decides what is featurism and what is an improvement?

> c) by not doing changes that break compatibility without having a broad
> agreement on that,

Sure.  But sometimes it is not clearly distinguished between the two
kinds of compatibility.  I agree that MiNT should try very hard to be able
to run most TOS programs.  But I don't agree that MiNT should do anything
at all to make programs written for MiNT run under TOS or other OSes.

> d) by discussing new APIs before it's too late (for instance, a function
> that reads system variables and returns the value in d0 is A Very Bad Thing,
> because you can't detect EINVAL reliably).

Or to not consider everything that can be found in a beta kernel to be
mandatory for the future.  Sure the Ssystem API is not perfect and I don't
understand why we didn't change it after its vulnerability was detected.
If you look at it from a practical point of view 99 % of the people that
develop for MiNT are in very close contact.  We have the power to change
such things.

> To name a recent example, we had a discussion whether we actually need a new
> signal to enable an UPS daemon to inform "init" about a power problem. It
> was discovered, that, yes, we can add a signal for that but it's the very
> last that's free. As far as I remember, no powerful argument was given why
> we need to sacrifice this last unused signal for that purpose. I think that
> discussions like this need to be finished before changes make it actually
> into a release kernel.

And there is not a single application that actually uses that signal.  It
is still time to change its interpretation.  As long as the new signal is
also a fatal and catchable signal, no problem.

As for "/kern": You could not put that into a loadable module, it needs
access to many many kernel variables.

My point of view is: There are many people (at least two - Odd and I)
that still miss features in the MiNT kernel.  Not because I want Linux
with GEM apps but because I want to run software under MiNT that I grew
fond of while working on other platforms.

And besides: If somebody doesn't like the new features it's still possibly
to use an older kernel.  There are reasonably stable.  I think this is
really an option with MiNT.  What do you want to make MiNT more TOS
compatible?  I don't see anything at all.  For me, being interested in
MiNT development implies being interested in new features.

A compromise to me would be to make the kernel build and configuration
process fool-proof.  That would allow everybody to tailor the kernel to
personal needs and preferences.  Thomas has put his slb code inside
"#ifdef SLB_CODE", I have put my /dev/random driver into "#ifdef
DEV_RANDOM".  If somebody volunteers to write a user-friendly kernel build
script everybody could be happy.  Maybe somebody could even provide a
"kernel build server" with a Web-Interface, "get your personal kernel here
..."

Just my point of view.

Ciao

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