RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Endianness of particular fields?
@ 2018-02-22 18:13 Guy Harris
       [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Guy Harris @ 2018-02-22 18:13 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw

	http://www.radiotap.org

says

	Important Radiotap Characteristics

		...

	* Data is specified in little endian byte-order, all data fields including the it_version, it_len and it_present fields in the radiotap header are to be specified in little endian byte-order. This wiki has adopted the Linux convention of using __le64, __le32 and __le16 for 64-, 32- and 16-bit little endian quantities.

However, for example

	http://www.radiotap.org/fields/dB%20TX%20attenuation.html

says:

	Structure
		u16

rather than __le{anything}.

I presume the *intent* is that data in particular fields always be little-endian.  Part of the problem here is that the Linux convention, used to describe the comment headers specifies endianness rather than signedness (presumably everything is unsigned), and the convention used for particular fields specifies signedness rather than endianness (presumably everything is little-endian).

Should the site use the {u,s}{64,32,16,8} convention uniformly, and say "all multi-byte fields in all the headers and the fields are little-endian", to make it a little clearer that fields, as well as headers, are little-endian?  (Or, alternatively, say "{u,s}_le_64", "{u,s}_le_32", etc., or something similar with fewer underscores as desired?)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Endianness of particular fields?
       [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2018-02-22 20:19   ` Johannes Berg
       [not found]     ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2018-02-22 20:19 UTC (permalink / raw)
  To: Guy Harris, radiotap-sUITvd46vNxg9hUCZPvPmw

On Thu, 2018-02-22 at 10:13 -0800, Guy Harris wrote:
> 	http://www.radiotap.org
> 
> says
> 
> 	Important Radiotap Characteristics
> 
> 		...
> 
> 	* Data is specified in little endian byte-order, all data
> fields including the it_version, it_len and it_present fields in the
> radiotap header are to be specified in little endian byte-order. This
> wiki has adopted the Linux convention of using __le64, __le32 and
> __le16 for 64-, 32- and 16-bit little endian quantities.
> 
> However, for example
> 
> 	http://www.radiotap.org/fields/dB%20TX%20attenuation.html
> 
> says:
> 
> 	Structure
> 		u16
> 
> rather than __le{anything}.

Oops.

> I presume the *intent* is that data in particular fields always be
> little-endian.  

Yes.

> Part of the problem here is that the Linux convention, used to
> describe the comment headers specifies endianness rather than
> signedness (presumably everything is unsigned), and the convention
> used for particular fields specifies signedness rather than
> endianness (presumably everything is little-endian).

Yeah.

> Should the site use the {u,s}{64,32,16,8} convention uniformly, and
> say "all multi-byte fields in all the headers and the fields are
> little-endian", to make it a little clearer that fields, as well as
> headers, are little-endian?  (Or, alternatively, say "{u,s}_le_64",
> "{u,s}_le_32", etc., or something similar with fewer underscores as
> desired?)

I think we should just use {u,s}{64,32,16,8} and drop the whole __le
thing.

I'd say we should just remove the wording about adopting the Linux
convention. We'd never use __be16 or such anyway.

johannes

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Endianness of particular fields?
       [not found]     ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2018-06-18 13:58       ` Johannes Berg
  0 siblings, 0 replies; 3+ messages in thread
From: Johannes Berg @ 2018-06-18 13:58 UTC (permalink / raw)
  To: Guy Harris, radiotap-sUITvd46vNxg9hUCZPvPmw

On Thu, 2018-02-22 at 21:19 +0100, Johannes Berg wrote:
> 
> I think we should just use {u,s}{64,32,16,8} and drop the whole __le
> thing.
> 
> I'd say we should just remove the wording about adopting the Linux
> convention. We'd never use __be16 or such anyway.

I removed it now, not sure why I forgot earlier. Sorry about that.

johannes

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-22 18:13 Endianness of particular fields? Guy Harris
     [not found] ` <83A13AAE-2089-4ED9-97D9-EDEBDD911955-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2018-02-22 20:19   ` Johannes Berg
     [not found]     ` <1519330795.2637.16.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-06-18 13:58       ` Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git