[lkml]   [2011]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 01/11] MFD: DA9052 MFD core module v2
    On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote:
    > On Thursday 21 July 2011 16:47:48 Mark Brown wrote:

    > > Although the bigger problem is why are these interruptible? That's
    > > very unusual.

    > Well, the default should really be to use _interruptible or at least
    > _killable with the appropriate error handling, and only use noninterruptible
    > locks in cases where that's not possible.

    > In the funtions that Shawn pointed out, there is an error return, so it would
    > be possible to do that, but the callers would need to be audited carefully.

    We went round this analysis already with the underlying I2C drivers
    (which also end up needing to take mutexes and so on) - it really does
    work out better to just make the I/O noninterruptible, the I/O is fast
    enough to not really be worth interrupting and the handling for actual
    I/O errors should normally be sufficiently different to that for user
    initiated aborts that it just adds complication.

    For example, if the user interrupts while we're in the middle of some
    lengthy series of operations or wait what we really want to do is to
    tear down the high level thing we're doing in an orderly fashion. If
    we allow the interrupt to be noticed as part of an I/O operation then
    what we often end up doing is failing that and we then have to work out
    why the I/O failed, if actually happened on a physical level and how we
    deal with that. Usually none of these paths will be well tested.

    The overall result is that the system generally becomes more complicated
    and less robust.

     \ /
      Last update: 2011-07-22 11:01    [W:0.021 / U:11.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site