From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Marcin Jabrzyk <m.jabrzyk@samsung.com>,
ngupta@vflare.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, kyungmin.park@samsung.com
Subject: Re: [PATCH] zram: check compressor name before setting it
Date: Mon, 25 May 2015 13:03:04 +0900 [thread overview]
Message-ID: <20150525040304.GA555@swordfish> (raw)
In-Reply-To: <20150522131447.GA14922@blaptop>
On (05/22/15 22:14), Minchan Kim wrote:
> > > >second, there is not much value in exposing zcomp internals,
> > > >especially when the result is just another line in dmesg output.
> > >
> > > From the other hand, the only valid values that can be written are
> > > in 'comp_algorithm'.
> > > So when writing other one, returning -EINVAL seems to be reasonable.
> > > The user would get immediately information that he can't do that,
> > > now the information can be very deferred in time.
> >
> > it's not.
> > the error message appears in syslog right before we return -EINVAL
> > back to user.
>
> Although Marcin's description is rather misleading, I like the patch.
> Every admin doesn't watch dmesg output. Even people could change loglevel
> simply so KERN_INFO would be void in that case.
there is no -EUNSPPORTEDCOMPRESSIONALGORITHM errno that we can return
back to userspace and expect it [userspace] to magically transform it
into a meaningful error message; users must check syslog/dmesg. that's
the way it is.
# echo LZ4 > /sys/block/zram0/comp_algorithm
# -bash: echo: write error: Device or resource busy
- hm.... why?
- well, that's why:
dmesg
[ 249.745335] zram: Can't change algorithm for initialized device
> Instant error propagation is more strighforward for user point of view
> rather than delaying with depending on another event.
I'd rather just add two lines of code, w/o making zcomp internals visible.
it seems that we are trying to solve a problem that does not really
exist. I think what we really need to do is to rewrite zram documentation
and to propose zramctl usage as a recommended way of managing zram devices.
zramctl does not do `typo' errors. if somebody wants to configure zram
manually, then he simply must check syslog. it's simple.
---
drivers/block/zram/zcomp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index a1a8b8e..d96da53 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -54,11 +54,16 @@ static struct zcomp_backend *backends[] = {
static struct zcomp_backend *find_backend(const char *compress)
{
int i = 0;
+
while (backends[i]) {
if (sysfs_streq(compress, backends[i]->name))
break;
i++;
}
+
+ if (!backends[i])
+ pr_err("Error: unknown compression algorithm: %s\n",
+ compress);
return backends[i];
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Marcin Jabrzyk <m.jabrzyk@samsung.com>,
ngupta@vflare.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, kyungmin.park@samsung.com
Subject: Re: [PATCH] zram: check compressor name before setting it
Date: Mon, 25 May 2015 13:03:04 +0900 [thread overview]
Message-ID: <20150525040304.GA555@swordfish> (raw)
In-Reply-To: <20150522131447.GA14922@blaptop>
On (05/22/15 22:14), Minchan Kim wrote:
> > > >second, there is not much value in exposing zcomp internals,
> > > >especially when the result is just another line in dmesg output.
> > >
> > > From the other hand, the only valid values that can be written are
> > > in 'comp_algorithm'.
> > > So when writing other one, returning -EINVAL seems to be reasonable.
> > > The user would get immediately information that he can't do that,
> > > now the information can be very deferred in time.
> >
> > it's not.
> > the error message appears in syslog right before we return -EINVAL
> > back to user.
>
> Although Marcin's description is rather misleading, I like the patch.
> Every admin doesn't watch dmesg output. Even people could change loglevel
> simply so KERN_INFO would be void in that case.
there is no -EUNSPPORTEDCOMPRESSIONALGORITHM errno that we can return
back to userspace and expect it [userspace] to magically transform it
into a meaningful error message; users must check syslog/dmesg. that's
the way it is.
# echo LZ4 > /sys/block/zram0/comp_algorithm
# -bash: echo: write error: Device or resource busy
- hm.... why?
- well, that's why:
dmesg
[ 249.745335] zram: Can't change algorithm for initialized device
> Instant error propagation is more strighforward for user point of view
> rather than delaying with depending on another event.
I'd rather just add two lines of code, w/o making zcomp internals visible.
it seems that we are trying to solve a problem that does not really
exist. I think what we really need to do is to rewrite zram documentation
and to propose zramctl usage as a recommended way of managing zram devices.
zramctl does not do `typo' errors. if somebody wants to configure zram
manually, then he simply must check syslog. it's simple.
---
drivers/block/zram/zcomp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index a1a8b8e..d96da53 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -54,11 +54,16 @@ static struct zcomp_backend *backends[] = {
static struct zcomp_backend *find_backend(const char *compress)
{
int i = 0;
+
while (backends[i]) {
if (sysfs_streq(compress, backends[i]->name))
break;
i++;
}
+
+ if (!backends[i])
+ pr_err("Error: unknown compression algorithm: %s\n",
+ compress);
return backends[i];
}
next prev parent reply other threads:[~2015-05-25 4:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 8:31 [PATCH] zram: check compressor name before setting it Marcin Jabrzyk
2015-05-22 8:31 ` Marcin Jabrzyk
2015-05-22 8:56 ` Sergey Senozhatsky
2015-05-22 8:56 ` Sergey Senozhatsky
2015-05-22 9:12 ` Marcin Jabrzyk
2015-05-22 9:12 ` Marcin Jabrzyk
2015-05-22 12:44 ` Sergey Senozhatsky
2015-05-22 12:44 ` Sergey Senozhatsky
2015-05-22 13:14 ` Minchan Kim
2015-05-22 13:14 ` Minchan Kim
2015-05-22 13:34 ` Marcin Jabrzyk
2015-05-22 13:34 ` Marcin Jabrzyk
2015-05-25 4:03 ` Sergey Senozhatsky [this message]
2015-05-25 4:03 ` Sergey Senozhatsky
2015-05-25 14:16 ` Minchan Kim
2015-05-25 14:16 ` Minchan Kim
2015-05-22 13:26 ` Marcin Jabrzyk
2015-05-22 13:26 ` Marcin Jabrzyk
2015-05-25 6:18 ` Sergey Senozhatsky
2015-05-25 6:18 ` Sergey Senozhatsky
2015-05-25 6:23 ` Sergey Senozhatsky
2015-05-25 6:23 ` Sergey Senozhatsky
2015-05-25 7:15 ` Marcin Jabrzyk
2015-05-25 7:15 ` Marcin Jabrzyk
2015-05-25 7:34 ` Sergey Senozhatsky
2015-05-25 7:34 ` Sergey Senozhatsky
2015-05-25 8:05 ` Marcin Jabrzyk
2015-05-25 8:05 ` Marcin Jabrzyk
2015-05-25 14:21 ` Minchan Kim
2015-05-25 14:21 ` Minchan Kim
2015-05-26 0:09 ` Sergey Senozhatsky
2015-05-26 0:09 ` 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=20150525040304.GA555@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.jabrzyk@samsung.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.