From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753997AbbCEBgA (ORCPT ); Wed, 4 Mar 2015 20:36:00 -0500 Received: from mail-pd0-f178.google.com ([209.85.192.178]:42148 "EHLO mail-pd0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753427AbbCEBf7 (ORCPT ); Wed, 4 Mar 2015 20:35:59 -0500 Date: Thu, 5 Mar 2015 10:36:03 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, Jerome Marchand Subject: Re: [PATCH 0/2] make automatic device_id generation possible Message-ID: <20150305013603.GE14927@swordfish> References: <1425478601-19141-1-git-send-email-sergey.senozhatsky@gmail.com> <20150305001954.GA9563@blaptop> <20150305005829.GC14927@swordfish> <20150305011748.GD2592@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305011748.GD2592@blaptop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (03/05/15 10:17), Minchan Kim wrote: > > > > > > 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. > sure, no problem. that's a good question -- should we support user defined ids or not. thanks for asking. I can imagine that that static num_devices limitation (along with max num_devices == 32) was sort of a show stopper for some users (or an unnecessary complication at least), like in 'my now favorite' build server example :) -ss > 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. ;-) >