From: Federico Vaga <federico.vaga@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Alessandro Rubini <rubini@gnudd.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
dcobas@cern.ch, siglesia@cern.ch, manohar.vanga@cern.ch
Subject: Re: [RFC PATCH 2/7] include/linux: add headers for drivers/zio
Date: Sat, 26 Nov 2011 22:46:48 +0100 [thread overview]
Message-ID: <1491684.cGqJrVR8Lo@harkonnen> (raw)
In-Reply-To: <20111126200216.GC11421@kroah.com>
In data sabato 26 novembre 2011 12:02:16, Greg KH ha scritto:
> 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?
Different structures have similar features and we use zio_obj_head->zobj_type to
identify the correct container_of to apply. Sometimes we use the head only, so
we delay container_of later.
> > +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?
The device way was experimented and we can move in that direction. I also
tried a mixed solution with device and kobject, because not all the zio objects
can be device.
I decided to use the kobject way because it was an easier and flexible solution
for a fast development.
> If you use a kobject, you loose all of the device tree information that a
> real struct device provides to userspace,
You mean the device sysfs tree? Acctually we don't need that information
> and can only cause confusion in the long run.
I think it can be confusing to declare a device what is not a device, for
example: buffer, trigger, channel-set (maybe in some
sense can be a device) and channel
> 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.)
If you refer to device_type, I think it is too complex for our purpose (also
tried during the device "experiment"), we only need to recognize a zio object,
we don't need al the stuff within device_type.
You are right, device is full of great things and the migration to device is
always a point of discussion, but actually kobject meet well with our needs.
> Please consider moving to that instead.
We can re-evaluate and better explain the choice if kobj is still the
preferrable one
> thanks,
>
> greg k-h
--
Federico Vaga
next prev parent reply other threads:[~2011-11-26 21:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-26 17:30 [RFC PATCH 0/7] Introducing ZIO, a new I/O framework Alessandro Rubini
2011-11-26 17:30 ` [RFC PATCH 1/7] Documentation: add docs for drivers/zio Alessandro Rubini
2011-11-26 20:00 ` Greg KH
2011-11-26 21:48 ` Federico Vaga
2011-11-26 22:16 ` Jonathan Cameron
2011-11-26 22:53 ` Alessandro Rubini
2011-12-06 5:12 ` Randy Dunlap
2011-11-26 17:30 ` [RFC PATCH 2/7] include/linux: add headers " Alessandro Rubini
2011-11-26 20:02 ` Greg KH
2011-11-26 21:46 ` Federico Vaga [this message]
2011-11-27 9:32 ` Greg KH
2011-11-28 14:56 ` Federico Vaga
2011-11-28 14:56 ` Federico Vaga
2011-11-30 6:21 ` Greg KH
2011-11-26 17:30 ` [RFC PATCH 3/7] drivers/zio: core files for the ZIO input/output Alessandro Rubini
2011-11-26 20:03 ` Greg KH
2011-11-26 22:58 ` Federico Vaga
2011-11-27 9:33 ` Greg KH
2011-11-28 14:59 ` Federico Vaga
2011-11-28 14:59 ` Federico Vaga
2011-11-26 17:30 ` [RFC PATCH 4/7] drivers/zio: add triggers and buffers Alessandro Rubini
2011-11-26 17:31 ` [RFC PATCH 5/7] drivers/zio: add the zio-zero device driver Alessandro Rubini
2011-11-26 17:31 ` [RFC PATCH 6/7] drivers/zio: add user-space tool zio-dump Alessandro Rubini
2011-11-26 17:31 ` [RFC PATCH 7/7] zio: insert in Kbuild so it is actually compiled Alessandro Rubini
2011-11-26 18:09 ` [RFC PATCH 0/7] Introducing ZIO, a new I/O framework Lars-Peter Clausen
2011-11-26 19:11 ` Alessandro Rubini
2011-12-01 21:41 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1491684.cGqJrVR8Lo@harkonnen \
--to=federico.vaga@gmail.com \
--cc=dcobas@cern.ch \
--cc=greg@kroah.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manohar.vanga@cern.ch \
--cc=rubini@gnudd.com \
--cc=siglesia@cern.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.