lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xa1tvbsfmuxj.fsf@mina86.com>
Date:	Thu, 05 Jun 2014 13:56:24 +0200
From:	Michal Nazarewicz <mina86@...a86.com>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	'Felipe Balbi' <balbi@...com>
Cc:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] tools: ffs-test: convert to new descriptor format fixing compilation error

On Thu, Jun 05 2014, Krzysztof Opasiak <k.opasiak@...sung.com> wrote:
> I would suggest adding a suitable structure as you described in
> previous discussion[1]. Writing first 3 fields in each userspace
> program doesn't look quite good. Using:
>
> #ifndef USE_LEGACY_DESC_HEAD
> struct {
> 	struct usb_functionfs_desc_head2 header;
> 	__le32 fs_count
> 	(... and rest according to flags ...)
> } __attribute__((packed)) header;
> #else ...
>
> Would be shorter, more flexible and user friendly. Moreover it gives
> less places for mistake (writing fields in wrong order).

For ffs-test with USE_LEGACY_DESC_HEAD support it would be longer.
Compare:

----------- >8 ---------------------------------------------------------
static const struct {
	struct {
		__le32 magic;
		__le32 length;
#ifndef USE_LEGACY_DESC_HEAD
		__le32 flags;
#endif
		__le32 fs_count;
		__le32 hs_count;
	} __attribute__((packed)) header;
	/* … */
} __attribute__((packed)) descriptors = {
	.header = {
#ifdef USE_LEGACY_DESC_HEAD
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
#else
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
		.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
				     FUNCTIONFS_HAS_HS_DESC),
#endif
		.length = cpu_to_le32(sizeof descriptors),
		.fs_count = 3,
		.hs_count = 3,
	},
	/* … */
};
----------- >8 ---------------------------------------------------------

with

----------- >8 ---------------------------------------------------------
static const struct {
#ifdef USE_LEGACY_DESC_HEAD
	struct usb_functionfs_descs_head header;
#else
	struct usb_functionfs_descs_head2 header;
	__le32 fs_count;
	__le32 hs_count;
#endif
	/* … */
} __attribute__((packed)) descriptors = {
#ifndef USE_LEGACY_DESC_HEAD
	.fs_count = 3,
	.hs_count = 3,
	.header = {
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
		.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
				     FUNCTIONFS_HAS_HS_DESC),
#else
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
		.fs_count = 3,
		.hs_count = 3,
#endif
		.length = cpu_to_le32(sizeof descriptors),
	},
	/* … */
};
----------- >8 ---------------------------------------------------------

or with

----------- >8 ---------------------------------------------------------
static const struct {
#ifdef USE_LEGACY_DESC_HEAD
	struct usb_functionfs_descs_head header;
#else
	struct {
		struct usb_functionfs_descs_head2 header;
		__le32 fs_count;
		__le32 hs_count;
	} header;
#endif
	/* … */
} __attribute__((packed)) descriptors = {
	.header = {
#ifdef USE_LEGACY_DESC_HEAD
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
		.length = cpu_to_le32(sizeof descriptors),
#else
		.header = {
			.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
			.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
					     FUNCTIONFS_HAS_HS_DESC),
			.length = cpu_to_le32(sizeof descriptors),
		},
#endif
		.fs_count = 3,
		.hs_count = 3,
	},
	/* … */
};
----------- >8 ---------------------------------------------------------

The second one uses an unreadable hack to match length of the first one
and the third one is two lines longer.  On top of that, the second and
third produce different structures, use more complicated preprocessing
directives, and repeat value of fs_count and hs_count twice.

Without legacy support, it would indeed be shorter (by two lines), but
would lead to awkward structures:

----------- >8 ---------------------------------------------------------
struct {
	struct usb_functionfs_descs_head2 header;
	/* Why aren't the two below fields inside of a header? */
	__le32 fs_count;  
	__le32 hs_count;
};

struct {
	struct {
		/* Why is there a header.header field? */
		struct usb_functionfs_descs_head2 header;
		__le32 fs_count;  
		__le32 hs_count;
	};
};
----------- >8 ---------------------------------------------------------

And I don't see how it would be more flexible.  If anything, it would be
less.

I understand, and share, your sentiment, but I don't think adding 
usb_functionfs_descs_head2 structure with magic, flags and length would
improve the situation.

Something I thought about shortly was:

----------- >8 ---------------------------------------------------------
#define USB_FFS_DESCS_HEAD(_flags) struct {				\
		__le32 magic, length, flags;				\
		__le32 data[!!(_flags & FUNCTIONFS_HAS_FS_DESC) +	\
			    !!(_flags & FUNCTIONFS_HAS_HS_DESC) +	\
			    !!(_flags & FUNCTIONFS_HAS_SS_DESC)];	\
	} __attribute__((packed))

#define USB_FFS_DESCS_HEAD_INIT(_flags, length, ...) {			\
		.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),	\
		.flags = cpu_to_le32(flags),				\
		.langth = cpu_to_le32(length),				\
		.data = { __VA_ARGS__ }					\
	}

static const struct {
	USB_FFS_DESCS_HEAD(FUNCTIONFS_HAS_FS_DESC | FUNCTIONFS_HAS_HS_DESC),
	/* … */
} __attribute__((packed)) descriptors = {
	USB_FFS_DESCS_HEAD_INIT(FUNCTIONFS_HAS_FS_DESC | FUNCTIONFS_HAS_HS_DESC,
				sizeof(descriptors), 3, 3),
	/* … */
};
----------- >8 ---------------------------------------------------------

But whether this is nicer is arguable as well.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