Re: [MiNT] New kernel features

["Anthony Jacques" <anthonyj@jacquesa.freeserve.co.uk>]

> > 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.
>
> Then it's probably a much better idea to try to make it shared *without*
> taking up memory when it's not used. Like by making it a loadable XFS.

Agreed. XFS seems the obvious way to implement additional file-systems...
provide an API that the XFS can query, then if you want human readable then
it can just use the API, or if an app requires the info it can use the API
directly.

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

Sorry, but its a case of NOT implementing it.... If you implement SIGPWR,
then someone cant "unimplement" it without forking development. Why not just
leave this signal alone completely until someone decides to create a powerd
and finds they are unable to figure a way without using SIGPWR? [or, finds
another way...]

Okay, so maybe your port of init will have a single line redefining SIGPWR
to another [perhaps inoproriate] signal (put it in the makefile if you
prefer not to modify the source at all). Is this really a big issue, when we
dont have an initd - feel free to "correct" the Makefile when/if someone
implements a powerd and tries to raise a SIGPWR.

> I think it would be a good idea when people would actually read what's
> proposed instead. I *never* said that I completey reject /kern -- I just
> claim that it can and should be done as a loadable XFS so that it doesn't
> take up space for those whon don't need it.

Seems logical to me.

> I don't think it's fair to make it an issue of "us" and "them". Discussion

Yes, it is getting very confrontational on this mailinglist, and in general
it isnt good for the development of MiNT...

Anthony