[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150227202914.466bbb2e.akpm@linux-foundation.org>
Date: Fri, 27 Feb 2015 20:29:14 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Minchan Kim <minchan@...nel.org>,
Jerome Marchand <jmarchan@...hat.com>,
Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 0/8] introduce dynamic device creation/removal
On Sat, 28 Feb 2015 12:34:15 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@...il.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.
--
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