lkml.org 
[lkml]   [2016]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
Date
On Thu, 10 Nov 2016, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Jani,
>
> On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote:
>> On Thu, 10 Nov 2016, Laurent Pinchart wrote:
>> > The issue here is that printk can't format the fourcc as a string by
>> > itself. There's a bunch of places in the kernel where a similar
>> > formatting problem occurs. In a few occasions it has been solved by
>> > extending printk with additional format specifiers (such as for MAC/IP
>> > addresses, GUIDs, various kind of device names, ...). DRM fourccs are
>> > probably too DRM specific to be worth a format specifier, but I wonder
>> > whether we could introduce a new specifier that takes a function pointer
>> > as a formatting helper. Another similarly crazy option would be a format
>> > specifier for strings that would free the passed pointer after printing
>> > it.
>>
>> I think there are too many non-standard format specifiers already. I
>> can't review the non-standard format strings without looking at
>> Documentation/prink-formats.txt first. The formatting hook would be a
>> generic alternative, but that's more than a little scary from the
>> security standpoint. And what if the hook has to allocate memory? Can't
>> do that in atomic contexts.
>
> There are lots of details to sort out obviously and I don't have an answer to
> all questions yet. I think it would be worth researching this, as the problem
> isn't specific to DRM/KMS.

That's easy to agree to; as much as you didn't mean to shoot down the
patch, I didn't mean to shoot down your idea! :)

BR,
Jani.


--
Jani Nikula, Intel Open Source Technology Center

\
 
 \ /
  Last update: 2016-11-10 12:04    [W:0.072 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site