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

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

[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.


diff -Nru a/drivers/char/mem.c b/drivers/char/mem.c
--- a/drivers/char/mem.c	Mon Dec 22 16:02:08 2003
+++ b/drivers/char/mem.c	Mon Dec 22 16:02:08 2003
@@ -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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Mon, Dec 22, 2003 at 04:26:09PM -0800, Greg KH wrote:
> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 08:15, Christoph Hellwig wrote:

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 10:31, Rob Love wrote:

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 10:31:56AM -0500, Rob Love wrote:
> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 11:39, Christoph Hellwig wrote:

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Greg KH]

On Tue, Dec 23, 2003 at 01:15:23PM +0000, Christoph Hellwig wrote:
> On Mon, Dec 22, 2003 at 04:26:09PM -0800, Greg KH wrote:
> > 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 10:01:27AM -0800, Greg KH wrote:
> 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?

> 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..)

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 02:19:43PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:
> 
> > 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[viro]

On Tue, Dec 23, 2003 at 02:19:43PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:
> 
> > 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:22, Christoph Hellwig wrote:

> 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... 

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:24, viro@parcelfarce.linux.theplanet.co.uk
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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Jeff Garzik]

On Tue, Dec 23, 2003 at 02:25:56PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:22, Christoph Hellwig wrote:
> 
> > 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:42, Jeff Garzik wrote:

> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[Stephan Maciej]

On Tuesday 23 December 2003 17:39, Christoph Hellwig wrote:
> 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] add sysfs mem device support [2/4]

[viro]

On Tue, Dec 23, 2003 at 09:00:04PM +0100, Stephan Maciej wrote:
> On Tuesday 23 December 2003 17:39, Christoph Hellwig wrote:
> > 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_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[PATCH] some sysfs patches for 2.6.0 [0/4]

[Greg KH]

Here are 4 sysfs related patches for 2.6.0.  They do the following:

  - fix an oops in sysfs when a kobject has been unregistered before
    it's child has.  An example of this is the oops that happens in
    2.6.0 whenever a usb-serial device is removed that has a port open
    by a user (almost all Pilot devices do this by virtue of the
    protocol...)


  - add sysfs support to the following char drivers:
  	- mem devices (/dev/null and friends)
	- misc devices (/dev/psaux and other odd devices)
	- vc devices

Please apply these to 2.6.0 or your -mm tree depending on how
comfortable you are with them.

thanks,

greg k-h
	

[PATCH] fix sysfs oops [1/4]

[Greg KH]

This fixes an oops when a kobject is unregistered before it's child is.
The usb-serial devices show this bug very easily (yank out a device
while its port is opened...)

Patch was originally written by Mike Gorse <mgorse@mgorse.dhs.org>


diff -Nru a/fs/sysfs/dir.c b/fs/sysfs/dir.c
--- a/fs/sysfs/dir.c	Mon Dec 22 16:02:07 2003
+++ b/fs/sysfs/dir.c	Mon Dec 22 16:02:07 2003
@@ -83,7 +83,8 @@
 	struct dentry * parent = dget(d->d_parent);
 	down(&parent->d_inode->i_sem);
 	d_delete(d);
-	simple_rmdir(parent->d_inode,d);
+	if (d->d_inode)
+		simple_rmdir(parent->d_inode,d);
 
 	pr_debug(" o %s removing done (%d)\n",d->d_name.name,
 		 atomic_read(&d->d_count));

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

[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.


diff -Nru a/drivers/char/mem.c b/drivers/char/mem.c
--- a/drivers/char/mem.c	Mon Dec 22 16:02:08 2003
+++ b/drivers/char/mem.c	Mon Dec 22 16:02:08 2003
@@ -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);
 	}

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Mon, Dec 22, 2003 at 04:26:09PM -0800, Greg KH wrote:
> 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..

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 08:15, Christoph Hellwig wrote:

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 10:31, Rob Love wrote:

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 10:31:56AM -0500, Rob Love wrote:
> 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.

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 11:39, Christoph Hellwig wrote:

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[Stephan Maciej]

On Tuesday 23 December 2003 17:39, Christoph Hellwig wrote:
> 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

