RE: [MiNT] New kernel features

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

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Guido Flohr
> Sent: Wednesday, December 01, 1999 12:13 AM
> To: mint@fishpool.com
> Subject: [MiNT] New kernel features
>
>
> Hi,
>
> sorry, I don't have the time to reply to every single posting regarding
> SIGPWR/kern and so on.  I try to answer most things with one mail.
>
> Let's start with the critics on details:
>
> Why should the /kern pseudo-filesystem be human-readable?
>
> 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

OK, what's the price for a memory expansion board beyond 4MB for a Mega ST?
Where do you buy it? Who's going to install it?

> a trade-off between human-readability (aka user-friendliness) and
> space/speed it is negligible.  "But the formatting consumes space ...":
>
> 	for (i = 0; i < n; i++) {
> 		for (j = 0; j < 4; j++)
> 			strtag[j] = (tag >> (j << 2)) & 0xff;
> 		ksprintf ("%s (0x%08x) 0x%08x\n", strtag, tag, value);
> 	}
>
> compared to
>
> 	for (i = 0; i < n; i++) {
> 		memcpy (tag++, cookiejar[i].tag);
> 		memcpy (tag++, cookiejar[i].value);
> 	}
>
> (don't take it verbatim ...)
>
> Even binary output is not for free.

No, it's not. But it's less expensive. And I claim that you need the binary
interface anyway, so it's not really a choice between the two, but the
question whether a text based interface needs to be *added*.

> Sorry, for me it is really ridiculous to discuss about single bytes
> (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.

The tool that parses needs to start up as well.

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

cat is ein external command, so are the various TTPs that show the contents
of cookies.

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

No, they are not. I think this is the 3rd or 4th time that I am offering the
source to interested people. BTW: MiNT wants to be POSIX compliant, right?
So you need a proper ps command anyway.

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

POSIX has defined the command uname for this.

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

Yes, and that's what I am going to do soon now that we have an API on /proc
for that.

> With a human-readable /kern you can find out just about everything about
> your system with one single program "cat", sometimes piped through "tr"
> to beautify the output a little bit.

So could you with one external command that you run instead of cat.

> Did you ever have the pleasure to debug an unbootable Wintel box?
> Simply take a Mini-Linux bootdisk and browse "/proc" (which is about the
> same as "/kern" here).
>
> Or did you ever wonder why you will hardly find any non-human-readable
> configuration/log/info files on a modern system?  Because this is
> considered bad style.  If it is of human interest it should be
> human-readable, welcome to Unix.

Configuration files: yes. APIs: no.

> 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
> want to argue about that?  If you lack of RAM you count your shortage in

Yes. That's what? 20% plus for a completely questionable functionality???

> MB not kB.  And if you cannot supply enough, bad luck for you.  But
> don't expect the rest of the world to bother about a cryptic interface
> just because you insist on running Apache on a 4 MB ST.

I can't follow why running ps.ttp (with all it's filter options) that is a
standard is more cryptic than the system that you are proposing.

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

Then it's probably a much better idea to try to make it shared *without*
taking up memory when it's not used. Like by making it a loadable XFS.

> ...

> 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
> filesystem as /proc.  I ported "killall5" yesterday: with /kern it was a
> matter of 10 minutes.  Yes, you don't need SIGPWR, you can explain me in
> five minutes how I can waste my time writing power management software
> without SIGPWR and the corresponding functionality of initd.  But I'm
> not interested, thank you.  Write it yourself and don't expect me to do
> your work.

I think it would be a good idea when people would actually read what's
proposed instead. I *never* said that I completey reject /kern -- I just
claim that it can and should be done as a loadable XFS so that it doesn't
take up space for those whon don't need it.

> ...

> Finally, there is also MiNT activity outside of this list and as a
> matter of fact feedback from there seems to focus a lot on Frank and
> me.  Believe it or not, there is hardly any criticism coming from the
> outside world, mostly encouragement (maybe because those folks are
> afraid of critizicing us, both notoric for our totalitarian attitudes
> and secret service decision structures).  Anyway, the "votes" coming
> from there also count for me.

I don't think it's fair to make it an issue of "us" and "them". Discussion
must be allowed, and many people have contributed to MiNT earlier, either by
source contributions, by writing software for it etc. Just because you
happen not to have added kernel features lately, that doesn't mean that you
don't contribute.