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

[Michael Schwingen <rincewind@discworld.dascon.de>]

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

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

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.

> Yes, it's not perfect, but it's too late for a change.

Sure? How many programs do already use that one broken function?

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

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen