Skip to contentSkip to conversation

driver core: Add the ability to unbind drivers to devices from userspace

PATCH In review Jon Smirl 9 participants 49 messages Jul 25, 2005 – Aug 21, 2005 Driver core

lore
Share & tools
lore

Jon Smirl

author
#0 lore raw

PATCH 1/1 driver core: Add the ability to unbind drivers to devices from userspace

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

Signature · 2 lines
Jon Smirl
[email protected]
drivers/base/bus.c +4 -2
@@ -137,9 +137,11 @@ decl_subsys(bus, &ktype_bus, NULL);
 static int driver_helper(struct device *dev, void *data)
 {
        const char *name = data;
-
-       if (strcmp(name, dev->bus_id) == 0)
+printk(KERN_ERR "unbind: %s %s\n", name, dev->bus_id);
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0) {
+printk(KERN_ERR "match\n");
                return 1;
+       }
        return 0;
 }
#1 lore raw
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

Signature · 1 line
Dmitry
author
#2 lore raw
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

- if (strcmp(name, dev->bus_id) == 0)
+ if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

I work in this area and I couldn't figure out why it was silently not working. I had to add the printk to the source before I could figure it out. I suspect most people are going to have this trouble.

This has also made me realize that I have created other places in the kernel where my sysfs attribute code is not going to work correctly. Maybe we should adjust the sysfs driver to strip leading and trailing white space before passing the string on.

Signature · 2 lines
Jon Smirl
[email protected]
#3 lore raw
Quoted 14 lines · Jon Smirl
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

Review

Quoted 2 lines
(quoted diff) +1 -1
-       if (strcmp(name, dev->bus_id) == 0)
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

This will produce "interesting results" if you have both "blah-1" and "blah-10" devices on the bus.

Signature · 1 line
Dmitry
author
#4 lore raw
Quoted 14 lines · Dmitry Torokhov
Quoted 13 lines · Jon Smirl
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

Quoted 6 lines

Review

Quoted 3 lines
(quoted diff) +1 -1
-       if (strcmp(name, dev->bus_id) == 0)
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

This will produce "interesting results" if you have both "blah-1" and "blah-10" devices on the bus.

Then the better solution is to fix the generic attribute set code to strip leading and trailing white space.

Signature · 2 lines
Jon Smirl
[email protected]
#5 lore raw
Quoted 15 lines · Jon Smirl
Quoted 14 lines · Dmitry Torokhov
Quoted 13 lines · Jon Smirl
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

Quoted 6 lines
Quoted 6 lines

Review

Quoted 3 lines
(quoted diff) +1 -1
-       if (strcmp(name, dev->bus_id) == 0)
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

This will produce "interesting results" if you have both "blah-1" and "blah-10" devices on the bus.

Yes, not a good thing for USB devices specifically.

Quoted 2 lines

Then the better solution is to fix the generic attribute set code to strip leading and trailing white space.

No, that might break other things as we have not been doing this from day one. I'd rather just change these two places, if it's that big of a deal. It was documented (in a lwn.net article) and the changelog entry, that you should use "echo -n".

thanks,

greg k-h

author
#6 lore raw
Quoted 25 lines · Greg KH
Quoted 15 lines · Jon Smirl
Quoted 14 lines · Dmitry Torokhov
Quoted 13 lines · Jon Smirl
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

Quoted 6 lines
Quoted 6 lines

Review

Quoted 3 lines
(quoted diff) +1 -1
-       if (strcmp(name, dev->bus_id) == 0)
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

This will produce "interesting results" if you have both "blah-1" and "blah-10" devices on the bus.

Yes, not a good thing for USB devices specifically.

Quoted 7 lines
Quoted 2 lines

Then the better solution is to fix the generic attribute set code to strip leading and trailing white space.

No, that might break other things as we have not been doing this from day one. I'd rather just change these two places, if it's that big of a deal. It was documented (in a lwn.net article) and the changelog entry, that you should use "echo -n".

I didn't realize that echo was adding the CR, I thought that it always appeared on the end of a sysfs attribute set. So now I have to go add white space stripping to a dozen fbdev/drm sysfs attribute implementations. Given that the param is const I may have to allocate new buffers and copy. I also wonder how many other people have made the same mistake.

Are you sure it would break other things? These are supposed to be text attributes, not binary ones.

Signature · 2 lines
Jon Smirl
[email protected]
#7 lore raw
Quoted 34 lines · Jon Smirl
Quoted 25 lines · Greg KH
Quoted 15 lines · Jon Smirl
Quoted 14 lines · Dmitry Torokhov
Quoted 13 lines · Jon Smirl
Quoted 8 lines · Dmitry Torokhov
Quoted 5 lines · Jon Smirl

I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution.

"echo -n" should take care of this problem I think.

