Greg KH wrote:
> On Fri, May 09, 2003 at 03:35:36PM -0700, Max Krasnyansky wrote:
>
>>Ok. Sounds like it should be
>> uint32_t hcd_cb[16]; // 64 bytes for internal use by HCD
>> uint32_t drv_cb[2]; // 8 bytes for internal use by USB driver
>
>
> s/uint32_t/u32/ please.
"u32" is prettier, but is there actually a policy against using
the more standard type names? (POSIX, someone had said.)
> And if this is going to be used for pointers, why not just say they are
> pointers? Otherwise people are going to have to be careful with 32 vs.
> 64 bit kernels to not overrun their space.
>
> struct sk_buff uses a char, any reason not to use that here too? Has
> being a char made things more difficult for that structure over time?
No, it's just that in some similar cases having the value be "long"
(not "32 bit unsigned") has been simpler. I'm not religious.
- Dave
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 10 May 2003 10:48 am, David Brownell wrote:
> > s/uint32_t/u32/ please.
>
> "u32" is prettier, but is there actually a policy against using
> the more standard type names? (POSIX, someone had said.)
Not Invented Here?
Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+vIjiW6pHgIdAuOMRAm6+AKCg3P6rUZOvUEcv4emlpwXiGwAA8ACfUlLG
MuHfr7Pmc8yk017a1aWGLYw=
=8zSh
-----END PGP SIGNATURE-----
On Fri, May 09, 2003 at 05:48:16PM -0700, David Brownell wrote:
> Greg KH wrote:
> >On Fri, May 09, 2003 at 03:35:36PM -0700, Max Krasnyansky wrote:
> >
> >>Ok. Sounds like it should be
> >> uint32_t hcd_cb[16]; // 64 bytes for internal use by HCD
> >> uint32_t drv_cb[2]; // 8 bytes for internal use by USB driver
> >
> >
> >s/uint32_t/u32/ please.
>
> "u32" is prettier, but is there actually a policy against using
> the more standard type names? (POSIX, someone had said.)
Yes there is. Linus has stated this a few times on lkml in the past. I
have an old linux journal article that talks about this that I need to
turn into docbook and add to the kernel tree to set it in stone.
thanks,
greg k-h
On Fri, May 09, 2003 at 05:48:16PM -0700, David Brownell wrote:
>> "u32" is prettier, but is there actually a policy against using
>> the more standard type names? (POSIX, someone had said.)
On Fri, May 09, 2003 at 10:40:15PM -0700, Greg KH wrote:
> Yes there is. Linus has stated this a few times on lkml in the past. I
> have an old linux journal article that talks about this that I need to
> turn into docbook and add to the kernel tree to set it in stone.
If someone could clarify the motive I'd be much obliged.
Thanks.
-- wli
On Fri, May 09, 2003 at 10:55:16PM -0700, William Lee Irwin III wrote:
> On Fri, May 09, 2003 at 05:48:16PM -0700, David Brownell wrote:
> >> "u32" is prettier, but is there actually a policy against using
> >> the more standard type names? (POSIX, someone had said.)
>
> On Fri, May 09, 2003 at 10:40:15PM -0700, Greg KH wrote:
> > Yes there is. Linus has stated this a few times on lkml in the past. I
> > have an old linux journal article that talks about this that I need to
> > turn into docbook and add to the kernel tree to set it in stone.
>
> If someone could clarify the motive I'd be much obliged.
Read Linus's comments in this thread for more insight:
http://marc.theaimsgroup.com/?t=102806382900001
Hope this helps,
greg k-h
On Fri, May 09, 2003 at 10:55:16PM -0700, William Lee Irwin III wrote:
>> If someone could clarify the motive I'd be much obliged.
On Fri, May 09, 2003 at 11:11:14PM -0700, Greg KH wrote:
> Read Linus's comments in this thread for more insight:
> http://marc.theaimsgroup.com/?t=102806382900001
That looks relatively arbitrary but I honestly can't be arsed to have
an opinion, only to be informed.
Thanks.
-- wli
At 05:48 PM 5/9/2003, David Brownell wrote:
>Greg KH wrote:
>>On Fri, May 09, 2003 at 03:35:36PM -0700, Max Krasnyansky wrote:
>>
>>>Ok. Sounds like it should be
>>> uint32_t hcd_cb[16]; // 64 bytes for internal use by HCD
>>> uint32_t drv_cb[2]; // 8 bytes for internal use by USB driver
>>
>>s/uint32_t/u32/ please.
>
>"u32" is prettier, but is there actually a policy against using
>the more standard type names? (POSIX, someone had said.)
>
>
>>And if this is going to be used for pointers, why not just say they are
>>pointers? Otherwise people are going to have to be careful with 32 vs.
>>64 bit kernels to not overrun their space.
>>struct sk_buff uses a char, any reason not to use that here too? Has
>>being a char made things more difficult for that structure over time?
>
>No, it's just that in some similar cases having the value be "long"
>(not "32 bit unsigned") has been simpler. I'm not religious.
I don't care either. 'char' is ok for me.
So, I guess in general you're ok with adding ->drv_cb and ->hcd_cb to 'struct urb' ?
Max
On Mon, May 12, 2003 at 10:53:48AM -0700, Max Krasnyansky wrote:
>
> So, I guess in general you're ok with adding ->drv_cb and ->hcd_cb to 'struct urb' ?
I am, as long as someone uses it :)
thanks,
greg k-h
At 11:01 AM 5/12/2003, Greg KH wrote:
>On Mon, May 12, 2003 at 10:53:48AM -0700, Max Krasnyansky wrote:
>>
>> So, I guess in general you're ok with adding ->drv_cb and ->hcd_cb to 'struct urb' ?
>
>I am, as long as someone uses it :)
Ok then.
I'll go ahead and change my driver to use ->drv_list and ->drv_cb and send the patch to you.
Thanks
Max