[lkml]   [2011]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 2/7] include/linux: add headers for drivers/zio
    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

     \ /
      Last update: 2011-11-26 22:47    [W:0.023 / U:8.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site