linux-kernel - Re: [RFC PATCH 2/7] include/linux: add headers for drivers/zio

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]

Date:	Sat, 26 Nov 2011 12:02:16 -0800
From:	Greg KH <greg@...ah.com>
To:	Alessandro Rubini <rubini@...dd.com>
Cc:	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	federico.vaga@...il.com, dcobas@...n.ch, siglesia@...n.ch,
	manohar.vanga@...n.ch
Subject: Re: [RFC PATCH 2/7] include/linux: add headers for drivers/zio

On Sat, Nov 26, 2011 at 06:30:31PM +0100, Alessandro Rubini wrote:
> +/*
> + * We use the same functions to deal with attributes, but the structures
> + * we act on may be different (dev, cset, channel). Thus, all structures
> + * begin with the type identifier, and zio_obj_head is used in container_of
> + */

Because you are using container_of, you don't have to have the structure
at the beginning of the structure it is included in, right?

> +enum zio_object_type {
> +	ZNONE = 0,	/* reserved for non zio object */
> +	ZDEV, ZCSET, ZCHAN,
> +	ZTRIG, ZTI,	/* trigger and trigger instance */
> +	ZBUF, ZBI,	/* buffer and buffer instance */
> +};
> +
> +/* zio_obj_head is for internal use only, as explained above */
> +struct zio_obj_head {
> +	struct kobject		kobj;
> +	enum zio_object_type	zobj_type;
> +	char			name[ZIO_NAME_LEN];
> +};
> +#define to_zio_head(_kobj) container_of(_kobj, struct zio_obj_head, kobj)
> +#define to_zio_dev(_kobj) container_of(_kobj, struct zio_device, head.kobj)
> +#define to_zio_cset(_kobj) container_of(_kobj, struct zio_cset, head.kobj)
> +#define to_zio_chan(_kobj) container_of(_kobj, struct zio_channel, head.kobj)

Why are you using a "raw" kobject and not 'struct device' instead?  If
you use a kobject, you loose all of the device tree information that a
real struct device provides to userspace, and can only cause confusion
in the long run.

This also will provide you the "type" and name that you are needing
here, as well as lots of other good things (properly formatted logging
messages, uevents, etc.)

Please consider moving to that instead.

thanks,

greg k-h
--
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/