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