All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Cc: Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [RFC] simple_char: New infrastructure to simplify chardev management
Date: Fri, 27 Mar 2015 01:45:46 -0700	[thread overview]
Message-ID: <20150327084546.GA5182@infradead.org> (raw)
In-Reply-To: <d3ab93173d51cebf00dd2263fd0ce9f8cd6258f7.1423609645.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>

> Thoughts?  I want to use this for the u2f driver, which will either be
> a chardev driver in its own right or use a simple new iso7816 class.
> 
> Ideally we could convert a bunch of drivers to use this, at least
> where there are no legacy minor number considerations.

I'd really like to see a few consumer posted with it, to see how the
conversion works.

> -			   topology.o container.o
> +			   topology.o container.o simple_char.o

And the code should probably go into fs/char_dev.c, and have simple
char_ names to that people use it naturally.  A bit of documentation
of all the char interfaces and why you'd want to use this one would
also be useful for driver writers.

> +static int simple_char_open(struct inode *inode, struct file *filep)
> +{
> +	struct simple_char_major *major =
> +		container_of(inode->i_cdev, struct simple_char_major,
> +			     cdev);
> +	void *private;
> +	const struct simple_char_ops *ops;
> +	int ret = 0;
> +
> +	mutex_lock(&major->lock);
> +
> +	{
> +		/*
> +		 * This is a separate block to make the locking entirely
> +		 * clear.  The only thing keeping minor alive is major->lock.
> +		 * We need to be completely done with the simple_char_minor
> +		 * by the time we release the lock.
> +		 */
> +		struct simple_char_minor *minor;
> +		minor = idr_find(&major->idr, iminor(inode));
> +		if (!minor || !minor->ops->reference(minor->private)) {
> +			mutex_unlock(&major->lock);
> +			return -ENODEV;
> +		}
> +		private = minor->private;
> +		ops = minor->ops;
> +	}
> +
> +	mutex_unlock(&major->lock);
> +
> +	replace_fops(filep, ops->fops);
> +	filep->private_data = private;

So we're back to replace_fops here.  I would much prefer if this
would the regions interface so that we don't have to rely on a full
major allocation and replacing live file operations.

> +EXPORT_SYMBOL(simple_char_major_create);

new exported function without any documentation

> +
> +void simple_char_major_free(struct simple_char_major *major)
> +{
> +	BUG_ON(!idr_is_empty(&major->idr));
> +
> +	cdev_del(&major->cdev);
> +	unregister_chrdev_region(MKDEV(major->majornum, 0), MAX_MINORS);
> +	idr_destroy(&major->idr);
> +	kfree(major);
> +}

non-static, non-exported function?

> +/**
> + * simple_char_minor_create() - create a chardev minor
> + * @major:	Major to use or NULL for a fully dynamic chardev.
> + * @ops:	simple_char_ops to associate with the minor.
> + * @private:	opaque pointer for @ops's use.
> + *
> + * simple_char_minor_create() creates a minor chardev.  For new code,
> + * @major should be NULL; this will create a minor chardev with fully
> + * dynamic major and minor numbers and without a useful name in
> + * /proc/devices.  (All recent user code should be using sysfs
> + * exclusively to map between devices and device numbers.)  For legacy
> + * code, @major can come from simple_char_major_create().

Sounds like you should not pass @major for the main interface then,
and instead have a low-level interface that takes the major pointer.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>, Jiri Kosina <jkosina@suse.cz>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC] simple_char: New infrastructure to simplify chardev management
Date: Fri, 27 Mar 2015 01:45:46 -0700	[thread overview]
Message-ID: <20150327084546.GA5182@infradead.org> (raw)
In-Reply-To: <d3ab93173d51cebf00dd2263fd0ce9f8cd6258f7.1423609645.git.luto@amacapital.net>

> Thoughts?  I want to use this for the u2f driver, which will either be
> a chardev driver in its own right or use a simple new iso7816 class.
> 
> Ideally we could convert a bunch of drivers to use this, at least
> where there are no legacy minor number considerations.

I'd really like to see a few consumer posted with it, to see how the
conversion works.

> -			   topology.o container.o
> +			   topology.o container.o simple_char.o

And the code should probably go into fs/char_dev.c, and have simple
char_ names to that people use it naturally.  A bit of documentation
of all the char interfaces and why you'd want to use this one would
also be useful for driver writers.

> +static int simple_char_open(struct inode *inode, struct file *filep)
> +{
> +	struct simple_char_major *major =
> +		container_of(inode->i_cdev, struct simple_char_major,
> +			     cdev);
> +	void *private;
> +	const struct simple_char_ops *ops;
> +	int ret = 0;
> +
> +	mutex_lock(&major->lock);
> +
> +	{
> +		/*
> +		 * This is a separate block to make the locking entirely
> +		 * clear.  The only thing keeping minor alive is major->lock.
> +		 * We need to be completely done with the simple_char_minor
> +		 * by the time we release the lock.
> +		 */
> +		struct simple_char_minor *minor;
> +		minor = idr_find(&major->idr, iminor(inode));
> +		if (!minor || !minor->ops->reference(minor->private)) {
> +			mutex_unlock(&major->lock);
> +			return -ENODEV;
> +		}
> +		private = minor->private;
> +		ops = minor->ops;
> +	}
> +
> +	mutex_unlock(&major->lock);
> +
> +	replace_fops(filep, ops->fops);
> +	filep->private_data = private;

