Re: [MiNT] Issue with XHDI

[David Gálvez <dgalvez75@gmail.com>]

I think the call XHNewCookie is the solution, this call would allow
the MiNT handle to be on the top of the XHDI chain, unlike the cookie
substitution method. The XHDI specification says that this call have
to be tried before changing the cookie.
Although this call is optional is supported by HDDriver, that sure is
the most used hard disk driver for Atari, and it could be implemented
in EmuTOS.
It could be explained in the documentation that MiNT only allows
multiple hardisk drivers if they support XHNewCookie.

Right now the kernel handle doesn't pass this call to the driver.
This is taken from the sources:

"/* XHNewCookie and XHMiNTInfo are never allowed */
    if (op == 9 || op == 16)
        return ENOSYS;"

The best would be to clarify why before modifying this.

David


2010/9/24 David Gálvez <dgalvez75@gmail.com>:
> Hi
>
> I would like to write about an issue i'm having being not able to
> install more than one XHDI driver with MiNT.
> Doing some investigation through the sources i found that MiNT doesn't
> check if the XHDI cookie has changed like the XHDI specification
> recommends.
> I have also seen that MiNT installs his own XHDI handler, so it can
> catch the XHDI calls and emulate them as system calls.
>
> Here i found some explanations about why this is done (the links is
> where this comments come from):
>
> "xhdi_emu.spp, xhdi_emu.h, xhdi.c,
> scsidrv_emu.spp, scsidrv_emu.h, scsidrv.c, scsidrv.h (new):
>        - emulation of these non system call interfaces through systemcalls;
>          necessary for nonblocking DMA operations
>        - added sys_XHDOSLimits for system calls
>        - some enhancements"
>
> http://sparemint.atariforge.net/cgi-bin/cvsweb/freemint/ChangeLog.%231.13-1.15.9?rev=1.1&content-type=text/x-cvsweb-markup
>
> This is from a virtual memory discussion in this list:
>
> "> 1. Disk drivers
>>
>> Atm. disk drivers (XHDI) live outside the kernel. That means the are hard to
>> be put into virtual address space.
>
> That's why the kernel overwrite the XHDI handler by a system call wrapper.
> XHDI calls from user space applications are redirected to a system call
> and handled inside the kernel (privilege checking, restricted to root). So
> XHDI is no problem."
>
> http://sparemint.atariforge.net/mailinglist/Mailing-Lists/MiNT-List.200512/Pine.NEB.4.63.0512081000260.3688@wh58-508.st.uni-magdeburg.de.text
>
> So i would like to ask if there is a method to install a second XHDI
> device driver that i'm not aware of.
> I'm trying to install it in a "dirty" way (TSR program) not with a XDD
> module (may be this is the answer)
>
> And if it's not possible discus how can we solve this inconvenient.
>
> Sorry for the long post
>
> David
>