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

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

On 17/04/15 13:03, David Gálvez wrote:
> 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.
>

If it's that fast, let's hold off committing this earlier patch.

Alan.