corbet@lwn.net (Jonathan Corbet) writes:
quoted text
>
> 3: Provide a new form of cdev_add() which lets the driver indicate
>    that the BKL is not needed on open (or anything else?).  At a
>    minimum, it could just be a new parameter on cdev_add which has a
>    value of zero or FIXME_I_STILL_NEED_BKL.  Still some churn but easier
>    to script and smaller because a lot of drivers are still using
>    register_chrdev() - something else worth fixing.
>
>    A more involved form might provide a new chardev_add() which takes
>    the new char_dev_ops structure too.  Mapping between new and old
>    operations vectors would be done internally to avoid breaking older
>    drivers before they can be fixed.
>
> 4: Just find every char dev open() function and shove in lock_kernel()
>    calls, then remove the call from chrdev_open().  The disadvantage
>    here is that, beyond lots of work and churn, there's no way to know
>    which ones you missed.

In general when changing semantics drastically you should force
compile errors by renaming the respective entry point. That
has been the standard Linux method for this for years.

I've been also pondering a variant of 1, but 3 might be better.

quoted text
> I kind of like the combination of 2 and 3, done in such a way that
> there's no "every driver must change" flag day.  This could be an
> interesting project, even...  Thoughts?

I doubt it will be very interesting, but it would be useful.
The goal less being to get rid of BKL in old drivers, but not 
requiring BKL in new drivers. Basically all BKL assumptions
in interfaces really should go.

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