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

[Bastien Nocera]

On Tue, 2012-10-09 at 09:13 +0530, Kunal Gangakhedkar wrote:
> Resending - since earlier mail got blocked from the list due to size
> >40KB.
> 
>  
> 
> On Monday 08 Oct 2012 5:54:06 PM Bastien Nocera wrote:
> 
> > On Mon, 2012-10-08 at 21:03 +0530, Kunal Gangakhedkar wrote:
> 
> > > 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.
> 
>  
> 
> As per my understanding, the moment fp_init() is called, entire
> libfprint (with all the baggage of drivers) is loaded into memory -
> and not piece-by-piece. 

A library will not be handled the same way as a dlopened() library.


> This is exactly what I'm pitching for with my patchset that we split
> it up so that it can be loaded with only required pieces.

You're working from the wrong assumptions.

> What parts of the memory image are swapped out are not in our control,
> but they are still executable memory image.
> 
>  
> 
> Also, the primary user of libfprint is still fprintd - a daemon
> started at boot time. If it keeps pinging the device for fingerprint
> status (I don't know - haven't looked at fprintd or any of the GUIs
> yet), libfprint is very much active in memory.

fprintd isn't started on boot, it's auto-started through D-Bus when
needed, and quits after 30 seconds of inactivity. 99% of the time, it's
not running.

> I think I did mention in my first mail that this can be done by using
> a post-install script with a separate program.

Yes, which adds complexity.

> You don't need to do it every so often, do you?
> 
> How many times do you change your fingerprint device to require
> enumeration with drivers?

The enumeration is done every time fprintd starts, so you can use the
finger print reader that's actually plugged in to the computer.

> Again, I'm trying to stick to UNIX philosophy - each program does one
> and only one job but does it well.

I don't see what that has to do with anything.

> > See the point I mentioned about the internal drivers API not being
> with
> 
> > any guarantees of stability.
> 
>  
> 
> *Somebody* has to maintain the drivers whenever there is change in
> internal API - whether they're built into libfprint or as separate
> modules.
> 
> So, this point is moot in my PoV.

The point is moot because you're not the maintainer of that code.

> Please note that I'm *not* suggesting or even supporting out-of-tree
> development here.

Well, what's the point then?

> > I'm willing to take patches to reduce the complexity of the
> different
> 
> > driver modules.
> 
>  
> 
> I hope it will come in future, but like I said, it needs cleaner
> interfaces and data structures. Consider this patchset as the
> beginning ;)

Sigh. Then no.

> BTW, I'm not asking it to be merged in master just now.
> 
> I expect people to just take a look at it right now - hence, calling
> it RFC.

Cheers