Re: [MiNT] Issue with XHDI

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

2010/9/27 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.

I've looked again into this and the reason it looks now very obvious,
MiNT isn't allowing XHNewCookie in his XHDI handle because calls that
go through this handle could come from user application and from the
MiNT point of view none user application should try to install itself
as a driver, so i forget about modifying the code above.

Then to install another XHDI driver with MiNT, i have two options:
1) create a TSR and put it before the kernel in the auto folder.
2) from a kernel module calling XHNewCookie but not through the kernel
XHDI handle but directly as the kernel does with other XHDI functions
in block_io.c, i must see how this can be done from a module.

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