lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200402155323.6866b5c9@coco.lan>
Date:   Thu, 2 Apr 2020 15:53:23 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Petr Mladek <pmladek@...e.com>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        hverkuil@...all.nl,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        laurent.pinchart@...asonboard.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-media@...r.kernel.org,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>
Subject: Re: [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM
 fourccs

Em Thu, 02 Apr 2020 11:34:48 +0300
Jani Nikula <jani.nikula@...ux.intel.com> escreveu:

> On Wed, 01 Apr 2020, Sakari Ailus <sakari.ailus@...ux.intel.com> wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.  
> 
> I'm not going to take a strong stand in one way or the other regarding
> the patch at hand, but I do think at some point we have to draw a line
> what should be included in printk formats. Arguably they should be
> reserved to things that are generally useful across large parts of the
> kernel, right?
> 
> I think the more specialized you get, the more you should think about
> just using the plain old %s, and your own helpers.

As I suggested it, from my side, I'd like to have it inside printk :-)

There is a subset of formats that are subsystem-specific anyway at
printk, like the network ones. We use extensively fourcc along the
media subsystem (and you probably also use fourcc at DRM). Even some input
devices nowadays may be using V4L2 core (some multi-sensor touching
devices), with depends on it.

So, those fourcc codes are pretty common. Having it at the printk
infra makes a lot easier for people to use them.

> Because frankly, the
> kernel printk specifiers also start getting more than a little obscure.

I liked one of the suggestions of using "%p4cc" (or maybe something
similar, if having a number there is a problem, like "%pAcc" or "%pfcc")
for this printk. This would be very easy for people to identify and 
remember about its meaning.

> Or could we conceive of a way to make this locally extensible yet safe,
> letting callers use something like %{foo}, as well as providing a
> locally relevant function to do the conversion?

That's something that it makes sense to be implemented in the future,
for things that would be self-contained inside an specific subsystem.

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