Re: [MiNT] What's in, what's out?

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

On Mon, Nov 29, 1999 at 12:06:41AM +0100, Michael Schwingen wrote:
> > > That's nice but only useful in shell scripts. I'd prefer to repair Ssystem()
> > > instead.
> > 
> > The /kern fs actually calls Ssystem to get the information.  And it works.
> 
> In that case, it might as well be implemented outside the kernel, eg. by
> writing a single program that gets the filename in /kern as an argument and
> prints the result to stdout.

/kern/cookiejar was just one example.  That's twenty lines of code and its
handy.

> > Being human-readable does not necessarily imply not-machine-readable.  You
> > can easily parse the information in your programs.
> 
> That is a bad idea. Linux already had incompatibilities due to changes in
> /proc more than once with the effect that some programs crashed on newer
> kernels because they could not parse the modified files correctly.

That has nothing to do with being human-readable.  Binary formats do also
change.

> IMHO, there should be either human-readable output (and then programs should
> be discouraged from parsing it), or there should be an easily-parseable,
> maybe binary, interface for programs to use.
> 
> And if we want human-readable output, I don't think it is good to put this
> in the kernel.

That human-readable output will only consume memory if somebody actually
wants to see it. And performance is not really important for these files.

> > Yes, it's not perfect, but it's too late for a change.
> 
> Sure? How many programs do already use that one broken function?

Ssystem? Every program that is compile with the MiNTLib.  It was already
in the MiNTLib when I took over maintainance for it and that is quite a
time.

Besides, Konrad has already stated it: You can easily work around the
shortcomings, in fact if you follow the recommended usage (check for
Ssystem being available first, and later you usually don't have to expect
errors) you will have no problems. 

> > BTW, what other signals do you want to implement?  Yes, we have heard
> > of a stack overflow signal.  But how do you want to react to that signal?
> > Increase the stack size?  And how do you want to proceed with the current
> > execution?
> 
> If we have virtual memory, that should be the kernel´s task - IMHO, you
> can't catch a stack fault on other unices, either.

Yes, I think so too. A stack overflow signal would currently be useless
and I don't see how it could be useful in the future.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:guido@atari.org