Re: [MiNT] This fight

[Petr Stehlik <joy@sophics.cz>]

V Čt, 11. 12. 2003 v 16:28, Frank Naumann píše:
> Ok. And which functions do you like to add to the kernel?

Can't we just export the NatFeat interface so that drivers can use
whatever they need? Or do we want the drivers to check for the NF
presence by themselves, without the kernel support? Or do we perhaps
want another (hardware specific, loadable) layer of separation that
would sit between kernel and XDDs and would provide hardware specific
features to the XDDs? I thought kernel itself could handle that - it's
not that many wasted bytes of RAM. FYI, the NFID and NFCall functions
take each just 4 bytes of memory.

> > Does it make sense now?
> 
> Now, this doesn't make sense. An ioctl always refer to an file handle.

You got me, ioctl is not the right thing. Isn't there another way of
calling the kernel API - something like syscall(SYS_NF,...)? Or perhaps
XDD drivers can call kernel function directly without going through the
syscalls? I don't know, I am not into the kernel.

> I didn't get your point. If someone need a MiNT function that is not
> available under TOS/MagiC he simply can use MiNT.

That's true. I never thought about it from this point of view. If
MiNTlib no longer supports the TOS compatibility mode then linking with
it basically creates MiNT only binaries.

> MiNTLib at least do it's
> best to map some things to TOS/MagiC but most advanced stuff does only
> work under FreeMiNT correctly.

Is sysinfo() most advanced or not?

> But why do you want to enhance TOS/MagiC for FreeMiNT functions?

I thought I would save myself another 'fight' about reading NF cookie in
MiNTlib if I went ahead and wrote a TOS TSR for that syscall.

> Where do you want to stop (after you rewritten FreeMiNT)?

LOL :) Don't worry, I won't start even the FreeMiNT rewrite.

> If this is exactly what do you want, why do you need a special syscall?
> This doesn't affect user space at all.

We'd like to start _somewhere_. Currently ARAnyM offers some things via
the NatFeats (and may/will offer more) and these things should be
wrapped in libraries and then used in drivers or perhaps even in
applications. The libraries would then be extended to make use of other
specific hardware on other platforms (e.g. DSP on Falcon, or 68040FPU,
or gfx card acceleration or god knows what else). If we don't even have
a MiNT friendly way of exporting the NatFeats how can we expect people
start writing libraries or even the applications for MiNT?

You (MiNT) convinced us (ARAnyM) that cookie jar is not the way to
export NatFeats interface under MiNT. OK. Is the syscall a good way or
not? Or is there a better way? I am just curious, no offense or
anything.

Petr