Re: [PATCH] add sysfs mem device support [2/4]

[viro]

On Tue, Dec 23, 2003 at 09:00:04PM +0100, Stephan Maciej wrote:
> On Tuesday 23 December 2003 17:39, Christoph Hellwig wrote:
> > 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.

Re: [PATCH] add sysfs mem device support [2/4]

[Andreas Jellinghaus]

On Tue, 23 Dec 2003 16:47:44 +0000, Christoph Hellwig wrote:
> I disagree. For fully static devices like the mem devices the udev
> indirection is completely superflous.

If sysfs does not contain data on mem devices, we will need makedev.

devfs did replace makedev. until udev can create all devices,
it would need to re-introduce makedev.

Andreas

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Thu, Dec 25, 2003 at 06:48:51PM +0100, Andreas Jellinghaus wrote:
> On Tue, 23 Dec 2003 16:47:44 +0000, Christoph Hellwig wrote:
> > I disagree. For fully static devices like the mem devices the udev
> > indirection is completely superflous.
> 
> If sysfs does not contain data on mem devices, we will need makedev.
> 
> devfs did replace makedev. until udev can create all devices,
> it would need to re-introduce makedev.

So what?

Re: [PATCH] add sysfs mem device support [2/4]

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Thu, 2003-12-25 at 20:45, Christoph Hellwig wrote:
> On Thu, Dec 25, 2003 at 06:48:51PM +0100, Andreas Jellinghaus wrote:
> > On Tue, 23 Dec 2003 16:47:44 +0000, Christoph Hellwig wrote:
> > > I disagree. For fully static devices like the mem devices the udev
> > > indirection is completely superflous.
> > 
> > If sysfs does not contain data on mem devices, we will need makedev.
> > 
> > devfs did replace makedev. until udev can create all devices,
> > it would need to re-introduce makedev.
> 
> So what?
> 

So maybe suggest an solution rather than shooting one down all the
time (which do seem logical, and is only apposed by one person currently
- namely you =).

I currently run a system with Greg's patches + udev, and all the devices
are generated via udev and a modified version of Robert's initscript
(running much earlier), with only alsa's nodes generated via another
script as it is not sysfs-ified yet.  So basically the initramfs idea
is fully plausible if initramfs will get there (or I get time to have
a look). 


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] add sysfs mem device support [2/4]

[Martin J. Bligh]

>> > On Tue, 23 Dec 2003 16:47:44 +0000, Christoph Hellwig wrote:
>> > > I disagree. For fully static devices like the mem devices the udev
>> > > indirection is completely superflous.
>> > 
>> > If sysfs does not contain data on mem devices, we will need makedev.
>> > 
>> > devfs did replace makedev. until udev can create all devices,
>> > it would need to re-introduce makedev.
>> 
>> So what?
>> 
> 
> So maybe suggest an solution rather than shooting one down all the
> time (which do seem logical, and is only apposed by one person currently
> - namely you =).

Nah, most of us just trust Christoph to fight the good fight for us ;-)

I for one certainly agree with him that for static stuff, we don't need 
(or want) udev. For inherently hotplug stuff like USB cameras, or large 
SCSI raid arrays, it's nice, but not for basic things like mem devices 
and the disk devices I'm booting from - it's just added complexity.

If it works as is, don't screw with it.

M.

Re: [PATCH] add sysfs mem device support [2/4]

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Thu, 2003-12-25 at 22:57, Martin J. Bligh wrote:
> >> > On Tue, 23 Dec 2003 16:47:44 +0000, Christoph Hellwig wrote:
> >> > > I disagree. For fully static devices like the mem devices the udev
> >> > > indirection is completely superflous.
> >> > 
> >> > If sysfs does not contain data on mem devices, we will need makedev.
> >> > 
> >> > devfs did replace makedev. until udev can create all devices,
> >> > it would need to re-introduce makedev.
> >> 
> >> So what?
> >> 
> > 
> > So maybe suggest an solution rather than shooting one down all the
> > time (which do seem logical, and is only apposed by one person currently
> > - namely you =).
> 
> Nah, most of us just trust Christoph to fight the good fight for us ;-)
> 