That will work around it but I think we should fix it. Changing to strncmp() fixes most cases.

Quoted 6 lines
Quoted 6 lines

Review

Quoted 3 lines
(quoted diff) +1 -1
-       if (strcmp(name, dev->bus_id) == 0)
+       if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0)

This will produce "interesting results" if you have both "blah-1" and "blah-10" devices on the bus.

Yes, not a good thing for USB devices specifically.

Quoted 7 lines
Quoted 2 lines

Then the better solution is to fix the generic attribute set code to strip leading and trailing white space.

No, that might break other things as we have not been doing this from day one. I'd rather just change these two places, if it's that big of a deal. It was documented (in a lwn.net article) and the changelog entry, that you should use "echo -n".

Quoted 6 lines

I didn't realize that echo was adding the CR, I thought that it always appeared on the end of a sysfs attribute set. So now I have to go add white space stripping to a dozen fbdev/drm sysfs attribute implementations. Given that the param is const I may have to allocate new buffers and copy. I also wonder how many other people have made the same mistake.

Nah, just zero out that \n character :)

Quoted 2 lines

Are you sure it would break other things? These are supposed to be text attributes, not binary ones.

I agree, I don't know what would break. Care to make a patch so we could find out?

thanks,

greg k-h

author
#8 lore raw
Quoted 9 lines · Greg KH
Quoted 6 lines · Jon Smirl

I didn't realize that echo was adding the CR, I thought that it always appeared on the end of a sysfs attribute set. So now I have to go add white space stripping to a dozen fbdev/drm sysfs attribute implementations. Given that the param is const I may have to allocate new buffers and copy. I also wonder how many other people have made the same mistake.

Nah, just zero out that \n character :)

The input buffer is "const char * buf". I will have to override the const to zero it out.

Quoted 6 lines
Quoted 3 lines

Are you sure it would break other things? These are supposed to be text attributes, not binary ones.

I agree, I don't know what would break. Care to make a patch so we could find out?

I'll put one together to trim leading/trailing white space from the buffer before it is passed into the attribute functions. Now that I think about this I believe the attributes should have always had the leading/trailing white space removed. If we don't do it in the sysfs code then every driver has to do it.

Signature · 2 lines
Jon Smirl
[email protected]
#9 lore raw
Quoted 9 lines · Jon Smirl
Quoted 8 lines · Greg KH
Quoted 6 lines · Jon Smirl

I didn't realize that echo was adding the CR, I thought that it always appeared on the end of a sysfs attribute set. So now I have to go add white space stripping to a dozen fbdev/drm sysfs attribute implementations. Given that the param is const I may have to allocate new buffers and copy. I also wonder how many other people have made the same mistake.

Quoted 4 lines
Quoted 1 line

Nah, just zero out that \n character :)

The input buffer is "const char * buf". I will have to override the const to zero it out.

Yeah, hence the ":)" above.

Quoted 11 lines
Quoted 5 lines
Quoted 2 lines

Are you sure it would break other things? These are supposed to be text attributes, not binary ones.

I agree, I don't know what would break. Care to make a patch so we could find out?

I'll put one together to trim leading/trailing white space from the buffer before it is passed into the attribute functions. Now that I think about this I believe the attributes should have always had the leading/trailing white space removed. If we don't do it in the sysfs code then every driver has to do it.

Ok, sounds good.

thanks,

greg k-h

author
#10 lore raw
Quoted 7 lines · Greg KH
Quoted 5 lines

I'll put one together to trim leading/trailing white space from the buffer before it is passed into the attribute functions. Now that I think about this I believe the attributes should have always had the leading/trailing white space removed. If we don't do it in the sysfs code then every driver has to do it.

Ok, sounds good.

How does this look? This is a count based interface but a lot of attributes don't work unless I add the terminating zero. This interface should be documented: count or zero terminated, white space stripped or not, etc. Are these strings ASCII, UTF8, Unicode?

fs/sysfs/file.c +23 -0
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
  #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
  	struct attribute * attr = to_attr(dentry);
  	struct kobject * kobj = to_kobj(dentry->d_parent);
  	struct sysfs_ops * ops = buffer->ops;
+	char *x, *y, *z;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while( isspace(*x) && (x - buffer->page < count))
+		x++;
+
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
+		while( isspace(*y) && (y - buffer->page < count)) {
+			y++;
+		}
+	}
+	count = z - x;
+
+	/* strip the white space */
+	if (buffer->page != x)
+		memmove(buffer->page, x, count);
+	buffer->page[count] = '\0';
 
  	return ops->store(kobj,attr,buffer->page,count);
 }
Signature · 2 lines
Jon Smirl
[email protected]
#11 lore raw

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 224

