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

["Julian Reschke" <reschke@medicaldataservice.de>]

Hi,

in the last weeks there have been some discussions about what should be in
the kernel, and what changes that affect backwards compatibility are ok and
which are not.

Before proceeding, let's be clear about the fact that Frank Naumann has
every freedom to add/change the kernel in whatever way he likes -- if
somebody disagrees, (s)he can fork the kernel development.

But obviously nobody wants THAT to happen, so how can we prevent it?

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

b) by trying to prevent feature and opcode creep,

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

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

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.

Please remember -- the measure for the quality of a kernel is not the number
of features. And, in my opinion, a MiNT that gets bigger and bigger just to
be closer to Linux is a waste of time -- if I would *want* Linux, I would
just use it (and probably not an my slow TT).

Comments?

Julian

--
Julian F. Reschke (mailto:reschke@medicaldataservice.de)
MedicalData Service GmbH Münster, Germany