From: Kay Sievers <kay.sievers@vrfy.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Greg KH <greg@kroah.com>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus <torvalds@linux-foundation.org>
Subject: Re: linux-next: build warnings after merge of the tty tree
Date: Mon, 10 Jan 2011 15:55:35 +0100 [thread overview]
Message-ID: <AANLkTimd1oOzHau3OoyfLzNTRKJTpwxU5-+bQM6Xssm=@mail.gmail.com> (raw)
In-Reply-To: <20110110125908.4251eb45.sfr@canb.auug.org.au>
On Mon, Jan 10, 2011 at 02:59, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> On Sun, 9 Jan 2011 16:56:01 -0800 Greg KH <greg@kroah.com> wrote:
>>
>> Yes, Kay just sent me a patch to fix this, which I will queue up after
>> .38-rc1 is out.
>
> It is surely a pretty obvious patch, why not just do a quick test and
> send it on to Linus (or at least your tty-current tree)?
>
> /me gets annoyed by more warnings than necessary - especially when they
> should have never been introduced in the first place.
Honestly, just disable these mindless warnings. They *might* be a hint
for a developer, but they should not be triggered in any non-manual
build.
These warnings usually just misguide people to make make random
trivial things fatal at bootup, which even prevent a box from coming
up and allow to find the real error. If these return values would
really be important, the called function would log the error itself,
not force the caller.
I personally think they are as useless as the dumb 80 char limit
checkpatch likes to warn about. It just makes things worse, hard to
read -- while it possibly should just warn about to many indents,
never the line length.
Like the must_check nonsense, it's all stuff with well-intended, but
with really bad results in reality.
People should really stop imposing these sick rules everywhere in
tools -- everybody of us has enough personal issues already, I really
don't need our software to throw the issues of other people at me on
top. :)
Kay
next prev parent reply other threads:[~2011-01-10 14:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-21 7:11 linux-next: build warnings after merge of the tty tree Stephen Rothwell
2010-12-21 19:42 ` Greg KH
2011-01-10 0:49 ` Stephen Rothwell
2011-01-10 0:51 ` Kay Sievers
2011-01-10 0:56 ` Greg KH
2011-01-10 1:59 ` Stephen Rothwell
2011-01-10 5:49 ` Greg KH
2011-01-10 14:55 ` Kay Sievers [this message]
2015-03-10 5:37 Stephen Rothwell
2018-03-15 6:43 Stephen Rothwell
2018-03-15 17:34 ` Greg KH
2022-05-10 21:58 Stephen Rothwell
2022-05-10 22:46 ` Maciej W. Rozycki
2022-05-11 5:32 ` Greg KH
2022-05-13 22:47 ` Maciej W. Rozycki
2022-06-14 6:47 Stephen Rothwell
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='AANLkTimd1oOzHau3OoyfLzNTRKJTpwxU5-+bQM6Xssm=@mail.gmail.com' \
--to=kay.sievers@vrfy.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.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).