Re: [MiNT] This fight

[Petr Stehlik <joy@sophics.cz>]

V Čt, 11. 12. 2003 v 23:26, Frank Naumann píše:
> > I said 'drivers'. For example the sound driver (which is not yet a
> > module). Anyway, forget it for now (it's a discussion about
> > TSR-after-MiNT which is another major topic and would increase the
> > confusion even more).
> 
> Ah, so instead writing FreeMiNT drivers you want to write TSR (ok, I know
> you want to support TOS and MagiC). From my FreeMiNT side it's not in my
> scope to add support for TSR drivers.

You didn't understand me. Even if I said "forget it" you replied. Now I
have to explain it at large to prove that it wasn't about writing TSRs.
Actually it was exactly about the opposite - about fixing TSRs to cope
with MiNT and about making MiNT bootable on TOSless machines (is it
called bootstrap?)

For that the subject change is necessary. It has to be a new thread. And
the discussion is even less interesting than the NatFeat extension as
actually no one here needs bootstrapping MiNT.

> But you don't want to abstract and generalize this stuff into the
> operating system so that all users can profit of them.

How could this be generalized in the kernel? NatFeat covers all possible
extensions at once. I thought about the platform generalization at the
library level. Maybe I was wrong.

> > it could call the NF_NAME to obtain the host name.
> 
> Wrong, sysinfo() use gethostname() to obtain the hostname.

I am too lazy to check the MiNTlib source code to see the function
chain. My idea was just to return "ARAnyM/iMAC" or "STonX/Oxygen"
instead of "Falcon" or "TT". Just a pure visual thingy, nothing
important. It was just a (bad) example of how 'useful' NatFeats can be
;-)

> > These two calls are used for invoking the NatFeats from a C code.
> 
> Ah, to clarify, you just want a generic way to add anything you like and
> get this pushed through the kernel.

Sort of, yes. It should have been possible to call NatFeats while
keeping it under the kernel supervision and also offering a replacement
for the NF cookie pointers. Luckily Lonny has just opened my eyes - the
cookie pointer problem was not a real problem as there is no real
demand. We can fix it internally as I already said.

> you want it aranym specific there is no need to enhance or develop
> anything on the FreeMiNT kernel or VDI/AES side.

Well. It's hard to comment this for fifteenth time. I will better go
sleep.

Petr