Messages in this thread | | | Subject | Re: [PATCH v2] leds: Introduce userspace leds driver | From | David Lechner <> | Date | Thu, 15 Sep 2016 11:16:38 -0500 |
| |
On 09/15/2016 09:54 AM, Jacek Anaszewski wrote: > Hi Pavel, > > On 09/15/2016 03:01 PM, Pavel Machek wrote: >> Hi! >> >>>> @@ -0,0 +1,23 @@ >>>> +/* >>>> + * Userspace driver support for leds subsystem >>>> + * >>>> + * This program is free software; you can redistribute it and/or >>>> modify >>>> + * 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 >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> + * 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 >> it?
As a matter of fact, in led_classdev_register(), the name is limited to 64. This is hard-coded (no #define).
char name[64];
The given name is truncated to this length in a call to led_classdev_next_name().
>> >> (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 > avoided. >
| |