Quoted 10 lines · Jon Smirl
fs/sysfs/file.c +10 -0
+	while( isspace(*x) && (x - buffer->page < count))
+		x++;
+
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
+		while( isspace(*y) && (y - buffer->page < count)) {
+			y++;

Can we have consistent space vs. paren placement, pretty please?

Signature · 1 line
Dmitry
author
#12 lore raw
In reply to Jon Smirl

Any comments on this? I'll fix up the whitespace issues if everyone agrees that the code works.

This patch will break all of the fbdev attributes since I was making wrong assumptions. I have another patch ready to fix them after this one goes in.

Quoted 60 lines · Jon Smirl
Quoted 7 lines · Greg KH
Quoted 5 lines

I'll put one together to trim leading/trailing white space from the buffer before it is passed into the attribute functions. Now that I think about this I believe the attributes should have always had the leading/trailing white space removed. If we don't do it in the sysfs code then every driver has to do it.

Ok, sounds good.

How does this look? This is a count based interface but a lot of attributes don't work unless I add the terminating zero. This interface should be documented: count or zero terminated, white space stripped or not, etc. Are these strings ASCII, UTF8, Unicode?

fs/sysfs/file.c +23 -1
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
  #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
        struct attribute * attr = to_attr(dentry);
        struct kobject * kobj = to_kobj(dentry->d_parent);
        struct sysfs_ops * ops = buffer->ops;
+       char *x, *y, *z;
+
+       /* locate leading white space */
+       x = buffer->page;
+       while( isspace(*x) && (x - buffer->page < count))
+               x++;
+
+       /* locate trailng white space */
+       z = y = x;
+       while (y - buffer->page < count) {
+               y++;
+               z = y;
+               while( isspace(*y) && (y - buffer->page < count)) {
+                       y++;
+               }
+       }
+       count = z - x;
+
+       /* strip the white space */
+       if (buffer->page != x)
+               memmove(buffer->page, x, count);
+       buffer->page[count] = '\0';
 
        return ops->store(kobj,attr,buffer->page,count);
 }
 
 
--

Jon Smirl
[email protected]

Signature · 2 lines
Jon Smirl
[email protected]
#13 lore raw
Quoted 2 lines · Jon Smirl

Any comments on this? I'll fix up the whitespace issues if everyone agrees that the code works.

I'll add the patch to my tree and -mm if you clean up the whitespace issues :)

thanks,

greg k-h

author
#14 lore raw

New patch with fixed whitespace.

Signature · 2 lines
Jon Smirl
[email protected]
fs/sysfs/file.c +23 -0
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	char *x, *y, *z;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while (isspace(*x) && (x - buffer->page < count))
+		x++;
+
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
+		while (isspace(*y) && (y - buffer->page < count)) {
+			y++;
+		}
+	}
+	count = z - x;
+
+	/* strip the white space */
+	if (buffer->page != x)
+		memmove(buffer->page, x, count);
+	buffer->page[count] = '\0';
 
 	return ops->store(kobj,attr,buffer->page,count);
 }
#15 lore raw
Quoted 1 line · Jon Smirl

New patch with fixed whitespace.

But no changelog info or signed-off-by line :(

Care to try it again?

thanks,

greg k-h

author
#16 lore raw

Change log and signed off

Signature · 9 lines
Jon Smirl
[email protected]


Remove leading and trailing whitespace when text sysfs attributes are
assigned a value.


Signed-off-by: Jon Smirl <[email protected]>
fs/sysfs/file.c +23 -0
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	char *x, *y, *z;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while (isspace(*x) && (x - buffer->page < count))
+		x++;
+
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
+		while (isspace(*y) && (y - buffer->page < count)) {
+			y++;
+		}
+	}
+	count = z - x;
+
+	/* strip the white space */
+	if (buffer->page != x)
+		memmove(buffer->page, x, count);
+	buffer->page[count] = '\0';
 
 	return ops->store(kobj,attr,buffer->page,count);
 }
#17 lore raw

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 216

Quoted 10 lines · Jon Smirl
fs/sysfs/file.c +6 -0
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	char *x, *y, *z;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while (isspace(*x) && (x - buffer->page < count))
+		x++;

Ok, I can follow this. For example
buffer->page = " foo "

then x = "foo " at the end of that .

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 10 lines
fs/sysfs/file.c +10 -0
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
+		while (isspace(*y) && (y - buffer->page < count)) {
+			y++;
+		}
+	}
+	count = z - x;

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 232

Quoted 5 lines
fs/sysfs/file.c +5 -0
+
+	/* strip the white space */
+	if (buffer->page != x)
+		memmove(buffer->page, x, count);
+	buffer->page[count] = '\0';

Why move the buffer? Why not just pass in a pointer to the start of the "non-whitespace filled" buffer to the store() function?

thanks,

greg k-h

