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

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

Hi,

On Fri, Nov 26, 1999 at 11:40:47AM +0100, Julian Reschke wrote:
> > I prefer the other solution: If a program does not know about /kern it
> > cannot be irritated by it.  It can treat the files in there as regular
> > files.  Attempts to do something undesirable (like unlinking, chmod, open
> > for writing) will fail gracefully.
> 
> I'd still like to hear what this additional information is, and who needs
> it.

I can mail the manpage kern(5) to everybody who is interested.  It's still
preliminary but gives a good outline already.

> > The former /proc functionality is only a (relatively small) subset of the
> > functionality in /kern.  This filesystem provides information at a
> > user-friendly level that Ssystem provides at the internal application
> > level.  For example a mere "cat /kern/cookiejar" will list all cookies in
> > a human-readable form along with information as number of total slots and
> > number of slots used.  You can process it as a regular text file thus
> 
> 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.

> > making information available to the casual reader or (more important) to
> > shell scripts that would otherwise require a specialized tool
> > (which may be bugger or rely on undocumented features).
> 
> If the operating system interface is right, I don't see why such a
> specializid tool would be either buggy or would need to use undocumented
> features.

The /kern fs provides the system interface.

> Parts of this seem to come from the fact that there is no free AND
> open-source ps utility which works well with MiNT. But this situation could
> easily changed. I already offered Frank to give him the source of my ps tool
> which works extremely well (besides the bug descovered by MER, but this is
> already fixed).

Why give it to Frank?  You can upload it to a hundred of ftp servers.

> > The /kern filesystem is one step towards a higher abstraction level and it
> > is user-friendly as it provides a lot of otherwise hidden information.
> 
> Without having seen a specification I can only guess what it will actually
> do. If it makes the information accessible ONLY in a human-readable ASCII
> format, I would say it's a waste of kernel space and a poor replacement for
> a properly working API on /proc.

Being human-readable does not necessarily imply not-machine-readable.  You
can easily parse the information in your programs.

> > Yes, but now that Ssystem is commonly used it is almost too late.  The
> > only solution would be to rename Ssystem to Ssystem_old (and live with its
> > vulnerabilities) and introduce a new, improved Ssystem with a new opcode.
> > But there is someone subscribed to this list that is not very fond of
> > introducing new opcodes.
> 
> 1) If you want people not to access system variables directly, you MUST give
> them an interface that actually works.

Or people have to think of work-arounds.  As far as I can see, there are
work-arounds for the Ssystem bugs.

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

> 2) I cited this as an example for a poor API that found it's way into the
> kernel because it wasn't discussed before.

If somebody would have stood up and shouted "it's buggy!" it would have
been changed.  But you cannot change it now, years later.

> > I think I have already said that: The reason is that I don't know how this
> > mechanism should exactly work.  But I think if init, the kernel and the
> 
> If you don't, maybe it's a bit premature to change the kernel for the sake
> of something which might be a misunderstanding, correct?

SIGPWR is neither a weird idea nor a misunderstanding.  It is a System V
feature and its existance aids in porting power management software to
MiNT.

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?

> > MiNT lacks a standard setup for the startup procedure.  The /kern
> > filesystem provides a lot of information that tools that want to simplify
> > a standardized, easy configurable startup procedure needs.
> 
> So maybe the problem should be described first? Maybe it makes more sense to
> think about changes in the startup procedure?

That's what I'm doing.  And the problem is obvious: The shutdown
procedure(s) have to find out which processes should be killed and which
shouldn't.

> > Yes, my goal is that everybody installs a C compiler because IMHO this is
> > a vital part of every operating system.  As Sparemint grows more and more
> 
> No, it's not.

Yes, it is.  Without a C compiler you cannot compile your own kernel.

And besides, a lot of software is only distributed as source code.

> > mature this will become only a matter of hardware space.  But users will
> > only accept that if it is really unproblematic to install the required
> > tools and libraries.  The /kern filesystem may help a lot to develop tools
> > that do such tasks without bothering the user with configuration stuff ...
> 
> How about specifying what /kern actually is supposed to do? One point of my
> original mail was that new features have made it into the kernel, without
> being discussed in this list. And I think this is a bad thing.

Everybody can have the manpage.  And the /kern filesystem will be
specified as experimental.  Everything can be changed, extended or
removed.

Ciao

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