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

["Julian Reschke" <reschke@medicaldataservice.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

Yes. Why is /kern not optional? If it is supposed to do something which
applications other than a new ps.ttp need, why not move the functionality
into the existing /proc interface?

> 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

RAM might be cheap, but buying expansion cards for your ST/STE/TT/Falcon
might not.

> 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?

Ultimately the person who maintains the code. But I think the recent
discussions show that the acceptance will be much better when people
understand why changes were done. Or, alternatively, the discussion here
might result in better approach.

> > 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.

Obviously a MiNT-only feature will work somewhere else. But sometimes it can
be avoided to move away from existing functionality. The discussion about
/kern sounds alot like: I don't like this interface, thus I invent a second
one (which is then MiNT-only). I think it makes more sense to put into /proc
what's really needed.

> > 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

Yes, but 1.15.5 is a release kernel, correct?

> 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.

Great. That's what I am just trying to do.

> > 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.

Maybe you could explain a bit more which processes are actually using this.
My understanding from what was publshed here is that (i) a daemon sends it
to "init", and (ii) init uses it to shut down the processes it started.

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

Well, you can. Give it access to the internal variables. Of course it will
need to be updated when the kernel changes, but that shouldn't be a problem.

> 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

I don't think this is an option. New kernels will always contain a mixture
of bug fixes, performance enhancements and new features.

> compatible?  I don't see anything at all.  For me, being interested in
> MiNT development implies being interested in new features.

Yes, but they should be introduced in a way that makes sense.

> 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

Everybody with a working gcc/MiNTlib setup, maybe. Do you want to restrict
the MiNT audience to those people. Then you can say "use MagiC" as well...

> "kernel build server" with a Web-Interface, "get your personal kernel here
> ..."
>
> Just my point of view.

That's ok -- that's the point of a discussion :-)