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

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

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Guido Flohr
> Sent: Thursday, November 25, 1999 10:47 PM
> To: MiNT mailing list
> Subject: Re: [MiNT] What's in, what's out?
>
>
> 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.

I'd still like to hear what this additional information is, and who needs
it.

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

Yes, sorry.

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

That's nice but only useful in shell scripts. I'd prefer to repair Ssystem()
instead.

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

If the operating system interface is right, I don't see why such a
specializid tool would be either buggy or would need to use undocumented
features.

Parts of this seem to come from the fact that there is no free AND
open-source ps utility which works well with MiNT. But this situation could
easily changed. I already offered Frank to give him the source of my ps tool
which works extremely well (besides the bug descovered by MER, but this is
already fixed).

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

Without having seen a specification I can only guess what it will actually
do. If it makes the information accessible ONLY in a human-readable ASCII
format, I would say it's a waste of kernel space and a poor replacement for
a properly working API on /proc.

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

1) If you want people not to access system variables directly, you MUST give
them an interface that actually works.

2) I cited this as an example for a poor API that found it's way into the
kernel because it wasn't discussed before.

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

If you don't, maybe it's a bit premature to change the kernel for the sake
of something which might be a misunderstanding, correct?

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

So maybe the problem should be described first? Maybe it makes more sense to
think about changes in the startup procedure?

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

No, it's not.

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

How about specifying what /kern actually is supposed to do? One point of my
original mail was that new features have made it into the kernel, without
being discussed in this list. And I think this is a bad thing.