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

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

2015-04-17 13:41 GMT+02:00 Alan Hourihane <alanh@fairlite.co.uk>:
> On 17/04/15 08:57, David Gálvez wrote:
>> 2015-04-16 23:19 GMT+02:00 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.
>>>
>> OK, I'll export the entire XHDI interface, and after that I'll take a
>> look to the SCSIDRV interface.
>> In the meantime, should we apply these patches?, because now for
>> example Getbpb( ) BIOS function is returning wrong values for FAT16
>> partitions bigger than 1 GiB in USB devices.
>>
>
> How long would it take you to export XHDI ?
>

I've already started and it's going quite fast. I think I could have
it ready during this weekend, after this weekend perhaps I won't have
too much time to finish it.