#18 lore raw
Quoted 5 lines · Greg KH
Quoted 5 lines
fs/sysfs/file.c +5 -0
+	/* locate trailng white space */
+	z = y = x;
+	while (y - buffer->page < count) {
+		y++;
+		z = y;
Quoted 8 lines

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 5 lines
fs/sysfs/file.c +5 -0
+		while (isspace(*y) && (y - buffer->page < count)) {
+			y++;
+		}
+	}
+	count = z - x;

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

It looks sane-ish to me, but also more complicated than need be. Why can't you just do something like:

	while (count > 0 && isspace(x[count - 1]))
		count--;

-Mitch

author
#19 lore raw
Quoted 15 lines · Mitchell Blank Jr
Quoted 11 lines · Greg KH

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 10 lines
fs/sysfs/file.c +10 -0
+   /* locate trailng white space */
+   z = y = x;
+   while (y - buffer->page < count) {
+           y++;
+           z = y;
+           while (isspace(*y) && (y - buffer->page < count)) {
+                   y++;
+           }
+   }
+   count = z - x;
Quoted 2 lines

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

Quoted 8 lines

It looks sane-ish to me, but also more complicated than need be. Why can't you just do something like:

        while (count > 0 && isspace(x[count - 1]))
                count--;

-Mitch

Do we need to deal with UTF8 here? I did the forward loop because you can't parse UTF8 backwards. If UTF8 is possible I need to change the pointer inc function.

Signature · 2 lines
Jon Smirl
[email protected]
#20 lore raw

Am Donnerstag, 28. Juli 2005 14:54 schrieb Jon Smirl:

Quoted 22 lines · Mitchell Blank Jr
Quoted 21 lines
Quoted 11 lines · Greg KH

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 10 lines
fs/sysfs/file.c +10 -0
+   /* locate trailng white space */
+   z = y = x;
+   while (y - buffer->page < count) {
+           y++;
+           z = y;
+           while (isspace(*y) && (y - buffer->page < count)) {
+                   y++;
+           }
+   }
+   count = z - x;
Quoted 2 lines

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

It looks sane-ish to me, but also more complicated than need be. Why can't you just do something like:

        while (count > 0 && isspace(x[count - 1]))
                count--;
Quoted 6 lines
Quoted 2 lines

-Mitch

Do we need to deal with UTF8 here? I did the forward loop because you can't parse UTF8 backwards. If UTF8 is possible I need to change the pointer inc function.

This considerations show that having parsing code in kernel space is a questionable idea. Are you absolutely sure that you cannot do with less?

Regards
Oliver

#21 lore raw
In reply to Jon Smirl
Quoted 11 lines · Jon Smirl
Quoted 6 lines · Mitchell Blank Jr

[...]
It looks sane-ish to me, but also more complicated than need be. Why can't you just do something like:

       while (count > 0 && isspace(x[count - 1]))
               count--;

Do we need to deal with UTF8 here? I did the forward loop because you can't parse UTF8 backwards. If UTF8 is possible I need to change the pointer inc function.

I don't think it matters here. Even with UTF8, any char that makes isspace return true, can't be part of a multi-byte char, as every byte in a multi-byte char in UTF8 has the MSB set, i.e., >= 0x80.

Signature · 5 lines
Paulo Marques - www.grupopie.com

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
#22 lore raw
In reply to Jon Smirl
Quoted 3 lines · Jon Smirl

Do we need to deal with UTF8 here? I did the forward loop because you can't parse UTF8 backwards. If UTF8 is possible I need to change the pointer inc function.

As others have mentioned there shouldn't be a UTF8 problem with isspace(). However, even if you wanted to scan going forwards you can do it without the complexity of a nested loop:

	char *real_end;

	for (real_end = x; x - buffer->page < count; x++)
		if (!isspace(*x))
			real_end = x + 1;
	*real_end = '\0';
	// then fix "count"

BTW, my code I posted yesterday is incomplete since I neglected to notice that the "count = z - x" at the end is used to repair "count" damage from both the leading and trailing whitespace stripping. Its actually easier to strip the trailing whitespace first, like:

	while (count > 0 && isspace(buffer->page[count - 1]))
		count--;	/* strip trailing whitespace */
	if (count > 0 && isspace(buffer->page[0])) {
		/*
		 * We have leading whitespace but also at least one
		 * non-whitespace character
		 */
		const char *x = buffer->page;
		do {
			x++;
			count--;
		} while (isspace(*x));
		memmove(buffer->page, x, count);
	}
	buffer->page[count] = '\0';

-Mitch

#23 lore raw
In reply to Jon Smirl
Quoted 22 lines · Jon Smirl
Quoted 21 lines · Mitchell Blank Jr
Quoted 11 lines · Greg KH

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 10 lines
fs/sysfs/file.c +10 -0
+   /* locate trailng white space */
+   z = y = x;
+   while (y - buffer->page < count) {
+           y++;
+           z = y;
+           while (isspace(*y) && (y - buffer->page < count)) {
+                   y++;
+           }
+   }
+   count = z - x;
Quoted 2 lines

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