heh =)

> I for one certainly agree with him that for static stuff, we don't need 
> (or want) udev. For inherently hotplug stuff like USB cameras, or large 
> SCSI raid arrays, it's nice, but not for basic things like mem devices 
> and the disk devices I'm booting from - it's just added complexity.
> 

Well, its inclusion do not mean you have to use it - you have to
physically walk all the classes in /sys to get udev to create the nodes,
as they are already there when booted.  And as the code is only a few
lines for each device, it is not much overhead to get:

1) a full sysfs tree of all physical and 'virtual' (?) devices.

2) Optional feature to generate /dev with one simple script for those
   that want it, which should be the less complex option at initramfs
   time.

> If it works as is, don't screw with it.
> 

With an already populated /dev, sure :/


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Thu, Dec 25, 2003 at 09:41:28PM +0200, Martin Schlemmer wrote:
> So maybe suggest an solution rather than shooting one down all the
> time (which do seem logical, and is only apposed by one person currently
> - namely you =).

My suggestion is to just use MAKEDEV asis for devices that are static
like the memdevices.  Dynamic solutions do not buy us anything for those.

Re: [PATCH] add sysfs mem device support [2/4]

[Tomasz Torcz]

On Fri, Dec 26, 2003 at 04:19:49PM +0000, Christoph Hellwig wrote:
> On Thu, Dec 25, 2003 at 09:41:28PM +0200, Martin Schlemmer wrote:
> > So maybe suggest an solution rather than shooting one down all the
> > time (which do seem logical, and is only apposed by one person currently
> > - namely you =).
> 
> My suggestion is to just use MAKEDEV asis for devices that are static
> like the memdevices.  Dynamic solutions do not buy us anything for those.

 They do buy when using tmpfs for /dev.

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu@irc.-nie.spam-.pl   one blends softly casual into the other. 

Re: [PATCH] add sysfs mem device support [2/4]

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Fri, 2003-12-26 at 18:54, Tomasz Torcz wrote:
> On Fri, Dec 26, 2003 at 04:19:49PM +0000, Christoph Hellwig wrote:
> > On Thu, Dec 25, 2003 at 09:41:28PM +0200, Martin Schlemmer wrote:
> > > So maybe suggest an solution rather than shooting one down all the
> > > time (which do seem logical, and is only apposed by one person currently
> > > - namely you =).
> > 
> > My suggestion is to just use MAKEDEV asis for devices that are static
> > like the memdevices.  Dynamic solutions do not buy us anything for those.
> 
>  They do buy when using tmpfs for /dev.

And it will anyhow require a full evaluation of MAKEDEV (debian's one
anyhow), as it really put a lot of extra crap in.  With Greg's patches I
only need to worry about /dev/core, /dev/std{in,out,err} and alsa.  The
question is now also how do you 'qualify' an device to have sysfs
support.  Sure some is static like /dev/null, but over here /dev/hda is
pretty static as well =)


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] add sysfs mem device support [2/4]

[Greg KH]

On Tue, Dec 23, 2003 at 01:15:23PM +0000, Christoph Hellwig wrote:
> On Mon, Dec 22, 2003 at 04:26:09PM -0800, Greg KH wrote:
> > 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

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 10:01:27AM -0800, Greg KH wrote:
> 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?

> 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..)

> 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?

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[Christoph Hellwig]

On Tue, Dec 23, 2003 at 02:19:43PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:
> 
> > 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.

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:22, Christoph Hellwig wrote:

> 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... 

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[Jeff Garzik]

On Tue, Dec 23, 2003 at 02:25:56PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:22, Christoph Hellwig wrote:
> 
> > 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

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:42, Jeff Garzik wrote:

> 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

Re: [PATCH] add sysfs mem device support [2/4]

[viro]

On Tue, Dec 23, 2003 at 02:19:43PM -0500, Rob Love wrote:
> On Tue, 2003-12-23 at 14:16, Christoph Hellwig wrote:
> 
> > 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.

Re: [PATCH] add sysfs mem device support [2/4]

[Rob Love]

On Tue, 2003-12-23 at 14:24, viro@parcelfarce.linux.theplanet.co.uk
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