devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	ksummit-2013-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [Ksummit-2013-discuss] [RFC] of: Allow for experimental device tree bindings
Date: Fri, 25 Oct 2013 10:22:30 +0200	[thread overview]
Message-ID: <20131025082229.GD19622@ulmo.nvidia.com> (raw)
In-Reply-To: <52699E8B.3000305-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Thu, Oct 24, 2013 at 11:26:19PM +0100, Stephen Warren wrote:
> On 10/23/2013 07:51 PM, Thierry Reding wrote:
> > On Wed, Oct 23, 2013 at 05:05:32PM +0100, David Woodhouse wrote:
> >> On Wed, 2013-10-23 at 17:06 +0200, Thierry Reding wrote:
> >>> +       /* check if binding is experimental */
> >>> +       if (dev != device || drv != driver) {
> >>> +               pr_warn("of: device %s (%s) uses an experimental binding\n",
> >>> +                       np->name, np->full_name);
> >>> +
> >>
> >> In the discussions earlier I think we decided that this should set a
> >> taint flag too.
> > 
> > A taint flag seems somewhat drastic. It's not like using an experimental
> > binding should have an influence on the stability of the running kernel.
> > I always thought that taint flags were supposed to flag conditions where
> > code of unknown origin or code known to be broken was being executed
> > because they may destabilize the running kernel.
> > 
> > The worst that should happen if you run an experimental binding is that
> > some part of the system will just not come up.
> 
> IIRC, the purpose of the taint flag was to make it clear that the kernel
> or DT was not expected to function in the future, so don't be surpised
> if you upgrade it, and it stops working, without you taking explicit
> action, such as revising your DT to match the new kernel or vice-versa.

I understand that, but I was arguing that it doesn't match existing uses
of taint flags. The various flags that are currently defined all seem to
be set whenever some event occurs that could cause instability of the
currently running system, such as loading a proprietary or out-of-tree
module, forcing a module to be loaded, overriding firmware parameters...

All those seem to have the goal of appearing in crash logs, so that
whoever looks at the bug report can point users somewhere else since the
problem is likely to be caused by their own (bad) decision. Or ask users
to reproduce crashes or bugs without doing whatever they did to cause
the taint flag(s) to be set.

Experimental bindings shouldn't cause any crashes in the first place, or
not cause memory corruption or similar for that matter. If we don't want
to support an experimental binding, then all we should do is not support
any functionality that relies on them. That doesn't mean that runtime
stability is in any way affected.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-10-25  8:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 15:06 [RFC] of: Allow for experimental device tree bindings Thierry Reding
2013-10-23 16:05 ` [Ksummit-2013-discuss] " David Woodhouse
     [not found]   ` <1382544332.8522.40.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-10-23 16:55     ` Guenter Roeck
     [not found]       ` <20131023165512.GB22394-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-10-23 17:05         ` David Woodhouse
     [not found]           ` <1382547916.8522.42.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-10-23 18:56             ` Thierry Reding
2013-10-23 18:51     ` Thierry Reding
     [not found]       ` <20131023185114.GA7863-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-24 22:26         ` Stephen Warren
     [not found]           ` <52699E8B.3000305-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-25  8:22             ` Thierry Reding [this message]
     [not found]               ` <20131025082229.GD19622-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-25  8:45                 ` Stephen Warren
     [not found] ` <1382540779-6334-1-git-send-email-treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-23 16:33   ` Stephen Warren
     [not found]     ` <5267FA58.9050002-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-23 17:20       ` [Ksummit-2013-discuss] " Wolfram Sang
2013-10-23 18:59         ` Thierry Reding
     [not found]           ` <20131023185909.GC7863-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-23 19:34             ` Jason Gunthorpe
     [not found]               ` <20131023193450.GE32563-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-10-23 19:58                 ` Thierry Reding
2013-10-23 21:08                   ` Jason Gunthorpe
     [not found]                     ` <20131023210849.GB2912-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-10-24  8:04                       ` Thierry Reding
2013-10-24 17:32                         ` Jason Gunthorpe
2013-10-23 21:13                   ` Andy Lutomirski
2013-10-23 19:40             ` Wolfram Sang
2013-10-23 20:05               ` Thierry Reding
2013-10-24  8:34         ` Grant Likely
     [not found]           ` <20131024083459.48FE3C4039D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-10-24  8:50             ` Thierry Reding
2013-10-24 20:26             ` Matt Sealey
2013-10-24 22:29             ` Stephen Warren
2013-10-24 18:39   ` jonsmirl-Re5JQEeQqe8AvxtiuMwx3w

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131025082229.GD19622@ulmo.nvidia.com \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=ksummit-2013-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).