From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754197AbcIOPZX (ORCPT ); Thu, 15 Sep 2016 11:25:23 -0400 Received: from vern.gendns.com ([206.190.152.46]:47452 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754005AbcIOPZO (ORCPT ); Thu, 15 Sep 2016 11:25:14 -0400 Subject: Re: [PATCH v2] leds: Introduce userspace leds driver To: Jacek Anaszewski , Pavel Machek References: <1473361440-9668-1-git-send-email-david@lechnology.com> <84510542-4faa-9763-611a-be3890f3f1f7@samsung.com> <20160915130110.GI13132@amd> <69e2865f-8ba9-ea1a-594f-3de4131e3ea2@samsung.com> Cc: Richard Purdie , linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org, Marcel Holtmann From: David Lechner Message-ID: <48ba9d0b-9718-8411-3a1e-c2dd19f0adb5@lechnology.com> Date: Thu, 15 Sep 2016 10:25:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <69e2865f-8ba9-ea1a-594f-3de4131e3ea2@samsung.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? >> >> (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. > 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.