Re: [RFC PATCH try2] sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor - Kernel

This is a discussion on Re: [RFC PATCH try2] sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor - Kernel ; On Fri, 2008-04-18 at 12:33 -0700, Dan Williams wrote: > --- a/Documentation/filesystems/sysfs.txt > +++ b/Documentation/filesystems/sysfs.txt > @@ -248,6 +248,7 @@ The top level sysfs directory looks like: > block/ > bus/ > class/ > +dev/ > devices/ Lots of stuff ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: [RFC PATCH try2] sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor

  1. Re: [RFC PATCH try2] sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor

    On Fri, 2008-04-18 at 12:33 -0700, Dan Williams wrote:
    > --- a/Documentation/filesystems/sysfs.txt
    > +++ b/Documentation/filesystems/sysfs.txt
    > @@ -248,6 +248,7 @@ The top level sysfs directory looks like:
    > block/
    > bus/
    > class/
    > +dev/
    > devices/


    Lots of stuff in that file is pretty damn wrong, and at it should
    probably just be deleted. Care to put this new documentation into:
    Documentation/ABI/

    > --- a/drivers/base/class.c
    > +++ b/drivers/base/class.c
    > @@ -134,6 +134,18 @@ static void remove_class_attrs(struct class *cls)
    > }
    > }
    >
    > +static void class_set_dev_kobj(struct class *class)
    > +{
    > +#ifdef CONFIG_BLOCK
    > + if (class == &block_class) {
    > + class->dev_kobj = block_kobj;
    > + return;
    > + }
    > +#endif
    > +
    > + class->dev_kobj = char_kobj;
    > +}
    > +


    If you do:
    struct class block_class = {
    .name = "block",
    .dev_kobj = block_kobj,
    }

    in:
    block/genhd.c
    and put:
    if (!class->dev_kobj)
    class->dev_kobj = char_kobj;
    in:
    class_register()
    we can get rid of all this logic and the BLOCK #ifdef, right?

    Also:
    class_create(THIS_MODULE, "usb_device");
    in:
    drivers/usb/core/devio.c
    should probably clear the dev_kobj after registration, and we can get
    rid of the "parent has the same dev_t" logic?

    > --- a/include/linux/device.h
    > +++ b/include/linux/device.h
    > @@ -192,6 +192,7 @@ struct class {
    > struct class_attribute *class_attrs;
    > struct class_device_attribute *class_dev_attrs;
    > struct device_attribute *dev_attrs;
    > + struct kobject *dev_kobj;
    >
    > int (*uevent)(struct class_device *dev, struct kobj_uevent_env *env);
    > int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
    > @@ -204,6 +205,8 @@ struct class {
    > int (*resume)(struct device *dev);
    > };
    >
    > +extern struct kobject *block_kobj;
    > +extern struct kobject *char_kobj;


    These global symbols should get better names, to make it obvious that
    it's "only" the /sys/dev/ stuff.


    Thanks,
    Kay

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [RFC PATCH try2] sysfs: add /sys/dev/{char,block} to lookupsysfs path by major:minor

    On Fri, 2008-04-18 at 17:41 -0700, Dan Williams wrote:
    > On Fri, 2008-04-18 at 13:53 -0700, Kay Sievers wrote:
    > > On Fri, 2008-04-18 at 12:33 -0700, Dan Williams wrote:
    > > Also:
    > > class_create(THIS_MODULE, "usb_device");
    > > in:
    > > drivers/usb/core/devio.c
    > > should probably clear the dev_kobj after registration, and we can get
    > > rid of the "parent has the same dev_t" logic?

    >
    > Greg had suspicions that there might be more cases like
    > usb_classdev_class, so I added a dev_warn() to help debug those.


    Yeah, it's Linux, you never know. But there are no currently known
    other subsystem doing this. It is perfectly ´╗┐valid scenario though, to
    have that, if someone comes up with a better idea as some current stuff
    is doing it, and we need to deprecate something, and have duplicated
    dev_t entries in sysfs for a while.

    > I don't mind taking your word for it that there are no more such cases,
    > but maybe the warning should stay in for a few -rc releases?


    I think, we can remove that, as it will print a warning for the
    "duplicate entry" anyway.

    Looks all fine now from my point of view.

    Thanks,
    Kay

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread