Jono Woodhouse wrote: > I am hoping to soon do a tidy up of the code that I am using to get > libfprint to work on our embedded systems, and would like to give you > the option to fold this back into the project. > > I have a couple of questions: > > 1) Should I go ahead and modify against v0.05 - or would it be better to > wait until v0.06 ?
Better to wait for v0.1 as there are loads of changes (all the asynchronous stuff I've been working on) I'm sorry that a lot of stuff is waiting on the async work to complete (which in turn depends on libusb-1.0). Progress is being made but it'll be a while longer given that I'm the only one working on that. > 2) I was thinking of using compile switches that would alternate the > Making of the project. i.e. By default you get the normal standard > compile - but with the use of compile switches you could include extra > embedded libfprint code, and/or code from stripped down 3rd Party > libraries (like glib and/or the AES code etc.) glib usage should just be removed altogether. libcrypto dep (for AES) should be optional - there should actually be 3 options: 1. no MSFPv2 support at all 2. MSFPv2 support through libcrypto (default) 3. MSFPv2 support through internal AES implementation p.s. I'm also told that the newest DigitalPersona-retailed UareU4000B's have the same C-R authentication scheme (without a new USB ID). Someone is donating one for me to work on. For "extra embedded" code, that depends on what the embedded functionality actually is. I would rather produce a library which does not have any specific "embedded mode". That may not be possible, but you'll have to convince me of that first. > 3) Regarding the use of external libraries that are just too large to > fit on some embedded systems (e.g. GLib). > Would you rather we keep the shrinking down of these libraries as a > separate project (outside of libprint), or is it okay to include > stripped down source files inside a say libfprint/glib_shrunk or > something like that? > GLib is also licensed under LGPL v2 - so is this okay from a licensing > point of view? Depends on the external libraries in question. I already gave answers for glib and libcrypto. Needs to be taken on a case-by-case basis. > 4) For now, I've been trying to make as few changes as possible to your > files, and have rather added new functions to a c file called embedded.c > Are you okay with this, or would you rather have all these changes > incorporated into the core.c / imgdev.c etc. files? > For example the following are in embedded.c at the moment: > void fp_embedded_init(struct fp_dev **p_fingerprint_device, struct > fp_img_dev **p_img_dev, struct fp_dscv_dev **p_dscv_dev); > void fp_embedded_exit(struct fp_dev **p_fingerprint_device, struct > fp_img_dev **p_img_dev, struct fp_dscv_dev **p_dscv_dev); > void fp_embedded_capture(struct fp_dev *p_dev, struct fp_img **p_img, > int p_unconditional); I'd rather not have any specific "embedded" functionality and have the whole thing lean enough for embedded use anyway. I suggest that you file feature request bugs for the 2 tasks that we have identified above (glib removal, 3 AES options), and any other *solid* tasks that you can identify. Then we can revisit them when the async work is complete and stable. Thanks! Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
