linux-kernel - Re: [PATCH 0/3] zram: Replace pr_* with dev

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]

Message-ID: <1438912113.2322.7.camel@perches.com>
Date:	Thu, 06 Aug 2015 18:48:33 -0700
From:	Joe Perches <joe@...ches.com>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Salah Triki <salah.triki@....org>, minchan@...nel.org,
	ngupta@...are.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] zram: Replace pr_* with dev_*

On Fri, 2015-08-07 at 10:42 +0900, Sergey Senozhatsky wrote:
> 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@...nel.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.

I'm fine with you having an opinion but I'm not fine
with you stating:

"We cannot change this anymore.

This potentially breaks things in user space.
So, I NACK the change set."
.
because dmesg is not an ABI.


--
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/