Alan Stern <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Sergei Organov wrote:
>
>> The fact remains that even GCC extensions to C can't deal with
>> endianness. I'd like to have such an extension though.
>
> It would be nice. And useful. It would also be nice if the compiler
> could deal w
On Mon, 12 Feb 2007, Sergei Organov wrote:
> The fact remains that even GCC extensions to C can't deal with
> endianness. I'd like to have such an extension though.
It would be nice. And useful. It would also be nice if the compiler
could deal with unaligned data automatically.
Bear in mind t
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Sergei Organov wrote:
>
>> Alan Stern <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, 8 Feb 2007, Sergei Organov wrote:
>> >
>> >> IMHO aligned(N) should be used in portable code only to *increase*
>> >> alignment (this effectively excludes
On Fri, 9 Feb 2007, Sergei Organov wrote:
> Alan Stern <[EMAIL PROTECTED]> writes:
>
> > On Thu, 8 Feb 2007, Sergei Organov wrote:
> >
> >> IMHO aligned(N) should be used in portable code only to *increase*
> >> alignment (this effectively excludes usage of 'packed'), and then the
> >> alignment
Alan Stern <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Sergei Organov wrote:
>
>> IMHO aligned(N) should be used in portable code only to *increase*
>> alignment (this effectively excludes usage of 'packed'), and then the
>> alignment won't affect the low-level operations, that automatically
Alan Stern <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Sergei Organov wrote:
>
>> IMHO aligned(N) should be used in portable code only to *increase*
>> alignment (this effectively excludes usage of 'packed'), and then the
>> alignment won't affect the low-level operations, that automatically
On Thu, 8 Feb 2007, Sergei Organov wrote:
> IMHO aligned(N) should be used in portable code only to *increase*
> alignment (this effectively excludes usage of 'packed'), and then the
> alignment won't affect the low-level operations, that automatically
> answers your question. Simple?
If you don'
Alan Stern <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Sergei Organov wrote:
>
>> Unfortunately I can't have the correct type for this field in C (it
>> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
>> can't get type-safety here anyway. Declaring this field __le16 is IMH
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 8. Februar 2007 16:41 schrieb Sergei Organov:
>> > If you do that, le16 is just as valid, especially if declared
>> > unaligned.
>>
>> I don't think so:
>>
>> 1. 'unsigned char', be it used in the form of 'u8' or not, has neither
>> al
On Thu, 8 Feb 2007, Sergei Organov wrote:
> Unfortunately I can't have the correct type for this field in C (it
> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
> poor attempt as it creates an illusion
Am Donnerstag, 8. Februar 2007 16:41 schrieb Sergei Organov:
> > If you do that, le16 is just as valid, especially if declared
> > unaligned.
>
> I don't think so:
>
> 1. 'unsigned char', be it used in the form of 'u8' or not, has neither
> alignment nor endianness problems, while le16 has bot
Oliver Neukum <[EMAIL PROTECTED]> writes:
>> Unfortunately I can't have the correct type for this field in C (it
>> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
>> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
>> poor attempt as it creates an illusi
> Unfortunately I can't have the correct type for this field in C (it
> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
> poor attempt as it creates an illusion of type safety when in fact there
> is no
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 18:31 schrieb Pete Zaitcev:
>> On Wed, 7 Feb 2007 14:39:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> > Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>>
>> > > static inline unsigned usb_get_uint16(__u
Am Mittwoch, 7. Februar 2007 23:45 schrieb Pete Zaitcev:
> On Wed, 7 Feb 2007 21:26:36 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > It would not, if le16_to_cpu took a pointer to u8. But as it is,
> > > functions are quite different.
> >
> > That's what casts are for. However, why do y
On Wed, 7 Feb 2007 21:26:36 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > It would not, if le16_to_cpu took a pointer to u8. But as it is,
> > functions are quite different.
>
> That's what casts are for. However, why do you have no type information
> in the first place? Untyped data is ris
On Wed, 7 Feb 2007, Oliver Neukum wrote:
> > I have often thought exactly the same thing. It seems so natural to
> > combine unaligned reads and writes with byte-reordering. I even brought
> > up the issue on LKML: Why shouldn't there be architecture-dependent
> > versions of
> >
> > get
Am Mittwoch, 7. Februar 2007 18:31 schrieb Pete Zaitcev:
> On Wed, 7 Feb 2007 14:39:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>
> > > static inline unsigned usb_get_uint16(__u8 const *p)
> > > {
> > > return p[0] | (p[
Am Mittwoch, 7. Februar 2007 19:47 schrieb Alan Stern:
> On Wed, 7 Feb 2007, Sergei Organov wrote:
>
> > In fact if there were macro/function similar to get_unaligned(), but
> > converting from little-/big-endian to native, say, get_unaligned_le(),
> > I'd use it:
>
> ...
>
> > Unfortunately th
Am Mittwoch, 7. Februar 2007 19:23 schrieb David Brownell:
> On Wednesday 07 February 2007 4:25 am, Oliver Neukum wrote:
>
> > 1. Disallow any padding
> > 2. Assume the structure may be in unaligned memory
> >
> > Issue number #1 is usually handled by the USB specification.
>
> Key word "usually
David Brownell <[EMAIL PROTECTED]> writes:
> On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote:
>> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
>> wrote:
>>
>> > [btw, I truly have little idea about which are those specific costs,
>> > out of professional cur
On Wed, 7 Feb 2007, Sergei Organov wrote:
> In fact if there were macro/function similar to get_unaligned(), but
> converting from little-/big-endian to native, say, get_unaligned_le(),
> I'd use it:
...
> Unfortunately there is no such macro, or did I miss it?
I have often thought exactly the
On Wednesday 07 February 2007 4:25 am, Oliver Neukum wrote:
> 1. Disallow any padding
> 2. Assume the structure may be in unaligned memory
>
> Issue number #1 is usually handled by the USB specification.
Key word "usually"; they haven't AFAIK promised to do so.
> #2 is not. Therefore packed da
Pete Zaitcev <[EMAIL PROTECTED]> writes:
> On Wed, 7 Feb 2007 14:39:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>
>> > static inline unsigned usb_get_uint16(__u8 const *p)
>> > {
>> > return p[0] | (p[1] << 8);
>> > }
>
On Wed, 7 Feb 2007 14:39:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
> > static inline unsigned usb_get_uint16(__u8 const *p)
> > {
> > return p[0] | (p[1] << 8);
> > }
>
> It makes little sense to reinvent le16_to_cpu(
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 15:04 schrieb Sergei Organov:
>> Unfortunately le16_to_cpu() is not exactly what's needed here, and if
>> I re-implement the above in terms of it:
>
> The issues of endianness and alignment are orthogonal. If you
> face both d
Am Mittwoch, 7. Februar 2007 15:04 schrieb Sergei Organov:
> Unfortunately le16_to_cpu() is not exactly what's needed here, and if
> I re-implement the above in terms of it:
The issues of endianness and alignment are orthogonal. If you
face both do:
x = le16_to_cpu(get_unaligned(p));
Don't reinv
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>
>> struct some_descriptor descr;
>> ...
>> read_from_wire(&descr, sizeof(descr));
>> do_something_with_values(usb_get_uint16(descr->foo), bar);
>> ...
>> usb_set_uint16(descr->foo, 2
Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
> struct some_descriptor descr;
> ...
> read_from_wire(&descr, sizeof(descr));
> do_something_with_values(usb_get_uint16(descr->foo), bar);
> ...
> usb_set_uint16(descr->foo, 2385);
>
> where:
>
> static inline unsigned
Inaky Perez-Gonzalez <[EMAIL PROTECTED]> writes:
[...]
> Here is my point: it's way easier and more maintenable to do
>
> struct some_descriptor {
> __le16 foo;
> __u8 bar;
> } __attribute__((packed));
> ...
> struct some_descriptor descr;
>
Am Mittwoch, 7. Februar 2007 08:00 schrieb David Brownell:
> > In scope of (1) i can't understand: structs are padded implicitly,
> > member access is coded explicitly.
>
> But the struct declarations in question are not memory layouts.
>
> They're "on-the-wire" protocol structures, where the com
Am Dienstag, 6. Februar 2007 23:48 schrieb Pete Zaitcev:
> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
> wrote:
>
> > [btw, I truly have little idea about which are those specific costs,
> > out of professional curiosity, got any pointers?]
>
> http://www.digital
On Tuesday 06 February 2007 5:58 pm, Oleg Verych wrote:
>
> Would you clarify "non aligned access issue" on well known platforms
> (*x86-*). I see on gcc's output, that they are not carry much about it:
X86 has hardware logic to handle misaligned access directly.
Which is why GCC output doesn't p
> From: David Brownell
> Newsgroups: gmane.linux.usb.devel
> Subject: Re: PATCH: usb: descriptor structures have to be packed
> Date: Tue, 6 Feb 2007 16:02:27 -0800
Hallo.
> On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote:
>> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL
On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote:
> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
> wrote:
>
> > [btw, I truly have little idea about which are those specific costs,
> > out of professional curiosity, got any pointers?]
>
> http://www.digital
On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
wrote:
> [btw, I truly have little idea about which are those specific costs,
> out of professional curiosity, got any pointers?]
http://www.digitalvampire.org/blog/articles/2006/07/31/why-you-shouldnt-use-__attribute__
On Tuesday 06 February 2007 1:08 pm, Inaky Perez-Gonzalez wrote:
> On Friday 02 February 2007 19:05, you wrote:
> > The code should have used sizes such as
> > USB_DT_CONFIG_SIZE instead of sizeof().
>
> I have a problem with that, and is maintenance. Is not that I don't like
> DT_CONFIG_SIZE
On Friday 02 February 2007 7:05 pm, Pete Zaitcev wrote:
> On Fri, 2 Feb 2007 17:32:24 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
> wrote:
>
> > usb: descriptor structures have to be packed
>
> > Many of the Wireless USB decriptors added to usb_ch9.h don't have the
> > __attribute__((packed)
On Friday 02 February 2007 19:05, you wrote:
> On Fri, 2 Feb 2007 17:32:24 -0800, Inaky Perez-Gonzalez
<[EMAIL PROTECTED]> wrote:
> > usb: descriptor structures have to be packed
> >
> > Many of the Wireless USB decriptors added to usb_ch9.h don't have the
> > __attribute__((packed)) tag, and thus
On Fri, 2 Feb 2007 17:32:24 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
wrote:
> usb: descriptor structures have to be packed
> Many of the Wireless USB decriptors added to usb_ch9.h don't have the
> __attribute__((packed)) tag, and thus, they don't reflect the wire
> size. This patch fixes
usb: descriptor structures have to be packed
Many of the Wireless USB decriptors added to usb_ch9.h don't have the
__attribute__((packed)) tag, and thus, they don't reflect the wire
size. This patch fixes that.
Signed-off-by: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
usb_ch9.h | 20
41 matches
Mail list logo