It looks sane-ish to me, but also more complicated than need be. Why can't you just do something like:

        while (count > 0 && isspace(x[count - 1]))
                count--;
Quoted 6 lines
Quoted 2 lines

-Mitch

Do we need to deal with UTF8 here? I did the forward loop because you can't parse UTF8 backwards. If UTF8 is possible I need to change the pointer inc function.

No, we don't need to handle UTF8. Or if we do, then we better not make a general filter function, as it will be a mess.

thanks,

greg k-h

author
#24 lore raw

New, simplified version of the sysfs whitespace strip patch...

Signature · 5 lines
Jon Smirl
[email protected]

Remove leading and trailing whitespace when text sysfs attribute is set
signed-off-by: Jon Smirl <[email protected]>
fs/sysfs/file.c +16 -1
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,8 +208,22 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	char *x;
 
-	return ops->store(kobj,attr,buffer->page,count);
+	/* locate trailing white space */
+	while ((count > 0) && isspace(buffer->page[count - 1]))
+		count--;
+
+	/* locate leading white space */
+	x = buffer->page;
+	while (isspace(*x) && (x - buffer->page < count))
+		x++;
+	count -= (x - buffer->page);
+
+	/* terminate the string */
+	x[count] = '\0';
+
+	return ops->store(kobj, attr, x, count);
 }
#25 lore raw

Still one nitpick:

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 220

Quoted 2 lines · Jon Smirl
fs/sysfs/file.c +2 -0
+	while (isspace(*x) && (x - buffer->page < count))
+		x++;

I think you can just do:

	if (count > 0)
		while (isspace(*x))
			x++;

If the passed-in string was fully whitespace then the trailing-whitespace stripping would already reduce it to count==0. So as long as you check for that case you can be sure that the while() will stop before x falls off the end of the string.

Other than that it looks fine to me now.

-Mitch

author
#26 lore raw

Even simpler version....

Signature · 5 lines
Jon Smirl
[email protected]

Remove leading and trailing whitespace when text sysfs attribute is set
signed-off-by: Jon Smirl <[email protected]>
fs/sysfs/file.c +17 -1
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,8 +208,23 @@ flush_write_buffer(struct dentry * dentr
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
+	char *x;
 
-	return ops->store(kobj,attr,buffer->page,count);
+	/* locate trailing white space */
+	while ((count > 0) && isspace(buffer->page[count - 1]))
+		count--;
+
+	/* locate leading white space */
+	x = buffer->page;
+	if (count > 0) {
+		while (isspace(*x))
+			x++;
+		count -= (x - buffer->page);
+	}
+	/* terminate the string */
+	x[count] = '\0';
+
+	return ops->store(kobj, attr, x, count);
 }
author
#27 lore raw

Greg, is this ok for your tree now or does it need more work?

Quoted 44 lines · Jon Smirl

Even simpler version....

--
Jon Smirl
[email protected]

Remove leading and trailing whitespace when text sysfs attribute is set

fs/sysfs/file.c +17 -1
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,8 +208,23 @@ flush_write_buffer(struct dentry * dentr
        struct attribute * attr = to_attr(dentry);
        struct kobject * kobj = to_kobj(dentry->d_parent);
        struct sysfs_ops * ops = buffer->ops;
+       char *x;
 
-       return ops->store(kobj,attr,buffer->page,count);
+       /* locate trailing white space */
+       while ((count > 0) && isspace(buffer->page[count - 1]))
+               count--;
+
+       /* locate leading white space */
+       x = buffer->page;
+       if (count > 0) {
+               while (isspace(*x))
+                       x++;
+               count -= (x - buffer->page);
+       }
+       /* terminate the string */
+       x[count] = '\0';
+
+       return ops->store(kobj, attr, x, count);
 }
 
Signature · 2 lines
Jon Smirl
[email protected]
#28 lore raw
Quoted 1 line · Jon Smirl

Greg, is this ok for your tree now or does it need more work?

It's in my queue, will add it to the tree next week. Sorry for the delay, was at OSCON this week...

thanks,

greg k-h

author
#29 lore raw
Quoted 5 lines · Greg KH
Quoted 1 line · Jon Smirl

Greg, is this ok for your tree now or does it need more work?

It's in my queue, will add it to the tree next week. Sorry for the delay, was at OSCON this week...

Glad to see this. After it lands in the tree I'll fix up about ten places where I have attribute processing wrong because of this. Is there some place in the sysfs doc that this can be mentioned?

Another thing that should be cleared up is if the attributes are described by length or zero termination. Right now they get both. I suspect the right answer here is supposed to be by length.

Signature · 2 lines
Jon Smirl
[email protected]
author
#30 lore raw
In reply to Jon Smirl
Quoted 30 lines · Jon Smirl

Even simpler version....

--
Jon Smirl
[email protected]

Remove leading and trailing whitespace when text sysfs attribute is set

fs/sysfs/file.c +5 -1
@@ -6,6 +6,7 @@
 #include <linux/fsnotify.h>
 #include <linux/kobject.h>
 #include <linux/namei.h>
+#include <linux/ctype.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -207,8 +208,23 @@ flush_write_buffer(struct dentry * dentr
        struct attribute * attr = to_attr(dentry);
        struct kobject * kobj = to_kobj(dentry->d_parent);
        struct sysfs_ops * ops = buffer->ops;
+       char *x;
 
-       return ops->store(kobj,attr,buffer->page,count);
+       /* locate trailing white space */
+       while ((count > 0) && isspace(buffer->page[count - 1]))
+               count--;

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 225

Quoted 10 lines
fs/sysfs/file.c +10 -0
+
+       /* locate leading white space */
+       x = buffer->page;
+       if (count > 0) {
+               while (isspace(*x))
+                       x++;
+               count -= (x - buffer->page);
+       }
+       /* terminate the string */
+       x[count] = '\0';

Should we add a check for a NULL string here? It seems not all drivers were prepared to handle a zero length store().

If (count == 0)

      return 0;
Quoted 4 lines
fs/sysfs/file.c +2 -0
+
+       return ops->store(kobj, attr, x, count);
 }
 
Signature · 2 lines
Jon Smirl
[email protected]
#31 lore raw
In reply to Jon Smirl

Am Donnerstag, 28. Juli 2005 21:57 schrieb Jon Smirl:

Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Regards
Oliver

author
#32 lore raw
Quoted 5 lines · Oliver Neukum

Am Donnerstag, 28. Juli 2005 21:57 schrieb Jon Smirl:

Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Quoted 4 lines

Regards
Oliver

Signature · 2 lines
Jon Smirl
[email protected]
#33 lore raw

Am Donnerstag, 28. Juli 2005 23:12 schrieb Jon Smirl:

Quoted 10 lines · Oliver Neukum
Quoted 5 lines

Am Donnerstag, 28. Juli 2005 21:57 schrieb Jon Smirl:

Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Why? If you can do it in user space, do so.

Regards
Oliver

#34 lore raw
In reply to Jon Smirl

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...
Pavel

Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         
author
#35 lore raw
Quoted 7 lines · Pavel Machek

Hi!

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Quoted 6 lines
Quoted 3 lines

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

echo is not the only source of problems. I had some trailing whitespace in a shell script and it took me a couple of hours to discover why the attribute set was failing. I finally had to add debug code to the kernel and reboot to located the problem. Normal users are never going to figure this out.

Binary attributes are for program use, they should not get cleaned up. If you dont want the whitespace cleaning switch to a binary one.

Quoted 5 lines

Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

Signature · 2 lines
Jon Smirl
[email protected]
#36 lore raw

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 12 lines · Pavel Machek
Quoted 11 lines

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Quoted 7 lines
Quoted 2 lines

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

Regards
Oliver

author
#37 lore raw
Quoted 16 lines · Oliver Neukum

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 15 lines · Pavel Machek
Quoted 13 lines

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

Quoted 7 lines
Quoted 4 lines

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

So the average user never needs to change their console mode? Check out /sys/class/graphics/fb/modes and mode.

Quoted 4 lines

Regards
Oliver

Signature · 2 lines
Jon Smirl
[email protected]
#38 lore raw

Am Freitag, 5. August 2005 20:14 schrieb Jon Smirl:

Quoted 22 lines · Oliver Neukum
Quoted 21 lines

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 19 lines · Pavel Machek
Quoted 7 lines

Hi!

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Quoted 6 lines
Quoted 3 lines

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

Quoted 5 lines
Quoted 2 lines

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

So the average user never needs to change their console mode? Check out /sys/class/graphics/fb/modes and mode.

That is what we have helper scripts for.

Regards
Oliver

author
#39 lore raw
Quoted 23 lines · Oliver Neukum

Am Freitag, 5. August 2005 20:14 schrieb Jon Smirl:

Quoted 22 lines · Oliver Neukum
Quoted 21 lines

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 19 lines · Pavel Machek
Quoted 7 lines

Hi!

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Quoted 6 lines
Quoted 3 lines

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

So the average user never needs to change their console mode? Check out /sys/class/graphics/fb/modes and mode.

That is what we have helper scripts for.

If we are going back to needing helper scripts then I should just remove the entire sysfs graphics interface and switch back to using ioctls and a helper app. Of could no one can ever find the helper app or remember how it works. I thought one of the main reasons behind the sysfs interface was to eliminate these helper apps.

