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
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.
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.
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
...
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.
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.
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
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.
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.
So much about human-readability.
But that's actually only a defense of the Linux design of /proc because
the MiNT /kern is in fact pretty much the same. So why aim at Linux
compatibility? Sure, Linux is not perfect and most subscribers of this
list are positively convinced that they could do just about everything
better then those amateurs that develop the Linux system. Unfortunately
they only *could*, in reality they spent their time discussing each
petitesse to pieces and mostly contribute nothing. Of course everybody
would like to have those tiny little nifty titbits that Linux offers,
but how to get them? Write a decent package manager for MiNT? Write a
most-sophisticated web server for our Atari? I prefer to become
compatible at the basic stuff and then "configure && make". RPM is a
good example for that. Believe it or not, I spent more than three
months introducing new code in the MiNTLib before I was able to get rpm
running (search in deja-news for kellis: "rpm? hopeless, way too much
missing").
As a result, you have rpm now (BTW, a real waster, the bare executable
is already one MB). And if you need realpath() you have it. If you
need a Berkeley style libdb, you have it. If you want to improve
security of anonymous ftp by means of chroot() you have it (thanks
again, Frank, for digging up the kernel fs stuff to make this work).
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.
You think you could do all this far better? Fine, but then do it and
don't talk it. Yes, Jörg, you *did* contribute something and mean old
Frank refused to implement it. I don't know how much Frank and you
discussed it and I don't know anything about TraPatch and I probably
wouldn't understand it, so I cannot comment on it from a technical point
of view. But if you are so convinced of your concept, why don't you
seize flaming Frank and defend your concept instead? Yes, I agree, if
somebody cared to contribute a lot of work to FreeMiNT, rejecting this
contribution should have been worth more than one single line of comment
here. But remember, his name is Frank Naumann and not INRI.
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.
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
ago that I was working on a port of the Linux SysV init suite, there was
no contradiction, I have developped a concept (a quite large one by the
way) for this project and I will follow that concept now because I have
already invested too much time in it. I don't care whether there is a
/kern filesystem or a SIGPWR in the kernel as long as they exist in my
kernel. And I don't care whether anybody uses that init suite or not as
long as I can use it myself. If you want to try it, install a
kern/SIGPWR kernel and decide yourself. Until then there is no more
need for any discussion, I withdraw my kernel patches. OK, don't cry, I
will revise them and put them into #ifdef SIGPWR_AND_SO_ON.
If you have made it until here you must be really interested in MiNT.
Maybe, now that this debate can be finished we can focus on a real
problem: There is somebody out there who really contributed a whole lot
of sweat and time to MiNT (I hope we agree on that) and can no longer
participate in our efforts. I am still thankful for all those kind help
offers (both material and immaterial) that I received when I had
hardware problems. Isn't it possible that with common efforts we find a
way to provide kellis with a working MiNT machine? As far as I
understood it, it is her mere Falcon that is dead. There has to be some
way to come over this. I would personally miss her contributions a lot.
Thank you for your patience.
Guido