Re: [PATCH 1/28] drivers/base/platform.c: Drop return value from platform_driver remove functions

On Wed, 10 Dec 2008 17:26:26 +0100 (CET)
Julia Lawall <julia@xxxxxxx> wrote:

From: Julia Lawall <julia@xxxxxxx>

The return value of the remove function of a driver structure, and thus
of
a platform_driver structure, is ultimately ignored

Currently

Are there really any plans about actually using the return value?


and is thus unnecessary.

Really - capturing those kind of failures is useful information which is
currently discarded but could later be used. Removing that information
makes it very hard to go and put back into all the drivers.

The overwhelming majority of platform drivers do not return anything
meaningful from their remove() callbacks. So, it looked like void is
appropriate here in the same manner as, for example, the module exit
functions are void.

Let me please shed some light on the history of this patchset. It all
began when I sent a benign one-liner to shut up an annoying compiler
warning:

http://marc.info/?l=linux-scsi&m=122714044609103&w=2

It was immediately noticed that the return value of the remove() callback
is actually ignored in the drivers/base/ code:

http://marc.info/?l=linux-scsi&m=122832419623402&w=2

So, the idea of converting the drivers from int (*remove)() to void
(*remove)() was born.

Then, Julia decided to use her semantic patch tool, which looked very
appropriate for this kind of change: conversion of int-returning remove()
callbacks to void callbacks. We asked Greg Kroah-Hartman for his opinion
about the exact way to proceed here, and this is what he suggested
off-list:

<<<

You can do a "migration" type change:
- create a new callback function pointer that returns void
- start moving code over to the new callback
- when finished, delete the old callback
- create a new callback with the same old name, that returns
void
- move the code to use the new name.

Yeah, it's a pain, but it can be done in an incremental way.

thanks,

greg k-h

<<<

The patchset is therefore the first step in the direction of the API cleanup.

So, maybe this background info would help the reviewers somehow.

Thanks,
Dmitri Vorobiev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • kmmio/mmio-trace problems
    ... drivers can immediately see the use of such a tool. ... static inline unsigned long page_present ... static void poke ... +static inline int post_kmmio_handler(unsigned long condition, ...
    (Linux-Kernel)
  • Re: Howto use callback functions with a C DLL
    ... typedef void; ... static extern void myfunction (callback_t callback, ... But once I start passing a callback function, the application crashes with "Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Library design for downloading an unknown amount of data?
    ... Thus the callback function would only be called once, right before the function returns control back to the caller. ... typedef void (const unsigned char *data, unsigned int size, void *userdata); ...
    (comp.lang.c)
  • UserControl, Repeater, OnItemCommand
    ... Invalid postback or callback argument. ... protected void Page_Load ... public partial class Control_OrderItems: System.Web.UI.UserControl ...
    (microsoft.public.dotnet.csharp.general)
  • Re: Howto use callback functions with a C DLL
    ... typedef void; ... static extern void myfunction (callback_t callback, ... But once I start passing a callback function, the application crashes with "Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. ...
    (microsoft.public.dotnet.languages.csharp)