Without doing whitespace cleanup there is a 100% probability that this will generate bug reports. I know this for a fact because I am already getting them.

Signature · 2 lines
Jon Smirl
[email protected]
#40 lore raw

Am Freitag, 5. August 2005 20:47 schrieb Jon Smirl:

Quoted 30 lines · Oliver Neukum
Quoted 29 lines

Am Freitag, 5. August 2005 20:14 schrieb Jon Smirl:

Quoted 27 lines · Oliver Neukum
Quoted 16 lines

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 15 lines · Pavel Machek
Quoted 13 lines

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

Quoted 7 lines
Quoted 4 lines

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

So the average user never needs to change their console mode? Check out /sys/class/graphics/fb/modes and mode.

Quoted 7 lines
Quoted 1 line

That is what we have helper scripts for.

If we are going back to needing helper scripts then I should just remove the entire sysfs graphics interface and switch back to using ioctls and a helper app. Of could no one can ever find the helper app or remember how it works. I thought one of the main reasons behind the sysfs interface was to eliminate these helper apps.

The point is that you _can_ do it with echo, not that it is _easy_. Nor is sysfs a solution in any case.

Quoted 3 lines

Without doing whitespace cleanup there is a 100% probability that this will generate bug reports. I know this for a fact because I am already getting them.

Stupid users are not a reason for kernel bloat.

Regards
Oliver

author
#41 lore raw
Quoted 39 lines · Oliver Neukum

Am Freitag, 5. August 2005 20:47 schrieb Jon Smirl:

Quoted 30 lines · Oliver Neukum
Quoted 29 lines

Am Freitag, 5. August 2005 20:14 schrieb Jon Smirl:

Quoted 27 lines · Oliver Neukum
Quoted 16 lines

Am Freitag, 5. August 2005 15:32 schrieb Jon Smirl:

Quoted 15 lines · Pavel Machek
Quoted 13 lines

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

Quoted 7 lines
Quoted 4 lines

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

The average user has no place poking sysfs. Root should know when to use -n, as should shell scripts.

So the average user never needs to change their console mode? Check out /sys/class/graphics/fb/modes and mode.

Quoted 7 lines
Quoted 1 line

That is what we have helper scripts for.

If we are going back to needing helper scripts then I should just remove the entire sysfs graphics interface and switch back to using ioctls and a helper app. Of could no one can ever find the helper app or remember how it works. I thought one of the main reasons behind the sysfs interface was to eliminate these helper apps.

Quoted 8 lines

The point is that you _can_ do it with echo, not that it is _easy_. Nor is sysfs a solution in any case.

Quoted 3 lines

Without doing whitespace cleanup there is a 100% probability that this will generate bug reports. I know this for a fact because I am already getting them.

Stupid users are not a reason for kernel bloat.

You have a very wrapped sense of kernel bloat. This is nine lines of code whose absence is guaranteed to generate a bunch of bug reports. Not having it is also causing various implementers to implement attribute processing differently. Some are stripping white space in their implementations and some are not. If you want to attack kernel bloat there are much more productive areas.

If whitespace cleanup is rejected I believe we should eliminate text based sysfs attributes in general and make them all binary. I'll probably remove the fbdev sysfs interface because I don't want to deal with the bug reports reporting the same problem over and over.

Signature · 2 lines
Jon Smirl
[email protected]
#42 lore raw
Quoted 5 lines
Quoted 2 lines

Stupid users are not a reason for kernel bloat.

You have a very wrapped sense of kernel bloat. This is nine lines of code whose absence is guaranteed to generate a bunch of bug reports.

They are supposed to be present, but not in the kernel.

Quoted 4 lines

Not having it is also causing various implementers to implement attribute processing differently. Some are stripping white space in their implementations and some are not. If you want to attack kernel bloat there are much more productive areas.

If somebody is stripping whitespace in the kernel, find and destroy.

Quoted 4 lines

If whitespace cleanup is rejected I believe we should eliminate text based sysfs attributes in general and make them all binary. I'll probably remove the fbdev sysfs interface because I don't want to deal with the bug reports reporting the same problem over and over.

You are seeing this wrong. The problem is not binary vs. text. If binary were the problem we'd have a generic ioctl tool that takes arguments in any number format you'd want. The problem is untyped data. ASCII-strings without leading or trailing whitespece is a clearly defined datatype. Requiring a tool ensuring this format is met or care is used if other tools are used is perfectly in order. The kernel does not guess what an input is supposed to mean. Anything else is bloat.

Regards
Oliver

#43 lore raw
In reply to Jon Smirl

Hi!

Quoted 13 lines
Quoted 13 lines
Quoted 5 lines

If we are going back to needing helper scripts then I should just remove the entire sysfs graphics interface and switch back to using ioctls and a helper app. Of could no one can ever find the helper app or remember how it works. I thought one of the main reasons behind the sysfs interface was to eliminate these helper apps.

