Re: [MiNT] [PATCH][1/3] USB mass storage driver returns wrong FS limits for MiNT kernel

[Alan Hourihane <alanh@fairlite.co.uk>]

On 16/04/15 21:28, David Gálvez wrote:
> 2015-04-16 22:03 GMT+02:00 Alan Hourihane <alanh@fairlite.co.uk>:
>> Hi David,
>>
>> On 16/04/15 20:50, David Gálvez wrote:
>>> Hi Alan,
>>>
>>> 2015-04-16 21:24 GMT+02:00 Alan Hourihane <alanh@fairlite.co.uk>:
>>>> Hi David,
>>>>
>>>> Not sure this makes sense. The following code in XHDOSLimits() in the
>>>> usb's xhdi.c handler does this.....
>>>>
>>>> #ifdef TOSONLY
>>>>         return sys_XHDOSLimits(which,limit);
>>>> #else
>>>>         return ENOSYS;  /* so FreeMiNT kernel will handle this call */
>>>> #endif
>>>>
>>>> So sys_XHDOSLimits() would never be called in the FreeMiNT case.
>>>>
>>> The problem is that sys_XHDOSLimits is called also from inside the USB
>>> driver, in install.c the function build_bpb( ) calls it three times,
>>> and it ends filling with wrong values the BPB struct.
>> I see, so really, for these calls, we should be getting the XHDI handler
>> cookie and calling XHDOSLimits instead.
>>
>> Can we do that instead of duplicating the MiNT code ?
>>
> We can do it and it would work but I don't like that solution because
> going through MiNT's XHDI handler it's like we were a process from
> outside the kernel. If this code wouldn't be in a module but inside
> the kernel binary we would be able to call XHDI functions directly. To
> do the same from modules we need to export XHDI functions with kentry
> structure as we did with XHNewCookie. So for me the cleanest solution
> would be to add XHDOSLimits ( ) to kentry, or how I said in a previous
> email perhaps we could add the entire XHDI interface.
>

I'd be fine with that. Do we do it for SCSIDRV too ? If not, we might as
well do that as well, so we can leverage my SCSIDRV code.

Alan.