[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200811291220.47542.david-b@pacbell.net>
Date: Sat, 29 Nov 2008 12:20:47 -0800
From: David Brownell <david-b@...bell.net>
To: Hans Verkuil <hverkuil@...all.nl>
Cc: Linux and Kernel Video <video4linux-list@...hat.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"davinci-linux-open-source@...ux.davincidsp.com"
<davinci-linux-open-source@...ux.davincidsp.com>,
linux-kernel@...r.kernel.org,
Laurent Pinchart <laurent.pinchart@...net.be>
Subject: Re: [PATCH v2] v4l2_device/v4l2_subdev: final (?) version
On Saturday 29 November 2008, Hans Verkuil wrote:
> +void v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev)
> +{
> + BUG_ON(!dev || !v4l2_dev || dev_get_drvdata(dev));
>
Ouch. Better to return -EINVAL, like most register() calls,
than *ever* use a BUG_ON() for bad parameters. Same applies
every other place you use BUG_ON, from a quick scan ...
For the unregister() paths a WARN() would be fair. Again,
any time you're tempted to use BUG() or BUG_ON(), you need
to re-think. It's hardly ever the right thing to do. Just
report the error and continue; callers should check, and
clean up if something went wrong.
> +EXPORT_SYMBOL(v4l2_device_register);
This may be a nit, but I wonder why not EXPORT_SYMBOL_GPL,
which seems to be more correct in this case.
Another quasi-style point: v4l2-device.s and v4l-subdev.c
are so small, and conceptually related, that I'd be tempted
to have one file not two. Ditto their headers.
- Dave
--
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