[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 ?

Alan.