NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/atari/st/tech/6242

Text File | 1992-12-14 | 6.9 KB | 159 lines

Newsgroups: comp.sys.atari.st.tech
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!news.uni-bielefeld.de!techfak.uni-bielefeld.de!itschere
From: [e-mail] (Torsten Scherer)
Subject: RE: MiNT, which way forward...
Sender: [e-mail] (News Administrator)
Message-ID: <[e-mail]>
Date: Mon, 14 Dec 1992 15:47:14 GMT
Nntp-Posting-Host: lerche.techfak.uni-bielefeld.de
Organization: Universitaet Bielefeld, Technische Fakultaet.
Keywords: MiNT
Lines: 146

Mr Stephen R Usher writes the following stuff I'd like to comment:

> From reading the comp.sys.atari.st* groups it has become increasingly clear
> that there are two distinct groups of MiNT users, each of which have
> differing priorities for future developments.
>
> The two groups are as follows:-
>
> A) People who are looking for MiNT to provide a multitasking kernel
>    underlaying GEM so as to give the same sorts of functionality as MS
>    Windows, Windows NT or Apple's MultiFinder.
>
> B) People who are looking to use MiNT as the basis for a cheap substitute
>    for Unix as a development environment and possibly as a multiuser
>    service.

I personally would declare myself as clearly beeing a momber of BOTH groups.
But let's take this for truth...

> Group A have the following priorities:-
>
> (1) compatability with the old Mono-TOS/GEM

Compatibility in terms of the numbers of gemdos calls yes, but where's the
problem? "clean" programs should always run on any TOS, and "clean" is what
we're supposed to program, the era of dirty tricks should have gone by now.

> (2) process protection
> (3) rudimentry virtual memory (ie monolithic, merely giving the
>     processes in total a machine with a virtually bigger RAM size)

Isn't that very likely to be the same point? Using the PMMU for both protected
and virtual memory would be great.

> (4) networking (virtual drives)

sounds interesting, but only interesting in a professional area.

> Group B have these priorities:-
>
> (1) Process protection (including user id access control)

Isn't that allready included? When running your multi-user-package I can't kill
a process from another user at a terminal line. Because of the total lack of
protected memory I'm of course able to do some really ugly things...

> (2) Close emulation of Unix at library/OS levels.

Not neccessarily, I've never seen a program which has been directly ported
without major or minor complications, so you've got to rewrite parts of it
anyway. Of course this depends on the length of the program...

> (3) Internal Unix-like networking stubs (ie sockets, both UNIX and
>     INET Domains). Drivers for networking itself could be loaded
>     at boot time, but the code for inet stuff etc should be in
>     the kernel and multithreaded so as to be able to guarantee
>     as fast a response as possible. The INET loopback device
>     should be in the kernel as standard too.
> (4) Per-Process, highly efficient virtual memory (giving a process a
>     virtual machine)

don't think that's a good idea, think that's too complicated for too few use

> (5) Shared libraries
> (6) Mountable file systems (so only those file systems which the
>     operator wants to appear are actually visible, and they can
>     be placed where they are needed)

see below

> (7) Hardware specific terminal/serial drivers (which can take full
>     advantage of the higher specification hardware available on
>     the Mega STE, TT and Falcon)

This would be great!

> (8) Multithreaded file systems
> (9) Less granularity for scheduling. (MiNT currently feels to have
>     very coarse context switching.)
>
> Much of the stuff on group (2)'s wish list would help group (1), eg real
> virtual memory, networking available in kernel (anyone wana use NFS over
> UDP/IP on top of X25 on the MSTE/TT/Falcon network port?).
>
> Other things clash, such as group (2)'s wish for disk devices to be
> invisible until mounted whilst group (1) wanting them to appear as
> MS-DOS/GEM-DOS-like devices.

why not create a new super-device like the unix '/' and be able to mount
normal TOS partitiones as well as MINIX partitiones or whatever future will
bring? There's no great difference to what MiNT is now like, except that now
every possible drive is automatically "mounted" to u: and all deviced are also
accessible by their "normal" name instead of u:/devicename/. So I don't think
this will clash with group A priorities, they've just got to put a small line
in their mint.cnf and everything is like it was. The advantage is a better
control over the access possibilities in a multi user system, if, and that's
what I suggest, the mount point can be given an owner, a group and unixlike
access permissions.

> The advantage of using the INET protocols for networking is that once a
> person has a device driver for thier network interface hardware (eg an
> ethernet controller of some kind or even a serial line for SLIP or PPP or
> Packet Radio) they could just plug into their nearest network and be away.
> Also the INET protocols and NFS are in the public domain.
>
> Networking using INET protocols takes up space which small machines would
> have problems coping with, however, especially if they were on non-68030
> machines with less than 4 megs of RAM. In which case, should there be two
> MiNTs, the normal one and VMMiNT with all the networking and VM stuff in
> there? Or should there be three or four?

Wouldn't it be possible to write a version which automatically detects on
which processor it is running and behave optimized? I don't think writing two
or more versions is a good idea, but I also see the problem that many "new"
features of MiNT really require a '30 processor, so what about the peoples
without one?

> I think the question which sums this all up is:-
> Which way now?
>
> Steve
> JANET:-    [e-mail] or    [e-mail] (preferable)
> Internet:-    [e-mail] or    [e-mail] (preferable)

I don't claim to be a great programmer, so I would probably not be able to
write this stuff, but what *I* would MiNT to be like is:

- to have virtual memory *when* running on a '30 or higher
- to be more flexible in the filesystem
- to be more secure, real protection with a '30 plus MINIX fs
- to offer more support for virtual devices and networking, if possible through
  the standart ports *and* LAN ports etc.
- to be able to run more GEM programs, but that's another story


that's my wishlist
Torsten

-------
TeSche (Torsten Scherer), Estudiante de la computacion en la
Universidad de Bielefeld, Calle de la Universidad 25, D4800 Ciudad de Bielefeld
*******************************************************************************
paper mail: Wiesenstrasse 28, D-W4970 Bad Oeynhausen 1, Germany
internet e-mail : [e-mail]
                  [e-mail]
*************************************************************************(EOT)*