This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Max, I agree with Sylvain's comments, but like to add: The filename should not be gprs_gea.c but gprs_gea34.c or something along the lines. There are other ciphers (gea1/gea2) and that should somehow be reflected in the file name. Regarding coding style: We generally open the curly braces on the same line as in "for (a;b;c) {". We also don't indent the "case" statements in a switch, e.g.: switch (foo) { case A: foo = 1; break; } I'm also not sure if the gea3/gea4 should become part of libosmogsm itself, or if they should simply exist in the form of a libosmo-crypt-gea34 or the like. Actually, I once created such a library (plugging into gprs_cipher_register()) using the reference implementation of the cipher. I'm not 100% sure on this, though. Does anyone have an opinion on this? Even if it gea3/gea4 becomes part of libosmogsm, then I would like to have no direct functions exported to applications, but require applications to go through the gprs_cipher_* API. The same holds true for the A5/* family. Rather than having explicit function calls for each of the variants, I would love to have one set of functions with just a parameter or struct member defining the specific algorithm to be used by the implementation. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)