Hi David,

On 09/15/2016 05:25 PM, David Lechner wrote:
On 09/15/2016 09:54 AM, Jacek Anaszewski wrote:
Hi Pavel,

On 09/15/2016 03:01 PM, Pavel Machek wrote:

@@ -0,0 +1,23 @@
+ * Userspace driver support for leds subsystem
+ *
+ * This program is free software; you can redistribute it and/or
+ * it under the terms of the GNU General Public License as
published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * GNU General Public License for more details.
+ */
+#ifndef _UAPI__ULEDS_H_
+#define _UAPI__ULEDS_H_
+#define ULEDS_MAX_NAME_SIZE    80
+struct uleds_user_dev {
+    char name[ULEDS_MAX_NAME_SIZE];

We already have path component length limit somewhere, right? Just use

(And is struct with char array good idea at all? Perphaps it can just
use write() length up to something reasonable, and not bother with new
header file for userspace?)

In fact in this case the addition of another public header can be

The main reason I did it this way is in case someone wants to extend
this to also, for example, set the max_brightness value. If we use an
arbitrary size string, we could never add max_brightness without
breaking userspace.

If we are sure we will never want to pass any other parameters other
than name, then we can do away with the struct.

This is sound argument. Let's limit the name size to 64, as in case
of name variable in led_classdev_register(). This patch could also
add include directive "#include <uapi/leds/uleds.h>" to
drivers/leds/led-class.c and replace 64 with a new LED_MAX_NAME_LEN macro defined in the uleds.h header.

Best regards,
Jacek Anaszewski

Reply via email to