On Sat, 28 Feb 2015 12:34:15 +0900 Sergey Senozhatsky <sergey.senozhatsky.w...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/