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

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

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Guido Flohr
> Sent: Sunday, November 28, 1999 3:46 AM
> To: MiNT mailing list
> Subject: Re: [MiNT] What's in, what's out?
>
>
> 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.

I'll take a look at it.

> The /kern fs provides the system interface.

So it has a sort of dual 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.

It has been available for year now. Frank complained about it not being
open-source, that's why I offered to give him the sources (and take over
development) if he want's them.

> > > 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 do you think it's such a good idea to add a text-based operating
system interface just to make life easier for a few shell scripts, rather
than defining a proper (and more efficient) binary interface?

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

Right? So why did that happen? Because the interface was just added, not
openly discussed.

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

Yes, how can you say it's important enough to be added as the last available
signal, if you really can't tell us where and how it is used?

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

Compiling the kernel is a nice thing for a few people. Once you start
telling people that they *have* to be able to compile their kernels, you
probably won't be able to convince people to migrate from that other
operating system, right?