[fprint] [PATCH 0/8] [RFC] Build drivers as shared objects

[Bastien Nocera]

Hey Kunal,

On Mon, 2012-10-08 at 20:09 +0530, Kunal Gangakhedkar wrote:
> This is a set of patches that tries to build the drivers as shared object
> modules and provides API to load/unload them on the fly.
> 
> The design is inspired by the way linux kernel implements modules -
> albeit, with a lot less complexity :).
> 
> I don't know if anyone is interested in this kind of support.
> Hopefully, people find it useful.
> 
> Ideally, the way to use this feature would be to have fprintd/pam module
> maintain the configuration of drivers the system needs.
> This configuration can be generated by a post-installation script.
> 
> fprintd/pam then runs through such a list of drivers loading them one by one
> by calling load_module().
> 
> In case of PAM, we can add option like "drivers=drv_abc.so drv_xyz.so .."
> directly. However, IIRC the new fprintd code implements a PAM module that
> talks to fprintd instead of talking to h/w directly - in which case, this
> configuration can be handled only in fprintd.
> 
> I'll try to implement this support in fprintd whenever I find some spare
> time to burn.
> 
> This patchset is also available in the following git repo
> 	git://github.com/kunalg/libfprint.git
> in the branch dl-drivers.
> 
> Please review it and let me know if it can be merged.


Thanks for the patches, but you haven't explained why we would want or
need this feature. libfprint has no internal API guarantees, and is
still small enough that it doesn't make sense to disable drivers (240kB
of library on a 64-bit system, even less on 32-bit). This just adds more
complexity for no visible benefit.

Finally, patches should go to Bugzilla (bugzilla.freedesktop.org), not
the mailing-list.

Cheers