From: Marcin Jabrzyk <m.jabrzyk@samsung.com>
To: Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: 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: Fri, 22 May 2015 15:34:36 +0200 [thread overview]
Message-ID: <555F306C.7080704@samsung.com> (raw)
In-Reply-To: <20150522131447.GA14922@blaptop>
Hello Minchan,
On 22/05/15 15:14, Minchan Kim wrote:
> Hello Sergey,
>
> On Fri, May 22, 2015 at 09:44:11PM +0900, Sergey Senozhatsky wrote:
>> On (05/22/15 11:12), Marcin Jabrzyk wrote:
>>>>
>>>> no.
>>>>
>>>> zram already complains about failed comp backend creation.
>>>> it's in dmesg (or syslog, etc.):
>>>>
>>>> "zram: Cannot initialise %s compressing backend"
>>>>
>>> OK, now I see that. Sorry for the noise.
>>>
>>>> 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.
Sorry for being confusing, at the first time I've overlooked that error
message in syslog.
I didn't thought about looking for handling exactly this error in
completely different place.
>
> Instant error propagation is more strighforward for user point of view
> rather than delaying with depending on another event.
Yes this was my exact motivation.
Instant value can be detected in scripts etc. Easier to debug in
automated environment.
>
> Thanks.
>
>>
>> -ss
>>
>>> I'm not for exposing more internals, but getting -EINVAL would be nice I
>
If this would be ok, I can prepare v2 with better description and with
less exposing zcomp internals.
Best regards,
Marcin Jabrzyk
--
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: Marcin Jabrzyk <m.jabrzyk@samsung.com>
To: Minchan Kim <minchan@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: 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: Fri, 22 May 2015 15:34:36 +0200 [thread overview]
Message-ID: <555F306C.7080704@samsung.com> (raw)
In-Reply-To: <20150522131447.GA14922@blaptop>
Hello Minchan,
On 22/05/15 15:14, Minchan Kim wrote:
> Hello Sergey,
>
> On Fri, May 22, 2015 at 09:44:11PM +0900, Sergey Senozhatsky wrote:
>> On (05/22/15 11:12), Marcin Jabrzyk wrote:
>>>>
>>>> no.
>>>>
>>>> zram already complains about failed comp backend creation.
>>>> it's in dmesg (or syslog, etc.):
>>>>
>>>> "zram: Cannot initialise %s compressing backend"
>>>>
>>> OK, now I see that. Sorry for the noise.
>>>
>>>> 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.
Sorry for being confusing, at the first time I've overlooked that error
message in syslog.
I didn't thought about looking for handling exactly this error in
completely different place.
>
> Instant error propagation is more strighforward for user point of view
> rather than delaying with depending on another event.
Yes this was my exact motivation.
Instant value can be detected in scripts etc. Easier to debug in
automated environment.
>
> Thanks.
>
>>
>> -ss
>>
>>> I'm not for exposing more internals, but getting -EINVAL would be nice I
>
If this would be ok, I can prepare v2 with better description and with
less exposing zcomp internals.
Best regards,
Marcin Jabrzyk
next prev parent reply other threads:[~2015-05-22 13:34 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 [this message]
2015-05-22 13:34 ` Marcin Jabrzyk
2015-05-25 4:03 ` Sergey Senozhatsky
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=555F306C.7080704@samsung.com \
--to=m.jabrzyk@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky.work@gmail.com \
/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.