The point is that you _can_ do it with echo, not that it is _easy_. Nor is sysfs a solution in any case.

Quoted 3 lines

Without doing whitespace cleanup there is a 100% probability that this will generate bug reports. I know this for a fact because I am already getting them.

Quoted 7 lines
Quoted 1 line

Stupid users are not a reason for kernel bloat.

You have a very wrapped sense of kernel bloat. This is nine lines of code whose absence is guaranteed to generate a bunch of bug reports. Not having it is also causing various implementers to implement attribute processing differently. Some are stripping white space in their implementations and some are not. If you want to attack kernel

Can you point place where we do strip whitespace in kernel sysfs handlers?
Pavel

Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         
#44 lore raw
In reply to Jon Smirl

Hi!

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Quoted 7 lines
Quoted 2 lines

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

Kernel is not a place to be user friendly. Or do you propose stripping whitespace
for open(), too? File called "foo.txt " certainly *is* going to be confusing, but it should be allowed at kernel level.

Now... echo foo > /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash.

Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         
author
#45 lore raw
Quoted 12 lines · Pavel Machek

Hi!

Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

Could you tell me why you don't just fail the operation if malformed input is supplied?

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

Quoted 7 lines
Quoted 4 lines

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

Kernel is not a place to be user friendly. Or do you propose stripping whitespace
for open(), too? File called "foo.txt " certainly *is* going to be confusing, but it should be allowed at kernel level.

open is not made for human use, it is used by programs and only indirectly by humans. sysfs variables are used by directly humans.

Quoted 3 lines

Now... echo foo > /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash.

It is going to take a lot more code to return an error that a parameter didn't match because of extra white space that it would take to simply remove the whitespace.

Quoted 4 lines

--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

Signature · 2 lines
Jon Smirl
[email protected]
#46 lore raw

Hi!

Quoted 10 lines
Quoted 7 lines
Quoted 4 lines

It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine.

Kernel is not a place to be user friendly. Or do you propose stripping whitespace
for open(), too? File called "foo.txt " certainly *is* going to be confusing, but it should be allowed at kernel level.

open is not made for human use, it is used by programs and only indirectly by humans. sysfs variables are used by directly humans.

Both are kernel interfaces; I can use open() by hand just fine...

Quoted 6 lines
Quoted 2 lines

Now... echo foo > /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash.

It is going to take a lot more code to return an error that a parameter didn't match because of extra white space that it would take to simply remove the whitespace.

I believe we do correctly report errors in write() calls already. Bash not reporting them to the user is different problem.
Pavel

Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address
#47 lore raw
In reply to Pavel Machek
Quoted 7 lines · Pavel Machek

Hi!

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

New, simplified version of the sysfs whitespace strip patch...

Could you tell me why you don't just fail the operation if malformed input is supplied?

Quoted 6 lines
Quoted 3 lines

Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n.

Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel...

Ahhh, this would be so much easier if people just got used to using printf instead of echo when doing text output. =)

Regards: David Weinehall

Signature · 3 lines
 /) David Weinehall <[email protected]> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/
author
#48 lore raw
In reply to Greg KH
Quoted 32 lines · Greg KH

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 216

Quoted 10 lines · Jon Smirl
fs/sysfs/file.c +6 -0
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
      struct attribute * attr = to_attr(dentry);
      struct kobject * kobj = to_kobj(dentry->d_parent);
      struct sysfs_ops * ops = buffer->ops;
+     char *x, *y, *z;
+
+     /* locate leading white space */
+     x = buffer->page;
+     while (isspace(*x) && (x - buffer->page < count))
+             x++;

Ok, I can follow this. For example
buffer->page = " foo "

then x = "foo " at the end of that .

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 227

Quoted 10 lines
fs/sysfs/file.c +10 -0
+     /* locate trailng white space */
+     z = y = x;
+     while (y - buffer->page < count) {
+             y++;
+             z = y;
+             while (isspace(*y) && (y - buffer->page < count)) {
+                     y++;
+             }
+     }
+     count = z - x;

Hm, I _think_ this works, but I need someone else to verify this... Anyone else?

Quoted 8 lines

fs/sysfs/file.c flush_write_buffer(struct dentry * dentr · line 232

Quoted 5 lines
fs/sysfs/file.c +5 -0
+
+     /* strip the white space */
+     if (buffer->page != x)
+             memmove(buffer->page, x, count);
+     buffer->page[count] = '\0';

Why move the buffer? Why not just pass in a pointer to the start of the "non-whitespace filled" buffer to the store() function?

That will work if you say it does. I didn't know what happens with buffer->page in other parts of the code.

Quoted 5 lines

thanks,

greg k-h

Signature · 2 lines
Jon Smirl
[email protected]