Re: [MiNT] New kernel features

[joska@nuts.edu (Jo Even Skarstein)]

On Wed, 01 Dec 1999 00:13:17 +0100, Guido Flohr wrote:

> Because it's 1999 and not 1989.  Have a look at your dealer's price
> lists for RAM and hard disks and then think again.  Besides, if there is

Well, an aixTT alone costs almost as much as the complete second-hand PC I
recently bought (200MHz K6, 64Mb RAM, 3.5Gb disk, 4Mb ATI Rage 3D Pro graphics
card and a 32x Sony SCSI CD-ROM), so upgrading a TT is rather expensive...

> (even if they sum up).  Same with performance: Compare the time that the
> tool that actually reads these files (no matter if binary or
> human-readable) will need to start up (read the image from disk,
> relocate, create a basepage, put it into process queue, ...) with the
> time needed for the parsing.

That's a valid point, but only in the defence of the API.

> Say I would fall back with yous into stone age windows style and hide
> that information from the user by making it illegible to human-readers,
> how would this work?  You want to read the cookie jar? Fine, take
> MiNT-Setter (and write your own tool if you really care about
> performance and don't have GEM running at all).  With /kern, simply "cat
> /kern/cookiejar".
>
> Want to peek into a process's environment?  Take the extremely
> well-working ps.ttp (don't worry to think about modifications, the
> sources are a trade secret) and list it.  Or with /kern, simply "cat
> /kern/85/environ".
>
> After some update session want to know which kernel is currently
> running?  Write a tool yourself, convert the output of Ssystem and
> display it.  Or "cat /kern/version" and you can see who build when which
> kernel version on which host.
>
> Want to find out the exact memory usage of a certain process, including
> adresses, flags etc. of all allocated blocks?  Write a tool yourself or
> ...

I don't know much about /kern on Linux, but the things you listed above
can just as well be implemented in a XFS.

> Yes, summed up this new functionality will consume a considerable amount
> of RAM, I wouldn't be surprised if it is 30 or 40 kB.  But do you really

Well, MiNT already consumes around 700Kb on my Falcon, so I guess that
another 40Kb doesn't mean much... However, The Other Os (which I won't
mention here) fits (X)BIOS, GEMDOS, AES and desktop into the same amount
of memory.

> Furthermore: We don't have shared libs.  The more functionality is
> stuffed into the kernel the better because it can be moved out of
> applications.  That will save both RAM and harddisk space.

...but if this functionality can be placed in loadable modules you'll
save even more space, right? Perhaps this is the time to consider another
module-interface?

Btw. my Palm III has the entire libc in the OS, which indeed make the
applications compact. Should this be considered in MiNT as well?

> So, even if I would agree with you that illegible binary output would be
> more adequate for the /kern filesystem, I would still opt for the
> current style because it is compatible to Linux where this seems
> necessary.  There is a vast amount of useful software available for
> Linux that should be really easy to port with a somewhat similar

I agree that Linux-compatibility generally is a good thing, but you should
also keep in mind that Linux is getting more and more functionality in
loadable modules, and not compiled into one huge binary. This is what I
don't like about your /kern-proposal - you can't ditch it without
recompiling the kernel. If it can't be put into an XFS, perhaps another
more advanced module-interface should be considered?

> You are fed up reading my lamento?  Sorry, so am I debating stuff over
> and over again never being the wiser afterwards.  There seems to be no
> such thing as agreement on this list.  I've announced a couple of months

Exactly, and those who believe that every little detail should be discussed
and voted upon have completely misunderstood something. ME refered to this
list's FAQ - sorry ME, but the appropriate place to look for this is the
FreeMiNT license, and it says absolutely nothing about this. Anyone can
modify and distribute FreeMiNT if they want, and there's no need to confere
with anybody before you do it.

But that doesn't mean that it's the best way to do it, IMO major changes
should definitely be openly discussed. Not to achieve 100% agreement on
everything (that will never happen), but to listen to other contributors
(people who develops software for MiNT are also contributors) and hear
what they have to say - it might even be sensible...


/*
** Jo Even Skarstein    http://www.stud.ntnu.no/~josk/
**
**    beer - maria mckee - atari falcon - babylon 5
*/