Skip to contentSkip to conversation

add sysfs mem device support [2/4]

PATCH In review Greg KH 6 participants 17 messages Dec 23, 2003 Char and misc drivers

lore
Share & tools
lore

Greg KH

author
#0 lore raw

PATCH 1/1 add sysfs mem device support [2/4]

This adds /sys/class/mem which enables all mem char devices to show up properly in udev.

Has been posted to linux-kernel every so often since last July, and acked by a number of other kernel developers.

drivers/char/mem.c +32 -1
diff -Nru a/drivers/char/mem.c b/drivers/char/mem.c
@@ -24,6 +24,7 @@
 #include <linux/smp_lock.h>
 #include <linux/devfs_fs_kernel.h>
 #include <linux/ptrace.h>
+#include <linux/device.h>
 
 #include <asm/uaccess.h>
 #include <asm/io.h>

@@ -657,7 +658,7 @@
 	.open		= memory_open,	/* just a selector for the real open */
 };
 
-static const struct {
+static const struct mem_dev {
 	unsigned int		minor;
 	char			*name;
 	umode_t			mode;

@@ -676,6 +677,23 @@
 	{11,"kmsg",    S_IRUGO | S_IWUSR,           &kmsg_fops},
 };
 
+static void release_mem_dev(struct class_device *class_dev)
+{
+	kfree(class_dev);
+}
+
+static struct class mem_class = {
+	.name		= "mem",
+	.release	= &release_mem_dev,
+};
+
+static ssize_t show_dev(struct class_device *class_dev, char *buf)
+{
+	struct mem_dev *mem_dev = class_get_devdata(class_dev);
+	return print_dev_t(buf, MKDEV(MEM_MAJOR, mem_dev->minor));
+}
+static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
+
 static int __init chr_dev_init(void)
 {
 	int i;

@@ -683,7 +701,20 @@
 	if (register_chrdev(MEM_MAJOR,"mem",&memory_fops))
 		printk("unable to get major %d for memory devs\n", MEM_MAJOR);
 
+	class_register(&mem_class);
 	for (i = 0; i < ARRAY_SIZE(devlist); i++) {
+		struct class_device *class_dev;
+
+		class_dev = kmalloc(sizeof(*class_dev), GFP_KERNEL);
+		if (class_dev) {
+			memset(class_dev, 0x00, sizeof(*class_dev));
+			class_dev->class = &mem_class;
+			strncpy(class_dev->class_id, devlist[i].name, BUS_ID_SIZE);
+			class_set_devdata(class_dev, (void *)&devlist[i]);
+			if (!class_device_register(class_dev));
+				class_device_create_file(class_dev, &class_device_attr_dev);
+		}
+
 		devfs_mk_cdev(MKDEV(MEM_MAJOR, devlist[i].minor),
 				S_IFCHR | devlist[i].mode, devlist[i].name);
 	}

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#1 lore raw
Quoted 5 lines · Greg KH

This adds /sys/class/mem which enables all mem char devices to show up properly in udev.

Has been posted to linux-kernel every so often since last July, and acked by a number of other kernel developers.

This is pointless. The original point of sysfs and co was to present the physical device tree, where these devices absolutely fit into. Why are you doing this at all? Creating thse through udev doesn't make sense as they need to be present anyway..

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#2 lore raw
In reply to Greg KH
Quoted 4 lines · Christoph Hellwig

This is pointless. The original point of sysfs and co was to present the physical device tree, where these devices absolutely fit into. Why are you doing this at all? Creating thse through udev doesn't make sense as they need to be present anyway..

Creating them via udev is the point.

Remember, the ultimate goal is to have udev in initramfs during early boot, and all of these vital devices will be created.

For udev to work as intended, all devices on the system must be represented in sysfs.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#3 lore raw
In reply to Greg KH
Quoted 7 lines · Rob Love

Creating them via udev is the point.

Remember, the ultimate goal is to have udev in initramfs during early boot, and all of these vital devices will be created.

For udev to work as intended, all devices on the system must be represented in sysfs.

Oh, I think I get your point, now.

The devices actually do not need to be in sysfs, but we do need to generate a hotplug event for them.

Nonetheless, I think it makes sense to also put them in sysfs. I think of sysfs has a "device tree" and not necessarily a "physical device tree".

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#4 lore raw
In reply to Greg KH
Quoted 4 lines · Rob Love

Creating them via udev is the point.

Remember, the ultimate goal is to have udev in initramfs during early boot, and all of these vital devices will be created.

I disagree. For fully static devices like the mem devices the udev indirection is completely superflous.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#5 lore raw
In reply to Greg KH
Quoted 2 lines · Christoph Hellwig

I disagree. For fully static devices like the mem devices the udev indirection is completely superflous.

I see your point, so I really do not want to argue, but here is my rationale for why everything should be done seamlessly via udev:

In a nutshell, we want a single, clean, automatic solution to device naming. If some "static" devices are hard coded, we introduce a special case. Why do that? Why have special cases when udev can seamlessly manage the whole thing? Say we decide to remove /dev/foo in the kernel
- that should be reflected in udev simply by way of it no longer being created on boot.

That is my thoughts. I dislike special casing. And without it, udev can seamlessly handle everything, automatically.

But I _do_ see your point. It is silly to generate a hotplug event for a static device on every boot, etc. etc. But I think the cleanliness of not special casing certain devices in the udev solution is worth it.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

author
#6 lore raw
In reply to Greg KH
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Greg KH

This adds /sys/class/mem which enables all mem char devices to show up properly in udev.

Has been posted to linux-kernel every so often since last July, and acked by a number of other kernel developers.

This is pointless. The original point of sysfs and co was to present the physical device tree, where these devices absolutely fit into.

No. The point of sysfs and co was to present the physical _and_ logical device tree. Mem devices are devices. This patch also provides a place to move the /proc/sys/kernel/random files out of proc and into sysfs.

In order for tools like udev to work, we must export all char devices that are registered with the kernel. We can't do this at register_chrdev() time, as that only allocates a whole major. And people haven't converted over to using register_chrdev_region only when they really have a device present yet.

With devices such as the misc devices, we only care about the devices we really have in the system at that time. It also gives us the ability to show the linkage between the logical device, and the physical one (for misc devices.)

Now yeah, I can see that some people might think it's a bit overkill to move the mem devices here, but why not? They are logical devices in the system, and as stated above, it provides a place within sysfs to move user modifiable attributes of these devices out of /proc (as they do not pertain to anything related to processes.)

I do agree that the duplication of the code should be fixed, and I'll go do that right now (I should have realized that after cut-and-pasting that logic the third time, sorry about that.) If that is done, the overhead to support mem devices will drop to a very tiny ammount.

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#7 lore raw
In reply to Greg KH
Quoted 5 lines · Greg KH

In order for tools like udev to work, we must export all char devices that are registered with the kernel. We can't do this at register_chrdev() time, as that only allocates a whole major. And people haven't converted over to using register_chrdev_region only when they really have a device present yet.

Then add a random-junk-not-converted-yet devclass instead of duplicting the adhoc code everywhere. Still I'd vote for going to the proper interface directly instead of adding bad hacks all over the places. If that means waiting for 2.7 to open, so what?

Quoted 4 lines

With devices such as the misc devices, we only care about the devices we really have in the system at that time. It also gives us the ability to show the linkage between the logical device, and the physical one (for misc devices.)

But why is it tied to the obsoltet misc mechanism (or the obsolete usb major thing, etc..)

Quoted 5 lines

Now yeah, I can see that some people might think it's a bit overkill to move the mem devices here, but why not? They are logical devices in the system, and as stated above, it provides a place within sysfs to move user modifiable attributes of these devices out of /proc (as they do not pertain to anything related to processes.)

What user-modifiable attributes?

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#8 lore raw
In reply to Greg KH
Quoted 1 line · Christoph Hellwig

What user-modifiable attributes?

See /proc/sys/kernel/random

Junk like that should be ripped from procfs and put in sysfs corresponding to its device file.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#9 lore raw
In reply to Greg KH
Quoted 8 lines · Rob Love
Quoted 1 line · Christoph Hellwig

What user-modifiable attributes?

See /proc/sys/kernel/random

Junk like that should be ripped from procfs and put in sysfs corresponding to its device file.

Well, it's not just for /dev/random but also for all in-kernel cosumers of random numbers, so doing this as a sysctl makes quite a lot of sense.

Whether sysctl should be mached into procfs or sysfs or rather be it's own fs is an entirely different question. Interface-wise the latter would make most sense.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#10 lore raw
In reply to Greg KH
Quoted 8 lines · Rob Love
Quoted 1 line · Christoph Hellwig

What user-modifiable attributes?

See /proc/sys/kernel/random

Junk like that should be ripped from procfs and put in sysfs corresponding to its device file.

Junk like that is called "sysctl" and is a part of userland ABI.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#11 lore raw
In reply to Greg KH
Quoted 2 lines · Christoph Hellwig

Well, it's not just for /dev/random but also for all in-kernel cosumers of random numbers, so doing this as a sysctl makes quite a lot of sense.

And /dev/random is the user-space abstraction representing the random number generator...

Quoted 3 lines

Whether sysctl should be mached into procfs or sysfs or rather be it's own fs is an entirely different question. Interface-wise the latter would make most sense.

What to do with sysctl's in the long run is a good question.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#12 lore raw
In reply to Greg KH
Quoted 1 line · On Tue, 2003-12-23 at 14:24, [email protected] wrote:

Junk like that is called "sysctl" and is a part of userland ABI.

Right. And I agree 100% that we need to respect that ABI.

Long-term, though, we need to think about a saner home for sysctl's than procfs. hch's suggestion of giving them their own filesystem is a good idea to start with.

Right now, though, I think it is a shining exemplar of sanity to associate device-related attributes with the device's directory in sysfs.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#13 lore raw
In reply to Greg KH
Quoted 7 lines · Rob Love
Quoted 2 lines · Christoph Hellwig

Well, it's not just for /dev/random but also for all in-kernel cosumers of random numbers, so doing this as a sysctl makes quite a lot of sense.

And /dev/random is the user-space abstraction representing the random number generator...

Not precisely. If your userspace program can obtain random numbers in some other way, it should... /dev/random shouldn't be considered as the canonical source for random bits for the entire machine.

Jeff

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#14 lore raw
In reply to Greg KH
Quoted 3 lines · Jeff Garzik

Not precisely. If your userspace program can obtain random numbers in some other way, it should... /dev/random shouldn't be considered as the canonical source for random bits for the entire machine.

s/the random number generator/the kernel's random number generator (random.c)/

E.g., my point was that the device file was the user-space representation of the kernel rng, so associating the kernel rng attributes with the device file made sense. I did not mean to imply it was the be-all and end-all of rng's on the machine.

Rob Love

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#15 lore raw
In reply to Greg KH
Quoted 2 lines · Christoph Hellwig

I disagree. For fully static devices like the mem devices the udev indirection is completely superflous.

It can be considered superfluous, but OTOH I think when creating a clean interface it's desirable to keep the number of exceptional items as small as possible, IOW zero.

Stephan

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#16 lore raw
In reply to Greg KH
Quoted 7 lines · Stephan Maciej
Quoted 2 lines · Christoph Hellwig

I disagree. For fully static devices like the mem devices the udev indirection is completely superflous.

It can be considered superfluous, but OTOH I think when creating a clean interface it's desirable to keep the number of exceptional items as small as possible, IOW zero.

Trying to get rid of them for the sake of getting rid of them can very well make interface (a) not clean and (b) harder to cleanup up later.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel