Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Alex Dewar <alex.dewar90@gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        "David S. Miller" <davem@davemloft.net>,
        Alex Dewar <alex.dewar90@gmail.com>,
        Nayna Jain <nayna@linux.ibm.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Sourabh Jain <sourabhjain@linux.ibm.com>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        linux-kernel@vger.kernel.org
Subject: [PATCH RFC 0/2] simple sysfs wrappers for single values
Date:   Sun, 30 Aug 2020 00:37:15 +0100
Message-Id: <20200829233720.42640-1-alex.dewar90@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
To:     unlisted-recipients:; (no To-header on input)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi all,

I've noticed there seems to have been a fair amount of discussion around
the subject of possible helper methods for use in the context of sysfs
show methods (which I haven't had a chance to go through in detail yet
-- sorry!), so I thought I'd send out a couple of patches I've been
working on for this, in case it's of any interest to anyone.

My idea was to have a few simple wrappers for returning single values
via sysfs, as in theory that's how sysfs should be being used. This
isn't going to be usable for more complicated cases, but at least by
doing this we should be able to make it easier to direct the attention
of code checkers (either automated or the flesh-and-blood kind) towards
the potentially more problematic cases. Hopefully we should be able to
convert over many of the more trivial cases to these helpers using
Coccinelle.

For the number helper (sysfs_sprinti), I opted to go for a macro which
can handle short, int, ULL etc., though equally we could go for
differently named inline functions instead. Either way, I think
enforcing the type of input arguments and not allowing users to pass
format strings is the way to go. Even for e.g. "sprintf(buf, "%llu\n",
my_number)", there is the possibility that my_number could be of type
int and so mishandle negative values. Let's make it easy for maintainers
to review at a glance, without having to remember what type my_number
was declared as.

With the string helpers we can make sure that we aren't overflowing the
destination buffer, but I've also put in a check so that we don't read
beyond the end of the source buffer either, in the case that it's a
fixed-size array. So if we do have an automated changeover with
Coccinelle then we should make things safer too :-)

Anyway, I'm off to bed now but I'll check for messages in the morning.
Any feedback gratefully received!

Best,
Alex