Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
On Fri, Feb 04, 2005 at 10:16:36PM -0800, Greg KH wrote:
> On Wed, Feb 02, 2005 at 01:48:12AM +0100, Kay Sievers wrote:
> > On Tue, Feb 01, 2005 at 02:56:25PM -0800, Greg KH wrote:
> > > Hm, that class_simple interface is looking like the way we should move
> > > toward, as it's "simple" to use, instead of the more complex class code.
> > > I'll have to look at migrating more code to use it over time, or move
> > > that interface back into the class code itself...
> >
> > Nice idea! What about keeping a list of devices belonging to a
> > specific class in an own list in 'struct class' and maintaining that list
> > with class_device_add(), class_device_del()?
>
> What would that help out with?
>
> > A class driver may use that list to keep track of its own devices if
> > wanted and class_simple would not be needed anymore as everything
> > would be available in the core.
>
> I must be tired, but I don't see how class_simple could be dropped if
> that was done. Care to explain it with pseudo-code or something?
Sure, here is a patch for illustration. The needed class_simple logic
is moved to the core. It uses the class's children list to keep track of
the created devices. The tty and the input layer are changed to use the
new interface.
With this change, a driver still has the convenient class support without
the need to care about allocation and release functions. But it uses the
same data structures like a full featured class implementation.
Thanks,
Kay
= drivers/base/class.c 1.58 vs edited =
--- 1.58/drivers/base/class.c 2005-02-05 19:35:12 +01:00
+++ edited/drivers/base/class.c 2005-02-05 22:23:45 +01:00
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "base.h"
#define to_class_attr(_attr) container_of(_attr, struct class_attribute, attr)
@@ -161,6 +162,52 @@ void class_unregister(struct class * cls
subsystem_unregister(&cls->subsys);
}
+static void class_create_release(struct class *cls)
+{
+ kfree(cls);
+}
+
+static void class_device_create_release(struct class_device *class_dev)
+{
+ kfree(class_dev);
+}
+
+struct class *class_create(char *name)
+{
+ struct class *cls;
+ int retval;
+
+ cls = kmalloc(sizeof(struct class), GFP_KERNEL);
+ if (!cls) {
+ retval = -ENOMEM;
+ goto error;
+ }
+ memset(cls, 0x00, sizeof(struct class));
+
+ cls->name = name;
+ cls->class_release = class_create_release;
+ cls->release = class_device_create_release;
+
+ retval = class_register(cls);
+ if (retval)
+ goto error;
+
+ return cls;
+
+error:
+ kfree(cls);
+ return ERR_PTR(retval);
+}
+EXPORT_SYMBOL_GPL(class_create);
+
+void class_destroy(struct class *cls)
+{
+ if ((cls == NULL) || (IS_ERR(cls)))
+ return;
+
+ class_unregister(cls);
+}
+EXPORT_SYMBOL_GPL(class_destroy);
/* Class Device Stuff */
@@ -468,6 +515,42 @@ int class_device_register(struct class_d
return class_device_add(class_dev);
}
+struct class_device *class_device_create(struct class *cls, dev_t devt,
+struct device *device, char *fmt, ...)
+{
+ va_list args;
+ struct class_device *class_dev;
+ int retval;
+
+ if (cls == NULL || IS_ERR(cls))
+ return ERR_PTR(-ENODEV);
+
+ class_dev = kmalloc(sizeof(struct class_device), GFP_KERNEL);
+ if (!class_dev) {
+ retval = -ENOMEM;
+ goto error;
+ }
+ memset(class_dev, 0x00, sizeof(struct class_device));
+
+ class_dev->devt = devt;
+ class_dev->dev = device;
+ class_dev->class = cls;
+
+ va_start(args, fmt);
+ vsnprintf(class_dev->class_id, BUS_ID_SIZE, fmt, args);
+ va_end(args);
+ retval = class_device_register(class_dev);
+ if (retval)
+ goto error;
+
+ return 0;
+
+error:
+ kfree(class_dev);
+ return ERR_PTR(retval);
+}
+EXPORT_SYMBOL_GPL(class_device_create);
+
void class_device_del(struct class_device *class_dev)
{
struct class * parent = class_dev->class;
@@ -499,6 +582,25 @@ void class_device_unregister(struct clas
class_device_del(class_dev);
class_device_put(class_dev);
}
+
+void class_device_destroy(struct class *cls, dev_t devt)
+{
+ struct class_device *class_dev = NULL;
+ struct class_device *class_dev_tmp;
+
+ down_write(&cls->subsys.rwsem);
+ list_for_each_entry(class_dev_tmp, &cls->children, node) {
+ if (class_dev_tmp->devt == devt) {
+ class_dev = class_dev_tmp;
+ break;
+ }
+ }
+ up_write(&cls->subsys.rwsem);
+
+ if (class_dev)
+ class_device_unregister(class_dev);
+}
+EXPORT_SYMBOL_GPL(class_device_destroy);
int class_device_rename(struct class_device *class_dev, char *new_name)
{
= drivers/char/
Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
On Wed, Feb 02, 2005 at 01:48:12AM +0100, Kay Sievers wrote: > On Tue, Feb 01, 2005 at 02:56:25PM -0800, Greg KH wrote: > > Hm, that class_simple interface is looking like the way we should move > > toward, as it's "simple" to use, instead of the more complex class code. > > I'll have to look at migrating more code to use it over time, or move > > that interface back into the class code itself... > > Nice idea! What about keeping a list of devices belonging to a > specific class in an own list in 'struct class' and maintaining that list > with class_device_add(), class_device_del()? What would that help out with? > A class driver may use that list to keep track of its own devices if > wanted and class_simple would not be needed anymore as everything > would be available in the core. I must be tired, but I don't see how class_simple could be dropped if that was done. Care to explain it with pseudo-code or something? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
On Tue, Feb 01, 2005 at 02:56:25PM -0800, Greg KH wrote: > On Sun, Jan 23, 2005 at 05:19:11AM +0100, Kay Sievers wrote: > > This patch sequence moves the creation of the sysfs "dev" file of the class > > devices into the driver core. The struct class_device contains a dev_t > > value now. If set, the driver core will create the "dev" file containing > > the major/minor numbers automatically. > > > > The MAJOR/MINOR values are also exported to the hotplug environment. This > > makes it easy for userspace, especially udev to know if it should wait for > > a "dev" file to create a device node or if it can just ignore the event. > > We currently carry a compiled in blacklist around for that reason. > > > > It would also be possible to run some "tiny udev" while sysfs is not > > available - just by reading the hotplug call or the netlink-uevent. > > This is great, thanks for doing this. I've applied all of these patches > to my trees, and they'll show up in the next -mm release. Fine, thanks. > Hm, that class_simple interface is looking like the way we should move > toward, as it's "simple" to use, instead of the more complex class code. > I'll have to look at migrating more code to use it over time, or move > that interface back into the class code itself... Nice idea! What about keeping a list of devices belonging to a specific class in an own list in 'struct class' and maintaining that list with class_device_add(), class_device_del()? A class driver may use that list to keep track of its own devices if wanted and class_simple would not be needed anymore as everything would be available in the core. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
On Sun, Jan 23, 2005 at 05:19:11AM +0100, Kay Sievers wrote: > This patch sequence moves the creation of the sysfs "dev" file of the class > devices into the driver core. The struct class_device contains a dev_t > value now. If set, the driver core will create the "dev" file containing > the major/minor numbers automatically. > > The MAJOR/MINOR values are also exported to the hotplug environment. This > makes it easy for userspace, especially udev to know if it should wait for > a "dev" file to create a device node or if it can just ignore the event. > We currently carry a compiled in blacklist around for that reason. > > It would also be possible to run some "tiny udev" while sysfs is not > available - just by reading the hotplug call or the netlink-uevent. This is great, thanks for doing this. I've applied all of these patches to my trees, and they'll show up in the next -mm release. Hm, that class_simple interface is looking like the way we should move toward, as it's "simple" to use, instead of the more complex class code. I'll have to look at migrating more code to use it over time, or move that interface back into the class code itself... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
This patch sequence moves the creation of the sysfs "dev" file of the class devices into the driver core. The struct class_device contains a dev_t value now. If set, the driver core will create the "dev" file containing the major/minor numbers automatically. The MAJOR/MINOR values are also exported to the hotplug environment. This makes it easy for userspace, especially udev to know if it should wait for a "dev" file to create a device node or if it can just ignore the event. We currently carry a compiled in blacklist around for that reason. It would also be possible to run some "tiny udev" while sysfs is not available - just by reading the hotplug call or the netlink-uevent. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
