public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Salah Triki <salah.triki@acm.org>,
	minchan@kernel.org, ngupta@vflare.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] zram: Replace pr_* with dev_*
Date: Fri, 7 Aug 2015 10:42:12 +0900	[thread overview]
Message-ID: <20150807014212.GB1891@swordfish> (raw)
In-Reply-To: <1438910251.2322.2.camel@perches.com>

Hello Joe,

On (08/06/15 18:17), Joe Perches wrote:
[..]
> > "Can't change algorithm for initialized device\n"
> > --> "Can't change algorithm to %s for initialized device\n"
> > 
> > 
> > People already can have scripts doing `grep "zram:"` on dmesg or
> > whatever. We cannot change this anymore.
> 
> That's not true at all.
> 
> Using grep on dmesg is specifically _not_ guaranteed
> to remain stable between kernel versions.

It depends, I guess.  People do use grep after all and people don't
like when things are getting changed underneath; and we don't want
to do this. I think Minchan is with me here. We even didn't add some
additional pr_info/pr_err noise recently because we don't want
people to depend on that part.

http://lkml.iu.edu/hypermail/linux/kernel/1505.3/01759.html

Minchan Kim <minchan@kernel.org>:

|I meant if we remove the pr_err in future by some reason,
|someone might shout
|
|"No, it's ABI so if you guys removes it, it will break user interface's
|semantic". Maybe he seems to depends on parse on dmesg.
|That is not what I want.

And I saw some time ago people doing that type of thing. So I'd like
to avoid unnecessary pain for zram users even if the messages are not
guaranteed to remain stable between kernel releases. Just my opinion.

	-ss

  reply	other threads:[~2015-08-07  1:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 22:57 [PATCH 0/3] zram: Replace pr_* with dev_* Salah Triki
2015-08-06 23:03 ` [PATCH 1/3] zram: Replace pr_info with dev_info in max_comp_streams_store Salah Triki
2015-08-06 23:03   ` [PATCH 2/3] zram: Replace pr_info with dev_info in comp_algorithm_store Salah Triki
2015-08-06 23:03     ` [PATCH 3/3] zram: Replace pr_* with dev_* Salah Triki
2015-08-07  0:05 ` [PATCH 0/3] " Sergey Senozhatsky
2015-08-07  1:17   ` Joe Perches
2015-08-07  1:42     ` Sergey Senozhatsky [this message]
2015-08-07  1:48       ` Joe Perches
2015-08-07  2:03         ` Sergey Senozhatsky
2015-08-07  2:16           ` Sergey Senozhatsky
2015-08-07  6:05   ` Minchan Kim
2015-08-07  6:37     ` Sergey Senozhatsky
2015-08-07  6:56       ` Sergey Senozhatsky
2015-08-07  7:12         ` Joe Perches
2015-08-07  7:25           ` Sergey Senozhatsky
2015-08-07 14:58       ` Minchan Kim
2015-08-10  1:25         ` Sergey Senozhatsky

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=20150807014212.GB1891@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=salah.triki@acm.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