Re: [usb:usb-testing 17/35] drivers/usb/storage/usb.c:141:21: error: incompatible pointer types passing 'unsigned int *' to parameter of type 'uint64_t *' (aka 'unsigned long long *')

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

 



On Wed, May 01, 2024 at 08:50:36AM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 01, 2024 at 02:32:56PM +0800, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > head:   ac6a205c5bef39d65ecd9f5dd2c1d75652c35405
> > commit: 70d66b8e47e6fa031f541291e9dd3d7f0c44b41e [17/35] usb-storage: Optimize scan delay more precisely
> 
> I'm going to drop this commit from my tree now.
> 
> But really, it feels odd to have this parsing logic in a random driver
> for something like handling floating point numbers "properly" from
> userspace.  Why isn't this in the core kernel somewhere?  And, as that
> was a rhetorical question, the answer is we probably shouldn't be
> handling floating point number parsing in the kernel...

Strictly speaking, this is fixed point rather than floating point.  And 
the reason the commit didn't put the parsing code in the core kernel is 
because no other places seem to need it.  Still, I get your objection.

> I understand the quest for handling error time outs "faster" when you
> assume that you know that the error will never happen, but what's the
> odds that it will end up happening...
> 
> there has to be a better way to do this.

Norihiko, another possibility is to use ordinary integers but have 
users add an "m" or "ms" suffix when they want the value to be 
interpreted in milliseconds.  So "5" means 5 seconds, but "500ms" means 
500 milliseconds.

Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux