From: Artem Bityutskiy <dedekind1@gmail.com>
To: david.wagner@free-electrons.com
Cc: linux-mtd <linux-mtd@lists.infradead.org>,
linux-embedded <linux-embedded@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Tim Bird <tim.bird@am.sony.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI
Date: Mon, 22 Aug 2011 10:39:47 +0300 [thread overview]
Message-ID: <1313998793.2644.49.camel@sauron> (raw)
In-Reply-To: <1313587042-30846-1-git-send-email-david.wagner@free-electrons.com>
Hi,
thanks for the patch, it is quite good I think, but I still have few
comments. I did not review very carefully because of limited amount of
free time.
There are few checkpatch.pl complaints, could you please take a look?
Note, often I give a comment for one place, but there are many other
similar places with the same stuff.
On Wed, 2011-08-17 at 15:17 +0200, david.wagner@free-electrons.com
wrote:
> TODO:
> * the modules keeps a table of the devices which length is the maximum number
> of UBI volumes. There should be a better solution (linked list or, as
> Christoph Hellwig suggests, a radix tree (idr)).
Wold be nice to do the same change for UBI, BTW :-)
> Here is the v3 of ubiblk implementing ioctls for on-demand creation/removal of
> ubiblk device ; is it what you were thinking of ?
Looks like.
[snip]
> +config MTD_UBI_UBIBLK
> + tristate "Read-only block transition layer on top of UBI"
> + help
> + Read-only block interface on top of UBI.
> +
> + This option adds ubiblk, which creates a read-ony block device from
> + UBI volumes. It makes it possible to use block filesystems on top of
> + UBI (and thus, on top of MTDs while avoiding bad blocks).
s/block filesystems/R/O block filesystems/
s/on top of UBI/on top of UBI volumes/
s/and thus, on top of MTDs/and hence, on top of MTD devices/
> +
> + ubiblk devices are created by sending appropriate ioctl to the
> + ubiblk_ctrl device node.
s/sending/invoking/
[snip]
Would be good to add a section to the UBI Documentation describing
ubiblk by sending a patch against mtd-www:
http://git.infradead.org/mtd-www.git
[snip]
> +/*
> + * Structure representing a ubiblk device, proxying a UBI volume
> + */
> +struct ubiblk_dev {
> + struct ubi_volume_desc *vol_desc;
> + struct ubi_volume_info *vol_info;
Since this piece of code is part of drivers/mtd/ubi/, I think that it
makes sense to make it very consistent with the rest of the code. It is
then better to use consistent names for variables of this type: "desc"
and "vi".
> + int ubi_num;
> + int vol_id;
> +
> + /* Block stuff */
> + struct gendisk *gd;
> + struct request_queue *rq;
> + struct task_struct *thread;
Here is one comment I got from hch once which I also saved in the git
history: 6f904ff0e39ea88f81eb77e8dfb4e1238492f0a8
hch: a convention I tend to use and I've seen in various places
is to always use _task for the storage of the task_struct pointer,
and thread everywhere else. This especially helps with having
foo_thread for the actual thread and foo_task for a global
variable keeping the task_struct pointer
Let's follow it and call this field "<something_meaningful>_task", e.g.,
"req_task" (request queue/dispatcher/etc task) ? Keep using "_thread"
for other stuff.
You can also change UBI correspondingly.
> + /* Protects the access to the UBI volume */
> + struct mutex lock;
Lets call all locks <something_meaningful>_lock, e.g., volumes_lock or
vol_lock.
> +
> + /* Avoids concurrent accesses to the request queue */
> + spinlock_t queue_lock;
> +};
And for consistency, it is better to use kerneldoc comments, like the
rest of UBI, but if you hate them, I will not insist.
[snip]
> + mutex_lock(&dev->lock);
> + set_capacity(dev->gd,
> + (vol_info->size * vol_info->usable_leb_size) >> 9);
> + mutex_unlock(&dev->lock);
> + pr_debug("Resized ubiblk%d_%d to %d LEBs\n", vol_info->ubi_num,
> + vol_info->vol_id, vol_info->size);
If you find a way to properly use dev_dbg() instead of pr_debug(), your
messages will be automatically prefixed with "ubiblk%d_%d", and your
messages will be shorter - so less code, smaller binary size. See below
my other comment.
[snip]
> +static int ubiblk_notify(struct notifier_block *nb,
> + unsigned long notification_type, void *ns_ptr)
> +{
> + struct ubi_notification *nt = ns_ptr;
> +
> + switch (notification_type) {
> + case UBI_VOLUME_ADDED:
> + break;
> + case UBI_VOLUME_REMOVED:
> + ubiblk_remove(&nt->vi);
> + break;
> + case UBI_VOLUME_RESIZED:
> + ubiblk_resized(&nt->vi);
> + break;
> + case UBI_VOLUME_UPDATED:
> + break;
> + case UBI_VOLUME_RENAMED:
> + break;
> + default:
> + break;
Please, remove cases which do nothing and let them end up in "default:".
[snip]
> +static long ubiblk_ctrl_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + int err = 0;
> + void __user *argp = (void __user *)arg;
> +
> + struct ubi_volume_desc *vol_desc;
> + struct ubi_volume_info vol_info;
> + struct ubiblk_ctrl_req req;
> +
> + if (!capable(CAP_SYS_RESOURCE))
> + return -EPERM;
> +
> + err = copy_from_user(&req, argp, sizeof(struct ubiblk_ctrl_req));
> + if (err)
> + return -EFAULT;
> +
> + if (req.ubi_num < 0 || req.vol_id < 0)
> + return -EINVAL;
> +
> + vol_desc = ubi_open_volume(req.ubi_num, req.vol_id, UBI_READONLY);
> + if (IS_ERR(vol_desc)) {
> + pr_err("Opening volume %d on device %d failed\n",
> + req.vol_id, req.ubi_num);
Because dynamic_debug usually adds prefixes to messages, or pr_fmt is
usually used to add a prefix, I suggest to make all pr_* / dev_*
messages to start with small letter.
Also, should we use dev_* macros instead? I have always thought that
pr_* is used only if you do not have "struct device", no? But you do
have it, AFAICS:
1. For messages which are not related to a specific ubiblk device,
ubi_blk_ctrl_dev.this_device (may be ubi_blk_ctrk_dev then can be
shortened to ctrl_dev?)
2. For messages that are about a specific device - not exactly sure, but
I bet there is a struct device for your ubiblk_%d_%d device. Probably
disk_to_dev(<struct ubiblk_dev>->gd)
Try to find this out and test. We should not use pr_* unless there is a
good reason why dev_* does not work.
> + return PTR_ERR(vol_desc);
> + }
> +
> + ubi_get_volume_info(vol_desc, &vol_info);
> +
> + switch (cmd) {
> + case UBIBLK_IOCADD:
> + pr_info("Creating a ubiblk device proxing ubi%d:%d\n",
> + req.ubi_num, req.vol_id);
> + ubiblk_create(&vol_info);
Please, return the error code!
> + break;
> + case UBIBLK_IOCDEL:
> + pr_info("Removing ubiblk from ubi%d:%d\n",
> + req.ubi_num, req.vol_id);
> + ubiblk_remove(&vol_info);
And here!
[snip]
> +static int __init ubi_ubiblk_init(void)
> +{
> + int ret = 0;
> +
> + pr_info("UBIBLK starting\n");
Please, kill this message, it looks more like tracing, not info. I
suggest you to add one single message at the end like "blah blah
initialized, major number %d".
> +
> + ret = register_blkdev(0, "ubiblk");
> + if (ret <= 0) {
> + pr_err("UBIBLK: could not register_blkdev\n");
> + return -ENODEV;
> + }
> + ubiblk_major = ret;
> + pr_info("UBIBLK: device's major: %d\n", ubiblk_major);
Please, kill this message as well, or turn it into pr_debug()/dev_dbg().
Talking about messages:
1. Remove this UBIBLK: prefix from all of them. Rationale: if dynamic
debug is enabled, the dynamic debug infrastructure will add it for you,
see "Documentation/dynamic-debug-howto.txt". Otherwise you can always
define "pr_fmt" and add the prefix you wish.
[snip]
> +static void __exit ubi_ubiblk_exit(void)
> +{
> + int i;
> +
> + pr_info("UBIBLK: going to exit\n");
Please, kill these. Again, if you really feel like it - add one single
message like "blah exited" at the end.
[snip]
> +/* Structure to be passed to UBIBLK_IOCADD or IOCDEL ioctl */
> +struct ubiblk_ctrl_req {
> + __s32 ubi_num;
> + __s32 vol_id;
> +};
> +
> +/* ioctl commands of the UBI control character device */
Please, document here that you share "O" with UBI. Also document this in
UBI in a separate patch.
> +
> +#define UBIBLK_CTRL_IOC_MAGIC 'O'
> +
> +/* Create a ubiblk device from a UBI volume */
> +#define UBIBLK_IOCADD _IOW(UBIBLK_CTRL_IOC_MAGIC, 0x10, struct ubiblk_ctrl_req)
> +/* Delete a ubiblk device */
> +#define UBIBLK_IOCDEL _IOW(UBIBLK_CTRL_IOC_MAGIC, 0x11, struct ubiblk_ctrl_req)
> +
> +#endif
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2011-08-22 7:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1308922482-14967-1-git-send-email-david.wagner@free-electrons.com>
2011-06-28 15:24 ` [RFC PATCHv2] UBI: new module ubiblk: block layer on top of UBI david.wagner
2011-06-29 6:54 ` Artem Bityutskiy
2011-07-26 12:27 ` [PATCH] " David Wagner
2011-07-26 12:34 ` Christoph Hellwig
2011-07-26 12:58 ` David Wagner
2011-07-28 6:14 ` Artem Bityutskiy
2011-08-15 11:56 ` Artem Bityutskiy
2011-08-17 13:17 ` [PATCHv3] " david.wagner
2011-08-17 14:20 ` [PATCH] Tools for controling ubiblk David Wagner
2011-08-22 8:17 ` Artem Bityutskiy
2011-08-22 7:39 ` Artem Bityutskiy [this message]
2011-08-22 7:42 ` [PATCHv3] UBI: new module ubiblk: block layer on top of UBI Artem Bityutskiy
2011-08-24 16:23 ` Arnd Bergmann
2011-08-25 7:06 ` Artem Bityutskiy
2011-08-25 15:12 ` Arnd Bergmann
2011-09-01 12:55 ` David Wagner
2011-09-06 3:44 ` Artem Bityutskiy
2011-09-06 4:10 ` Artem Bityutskiy
2011-09-06 4:29 ` Artem Bityutskiy
2011-09-08 15:26 ` Arnd Bergmann
2011-09-09 11:53 ` Artem Bityutskiy
2011-09-09 12:02 ` Artem Bityutskiy
2011-09-09 14:25 ` Arnd Bergmann
2011-09-09 15:27 ` Artem Bityutskiy
2011-09-09 14:41 ` David Wagner
2011-09-09 14:51 ` Arnd Bergmann
2011-09-11 10:18 ` Artem Bityutskiy
2011-09-11 10:35 ` David Wagner
2011-08-24 16:15 ` [PATCHv4] " david.wagner
2011-08-24 16:21 ` [PATCH] document ubiblk's usage of the same ioctl magic as a part " David Wagner
2011-09-06 4:58 ` Artem Bityutskiy
2011-09-06 4:55 ` [PATCHv4] UBI: new module ubiblk: block layer on top " Artem Bityutskiy
2011-09-12 9:51 ` [PATCHv5] " David Wagner
2011-09-19 4:50 ` Artem Bityutskiy
2011-09-22 7:58 ` [PATCHv6] " David Wagner
2011-09-23 10:58 ` Artem Bityutskiy
2011-09-26 12:58 ` David Wagner
2011-09-26 9:17 ` Ricard Wanderlof
2011-09-26 12:38 ` [PATCHv7] " David Wagner
2011-09-26 13:20 ` Artem Bityutskiy
2011-09-26 14:25 ` [PATCHv8] " David Wagner
2011-09-26 14:36 ` Artem Bityutskiy
2011-09-26 14:40 ` [PATCHv9] " David Wagner
2011-10-01 14:08 ` Artem Bityutskiy
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=1313998793.2644.49.camel@sauron \
--to=dedekind1@gmail.com \
--cc=david.wagner@free-electrons.com \
--cc=dwmw2@infradead.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tim.bird@am.sony.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).