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 Frank Naumann
> Sent: Thursday, November 25, 1999 8:56 PM
> To: MiNT mailing list
> Subject: RE: [MiNT] What's in, what's out?
>
>
> Hi Julian!
>
> > 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?
>
> For compatibilty reasons we can't expand /proc in a clean way.

Sorry, I think this a very broad statement without any facts supporting it.
The first step would be to describe what additional features are required --
then it can be discussed how to do that.

> > 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.
>
> No, the reason behind is that the /proc filesystem is now 8 years old and
> not powerful enough for modern applications. Especially for tools from
> other Unix platforms that we like to have without a complete rewrite.

Which tools except "ps"?

> We don't have enough ressources to maintain our own versions. So we can
> stay with the old buggy and outdated tools or we try to port from other
> platforms.

What buggy or outdated tools are ou referring to?

> > Yes, but 1.15.5 is a release kernel, correct?
>
> Yes, and there is no /kern inside ;-).

Yes, but the change for SIGPWR is in it.

> > 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.
>
> No, this isn't a good method in my eyes.

One have to find a compromise, sure. If the new /kern fs is only needed by
one or a few esoteric Linux utilities, I would argue that it's acceptable to
have it as a loadable module relying on a special kernel version. Just
update and distribute both at the same time and version it properly.

> > That's ok -- that's the point of a discussion :-)
>
> The main point of this discussion is the way of FreeMiNT. Eventual it's
> time for a goal redefinition.
>
> My main goal is stability, speed and more Unix functionality.
> Second goal is to save/enhance TOS compatibility.

1. Keep defined compatibility

In my eyes, everything should be secondary -- otherwise don't complain about
people sticking with MagiC.

I don't say that there can't be new features. The question is: do they need
to be in the kernel, or does it make more sense to enhance the kernel
interfaces (like for shared libraries). I can think of a lot of shared
services I would like to see in my system, but do they need to be *in* the
kernel? I don't think so. Examples: character set translations, encryption
(yes), XML parser, regular expressions, and so on....

> Until now I also rejected extensions that don't follow the philosophy of
> a good operating system design (like joergs trapatch extension). My
> references for a good design is A.Tanenbaum, "Modern Operating Systems"
> and "The design and implementation of the 4.4BSD Operating system" from
> McKusick, Bostic, Karels and Quarterman.
>
> The main point are the Unix extensions. In my eyes it's very helpful for
> the future and for software porting if we agressive enhace the kernel for
> elementar functions.

I like Unix. But: if I would want a Unix system, I would just install it. I
think the strength of MiNT has been somewhere else, and it is to be small,
to run on those old machines, and to keep TOS compatibility while adding
some things from more powerful systems.

If your plan is to turn MiNT into a Linux clone then I must say --
completely futile. Become a Linux contributor and add a GEM interface layer
instead.

> Until now I added 4 new systemcalls: Dchroot(), Ffchown(), Ffchmod(),
> Fstat64(). For the future I planned mmap/getmntent/user_context functions.
> I also prepared Fsync(). The MiNT-Lib will support all of these new
> features for a higher Unix compatibility.
>
> This affects mostly Unix programs that can better run under MiNT.