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

[Kunal Gangakhedkar]

On Monday 08 Oct 2012 4:50:20 PM Bastien Nocera wrote:
> 
> 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.
> 

I'm of the opinion that the less amount of un-necessary code loaded in memory, 
the better it is.

Like I said in patch 1/8, very few people have >1 fp device on their machines.
So, it doesn't make sense to keep all the code related to those un-needed 
drivers in memory - however, small it may be.
Who knows what kind of attack vector it may turn out to be? :)

Besides, I don't think it adds any complexity - I cooked up the implementation 
in less than a weekend's time and I'm very slow :)
Instead, I think it actually reduces complexity.

In the current implementation, there are 3 lists of drivers -
1. one for registered drivers.
2. one for "known" primitive drivers
3. one for "known" imaging drivers.

What's the point of having 3 lists?
Ideally, the driver itself should know what kind of interface it provides and 
register itself likewise.

Moreover, after fp_init() lists 2 and 3 become redundent since the same 
structures are put into registered_drivers list (1).

With dynamically loadable drivers, both these are taken care of.
fprintd is the best judge to determine when it needs to use the fingerprint 
device and when it's done, it can just remove the driver from memory.

Tomorrow, if a new device comes to market, instead of recompiling the entire 
fprint library, most distros can just ship an updated package like fprint-data 
or fprint-drivers.

Besides, like I mentioned in the mail, I don't know if there is any need for 
such support and am just hoping that people find it useful :)
And this is probably very early cut of the code.

I hope I'm making some sense and a case for this patchset :).
Please feel free to punch holes in this logic - at least I'll learn something 
new :)

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

Oops, sorry, didn't know about that.
I'll post them to bugzilla if and when you approve.

Thanks,
Kunal