From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752280AbbB1EaB (ORCPT <rfc822;w@1wt.eu>);
	Fri, 27 Feb 2015 23:30:01 -0500
Received: from mail.linuxfoundation.org ([140.211.169.12]:50541 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750916AbbB1EaA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 27 Feb 2015 23:30:00 -0500
Date: Fri, 27 Feb 2015 20:29:14 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Minchan Kim <minchan@kernel.org>,
        Jerome Marchand <jmarchan@redhat.com>, Nitin Gupta <ngupta@vflare.org>,
        linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH 0/8] introduce dynamic device creation/removal
Message-Id: <20150227202914.466bbb2e.akpm@linux-foundation.org>
In-Reply-To: <20150228033415.GC5768@swordfish>
References: <1424959843-20409-1-git-send-email-sergey.senozhatsky@gmail.com>
	<20150227145109.b5656bdf853c2d283bf9268e@linux-foundation.org>
	<20150228033415.GC5768@swordfish>
X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 28 Feb 2015 12:34:15 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> On (02/27/15 14:51), Andrew Morton wrote:
> > hoo boy.  Creating a /dev node and doing ioctls on it is really old
> > school.  So old school that I've forgotten why we don't do it any more.
> > 
> > Hopefully Alan can recall the thinking?
> > 
> 
> perhaps, something like
> 
>  static struct class_attribute zram_class_attrs[] = {
>          __ATTR(zram_control, S_IWUSR | S_IRUGO,
>                          zram_control_show, zram_control_store),
>          __ATTR_NULL,
>  };
> 
>  struct class zram_class = {
>          .name           = "zram-control",
>          .class_attrs    = zram_class_attrs,
>  };
> 
> 
>  class_register(&zram_class);
> 
> 
> 
> or (even better) separate control files
> 
>  static struct class_attribute zram_class_attrs[] = {
>          __ATTR(zram_add, ....),
>          __ATTR(zram_remove, ....),
>          __ATTR_NULL,
>  };
> 
> 
> so we can just echo `device_id' to add/remove devices
> 
> echo 1 > /sys/class/zram-control/zram_add
> echo 1 > /sys/class/zram-control/zram_remove
> 
> 
> handling it in FOO_store() functions:
> 
>  static ssize_t zram_add_store(struct class *class,
>                          struct class_attribute *attr,
>                          char *buf)
> 
> 
> how about this?

That would be more conventional.  There's no pretty way of doing this
really.  

http://yarchive.net/comp/linux/ioctl.html does a pretty good job of the
thinking on ioctl - mainly the typelessness of it all.  That's very old
and doesn't discuss the 32/64 bit compat issues.

Your patch doesn't really have this problem at this stage, but once the
ioctl interface is added, new controls which are added later should use
it, and we're likely to get into the same issues.