[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150305005829.GC14927@swordfish>
Date: Thu, 5 Mar 2015 09:58:29 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Minchan Kim <minchan@...nel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Jerome Marchand <jmarchan@...hat.com>
Subject: Re: [PATCH 0/2] make automatic device_id generation possible
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 */
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.
-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.
--
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/
Powered by blists - more mailing lists