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: <CACvgo50+2B4Q_ABHqsoGBjxZrSXK7LJ_r5p=dnWbWBPPj1wNDQ@mail.gmail.com>
Date:   Tue, 27 Sep 2016 17:54:32 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Sean Paul <seanpaul@...omium.org>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On 27 September 2016 at 17:43, Joe Perches <joe@...ches.com> wrote:
> On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
>> On 27 September 2016 at 17:04, Joe Perches <joe@...ches.com> wrote:
>> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>> > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches <joe@...ches.com> wrote:
>> > > > Use a bit more consistent style with kernel loglevels
>> > > I'm not convinced this is worth doing if we're going to keep the
>> > > WARN/WARNING discrepancy, and I don't think we should switch DRM_WARN
>> > > to DRM_WARNING since it's so widely used.
>> > There is no DRM_WARN inconsistency.
>> DRM_WARN is to DRM_WARNING like DRM_INFO is to DRM_INFORMATION and
>> DRM_NOTE is to DRM_NOTICE...
>
> DRM_INFORMATION doesn't exist in the kernel tree.
>
>> is what I'm thinking and seemingly so
>> does Sean. Fwiw that part seem cosmetic/unrelated to the rest of the
>> patch, so it might be worth keeping separate ?
>
> To me, simplifying the macro means using the common kernel
> macro forms.
>
"unify" might be better, but I agree.

Either way there's no point in elaborating on the point me(Sean?)
meant since it's just going to get shoot down like a dog ;-)

Regards,
Emil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