public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org,
	Jerome Marchand <jmarchan@redhat.com>
Subject: Re: [PATCH 0/2] make automatic device_id generation possible
Date: Thu, 5 Mar 2015 10:17:48 +0900	[thread overview]
Message-ID: <20150305011748.GD2592@blaptop> (raw)
In-Reply-To: <20150305005829.GC14927@swordfish>

On Thu, Mar 05, 2015 at 09:58:29AM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (03/05/15 09:20), Minchan Kim wrote:
> > I'm not against but I want to know why we should support
> > user-defined device id. What usecase do you have in mind?
> > 
> 
> hm, you never know what people can come up with. that's probably the
> strongest support argument I can provide. I wish there was something
> like - my friend Mike has a "device /dev/zram1 is always swap device,
> device /dev/zram$(id -u) is a per-user zram device (he finds it useful,
> because just looking at device id he can easily tell who owns that
> device)" policy. but nothing like that. I just think that it can be
> useful. no real use cases (well, partly because we don't support device
> add/remove).
> 
> /* yet "/dev/zram$(id -u)" thing looks interesting */

Fair enough.

> 
> 
> user defined id support comes at a price of ~10 lines of code, or even
> less. we waste much more code to show ->stats, and not all of them are
> of any real use, to be fair. that just said, that dropping user defined
> id is not a great deal. ok, let's see if we can come up with anything by
> the end of this day and I'll send out a removal patch if nothing pop up.

As I told you, I'm never against. I just want to know usecase.
If we don't support it from the beginnig, someday, someone will complain
and we can catch up the usecase and support it easily with adding 10 line code.

This dyanmic add/revmove feature proves the idea. :)
Main reason I finally decided dynamic device management feature was
someone complained he should do rmmod/insmod zram.ko to increase
the number of zram device in runtime but one of zram device was
used for swap, which was hard to swapoff due to small memory
so there was no way to increase the number of zram device.
It appeals a lot to support dynamic zram creating and finally I catch up
the usecase. ;-)

> 
> 	-ss
> 
> > Could we support automatic id support only at this moment?
> > Then, if some user complains about that in future, we could turn
> > on user-defined device id easily and we could know the usecase.
> 

-- 
Kind regards,
Minchan Kim

  reply	other threads:[~2015-03-05  1:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 14:16 [PATCH 0/2] make automatic device_id generation possible Sergey Senozhatsky
2015-03-04 14:16 ` [PATCH 1/2] zram: return zram device_id value from zram_add() Sergey Senozhatsky
2015-03-04 14:16 ` [PATCH 2/2] zram: introduce automatic device_id generation Sergey Senozhatsky
2015-03-04 22:13   ` Andrew Morton
2015-03-05  0:09     ` Sergey Senozhatsky
2015-03-05  0:20 ` [PATCH 0/2] make automatic device_id generation possible Minchan Kim
2015-03-05  0:58   ` Sergey Senozhatsky
2015-03-05  1:17     ` Minchan Kim [this message]
2015-03-05  1:36       ` Sergey Senozhatsky
2015-03-05  1:20     ` Sergey Senozhatsky
2015-03-05  1:33       ` Minchan Kim
2015-03-05  1:47         ` Sergey Senozhatsky
2015-03-05  2:04           ` Minchan Kim
2015-03-05  2:27             ` Sergey Senozhatsky
2015-03-05  2:35               ` Minchan Kim
2015-03-05 12:10             ` Karel Zak
2015-03-05 12:31               ` Sergey Senozhatsky
2015-03-05 12:02     ` Karel Zak
2015-03-05 12:26       ` Sergey Senozhatsky
2015-03-05 12:03   ` Sergey Senozhatsky
2015-03-06  3:31   ` 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=20150305011748.GD2592@blaptop \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jmarchan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox