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

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

Alan.

On 16/04/15 19:25, David Gálvez wrote:
> When running as MiNT module, the USB mass storage driver is returning
> wrong file system limits when XHDI function XHDOSLimits( ) is called,
> it's returning limits for TOS 4 gemdos.
> With this patch it will return the limits taken from MiNT's XHDI
> pseudo-driver. I have copied those limits into the USB driver, Ideally
> instead of copy them we should get them calling XHDOSLimits( ), to do
> that we should add that XHDI function to the kentry structure so it
> would be exported for modules as we did with XHNewCookie( ), but I'm
> not sure if it's worth the trouble. We could also get the XHDI cookie
> to get the XHDI handle but I don't like this way because the kernel
> will see us as some external application.
> In the XHDI psuedo-handle all MiNT's limits but XH_DL_BFLAGS are hard
> coded, MiNT's asks for XH_DL_BFLAGS to the other drivers in the XHDI
> chain. (I have no idea why). So from the USB driver we can't know that
> value without implementing XHDOSLimits ( ) or using the XHDI cookie to
> get the XHDI handle (as explained above). So I've hard coded it with
> the value 0x00000001.
>
> If you don't agree with this patch and you think it's better to add
> XHDOSLimits( ) to kentry, or you think BS_FLAGS should have another
> value, please you just tell me.
>
>
> Commit message:
>
> When running as MiNT module USB mass storage driver is returning wrong
> file system limits when XHDI function XHDOSLimits( ) is called. Add
> MiNT real limits.
>
> Contributed by David Gálvez