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

[Bastien Nocera]

On Mon, 2012-10-08 at 21:03 +0530, Kunal Gangakhedkar wrote:
> 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.

If it's not actually executed, the code stays on the disk, not in
memory. Modern OSes will do that.

> 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? :)

How is it an attack vector if the code isn't executed? If you get to the
point where you can execute arbitrary code, it's very very likely that
you can also replace the memory contents with something else.

> 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.

 29 files changed, 678 insertions(+), 59 deletions(-)

Yeah, not sure about it reducing 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).

Not debating that. If you have code to simplify the drivers handling,
I'm interested.

> 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.

You're moving the complexity to the users of libfprint. Furthermore,
enumerating the supported devices means loading all the device drivers.

> 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.

See the point I mentioned about the internal drivers API not being with
any guarantees of stability.

> 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 :)

I'm willing to take patches to reduce the complexity of the different
driver modules.

> > 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.

Cheers