So we're back to replace_fops here.  I would much prefer if this
would the regions interface so that we don't have to rely on a full
major allocation and replacing live file operations.

> +EXPORT_SYMBOL(simple_char_major_create);

new exported function without any documentation

> +
> +void simple_char_major_free(struct simple_char_major *major)
> +{
> +	BUG_ON(!idr_is_empty(&major->idr));
> +
> +	cdev_del(&major->cdev);
> +	unregister_chrdev_region(MKDEV(major->majornum, 0), MAX_MINORS);
> +	idr_destroy(&major->idr);
> +	kfree(major);
> +}

non-static, non-exported function?

> +/**
> + * simple_char_minor_create() - create a chardev minor
> + * @major:	Major to use or NULL for a fully dynamic chardev.
> + * @ops:	simple_char_ops to associate with the minor.
> + * @private:	opaque pointer for @ops's use.
> + *
> + * simple_char_minor_create() creates a minor chardev.  For new code,
> + * @major should be NULL; this will create a minor chardev with fully
> + * dynamic major and minor numbers and without a useful name in
> + * /proc/devices.  (All recent user code should be using sysfs
> + * exclusively to map between devices and device numbers.)  For legacy
> + * code, @major can come from simple_char_major_create().

Sounds like you should not pass @major for the main interface then,
and instead have a low-level interface that takes the major pointer.

  parent reply	other threads:[~2015-03-27  8:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 23:44 [RFC] simple_char: New infrastructure to simplify chardev management Andy Lutomirski
2015-02-10 23:44 ` Andy Lutomirski
     [not found] ` <d3ab93173d51cebf00dd2263fd0ce9f8cd6258f7.1423609645.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2015-02-11  0:44   ` Greg Kroah-Hartman
2015-02-11  0:44     ` Greg Kroah-Hartman
     [not found]     ` <20150211004459.GA30746-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-02-11 20:04       ` Andy Lutomirski
2015-02-11 20:04         ` Andy Lutomirski
2015-02-11 10:10   ` Jiri Kosina
2015-02-11 10:10     ` Jiri Kosina
2015-03-27  8:45   ` Christoph Hellwig [this message]
2015-03-27  8:45     ` Christoph Hellwig
2015-04-23  8:25   ` Greg Kroah-Hartman
2015-04-23  8:25     ` Greg Kroah-Hartman
2015-04-23  9:34   ` David Herrmann
2015-04-23  9:34     ` David Herrmann
2015-03-26  0:16 ` Andy Lutomirski
     [not found]   ` <CALCETrUXgqAY1MzMP80W_YC-zCi3nostJE2sLA+X_U0Xu6hoFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-26  9:26     ` Greg Kroah-Hartman
2015-03-26  9:26       ` Greg Kroah-Hartman
2015-10-11  7:26     ` Christoph Hellwig
2015-10-11  7:26       ` Christoph Hellwig
     [not found]       ` <20151011072605.GA28986-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-10-12 20:02         ` Andy Lutomirski
2015-10-12 20:02           ` Andy Lutomirski
  -- strict thread matches above, loose matches on Subject: below --
2015-03-26  7:30 Hillf Danton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150327084546.GA5182@infradead.org \
    --to=hch-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=jkosina-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.