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

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

Hi,

On Wed, Nov 24, 1999 at 05:28:09PM +0100, Julian Reschke wrote:
> > 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?

Yes, it would be possible to extend /proc, but this extention would be
very radical.  And because of that general compatibilitism attitude we
wouldn't save anything at all (because we still would have to maintain the
old interface) but run the risk that some weird application stumbles if it
finds other (additional) files in /proc than it expects.

I prefer the other solution: If a program does not know about /kern it
cannot be irritated by it.  It can treat the files in there as regular
files.  Attempts to do something undesirable (like unlinking, chmod, open
for writing) will fail gracefully.

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

You mean "it will not work somewhere else"?

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

The former /proc functionality is only a (relatively small) subset of the
functionality in /kern.  This filesystem provides information at a
user-friendly level that Ssystem provides at the internal application
level.  For example a mere "cat /kern/cookiejar" will list all cookies in
a human-readable form along with information as number of total slots and
number of slots used.  You can process it as a regular text file thus
making information available to the casual reader or (more important) to
shell scripts that would otherwise require a specialized tool
(which may be bugger or rely on undocumented features).

The /kern filesystem is one step towards a higher abstraction level and it
is user-friendly as it provides a lot of otherwise hidden information. 

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

See below.

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

Yes, but now that Ssystem is commonly used it is almost too late.  The
only solution would be to rename Ssystem to Ssystem_old (and live with its
vulnerabilities) and introduce a new, improved Ssystem with a new opcode.
But there is someone subscribed to this list that is not very fond of
introducing new opcodes.

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

I think I have already said that: The reason is that I don't know how this
mechanism should exactly work.  But I think if init, the kernel and the
libc react to SIGPWR in the same way as the corresponding software on
System V platforms do, the UPS software available for System V (notably
Linux) should be source-compatible to MiNT.

Source-compatibility is a very important issue for me.  Software that
compiles with no or only minimal modifications tends to get updated very
often, we always have the latest version available (sh-utils,
binutils, rpm, ...).
The more modifications we need the more we are normally behind compared to
other platforms: Old binutils, gcc, ...

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

MiNT lacks a standard setup for the startup procedure.  The /kern
filesystem provides a lot of information that tools that want to simplify
a standardized, easy configurable startup procedure needs.

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

MiNT 1.12.6 was relatively stable.  Provided we find a volunteer it should
be possible to fix obvious bugs in that version too.

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

Yes, my goal is that everybody installs a C compiler because IMHO this is
a vital part of every operating system.  As Sparemint grows more and more
mature this will become only a matter of hardware space.  But users will
only accept that if it is really unproblematic to install the required
tools and libraries.  The /kern filesystem may help a lot to develop tools
that do such tasks without bothering the user with configuration stuff ...

Ciao

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