linux-kernel - Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt

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]

Date:	Thu, 28 Mar 2013 11:05:03 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	Julia Lawall <julia.lawall@...6.fr>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>, FlorianSchandinat@....de,
	linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	"backports@...r.kernel.org" <backports@...r.kernel.org>,
	cocci@...teme.lip6.fr,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	rodrigo.vivi@...il.com, Daniel Vetter <daniel.vetter@...ll.ch>,
	rafael.j.wysocki@...el.com
Subject: Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall <julia.lawall@...6.fr> wrote:
> On Thu, 28 Mar 2013, Jesse Barnes wrote:
>> >     -      info->skip_vt_switch = true;
>> >     +      fb_enable_skip_vt_switch(info);
>> >
>> > So we'd then have to just add this static inline change for each new driver...
>> > There may be a way to get SmPL to do this for us...
>
> @@
> type of info  *info;
> @@
>
> -      info->skip_vt_switch = true;
> +      fb_enable_skip_vt_switch(info);
>
> for whatever the type of info is.

Thanks Julia! I'll be sure to try to add this to compat-drivers if the
upstream fb patch is not accepted. If it is accepted we would not need
this at all!

> Then I guess there would be a similar rule for the false case?

Nope, see that's the proactive strategy taken by the static inline and
hence the patch. compat would have a static inline for both cases, and
for the false case it'd be a no-op. If accepted upstream though then
we would not need any changes for this collateral evolution. However
*spotting* these collateral evolutions and giving you SmPL for them as
a proactive strategy might be good given that if these type of patches
are indeed welcomed upstream we'd then be able to address these as
secondary steps. If they are not accepted then indeed we'd use them to
backport that collateral evolution through both compat (adds the
static inlines) and compat-drivers (the SmPL).

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/