All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.