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 _______________________________________________ fprint mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/fprint
