On Mon, Oct 03, 2005 at 03:43:50PM +0300, Pekka Enberg wrote:
> On 10/3/05, Russell King <[email protected]> wrote:
> > It makes sense for kfree() to ignore NULL pointers, but does it really
> > make sense for *_unregister() to do so too? Surely you want to only
> > unregister things which you know have previously been registered?
>
> Usually yes but it makes releasing partial initialization much simpler
> because you can reuse the normal release counterpart. For example,
>
> static int driver_init(void)
> {
> dev->resource1 = request_region(...);
> if (!dev->resource1)
> goto failed;
>
> dev->resource2 = request_region(...);
> if (!dev->resource2)
> goto failed;
>
> return 0;
>
> failed:
> driver_release(dev);
> return -1;
> }
>
> static void driver_release(struct device * dev)
> {
> release_resource(dev->resource1);
> release_resource(dev->resource2);
> kfree(dev);
> }
>
> Many drivers have the release function copy-pasted to init with lots
> of goto labels exactly because release_region, iounmap, and friends
> aren't NULL safe.
Bullshit. I have waded through many, *many* initialization sequences
like that. "Lots of goto labels" is _less_ prone to breakage when
properly done; your variant begs for trouble upon the driver changes.
Note that "lots of goto" is actually a cleaner control structure than
what you propose - the amount of instances of offending statement is
far from being the only metrics. The only things to verify with it are
* releasing is done in the opposite order to claiming
* you always exit to the releasing the last thing you've claimed.
Both are easy to maintain when you change the code _and_ do not break
when you need to introduce something like "keep the number of objects";
I've seen too many cases when release had done the things that can _not_
be made idempotent and still had been used in that manner. With obvious
breakage resulting from it.
And such breakage is easily introduced when changing the code - it's more
common than forgetting to propagate change between release and failure
exits in initialization.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
