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
next prev parent 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