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/.
Sylvain Munaut 246tnt at gmail.comHi Harald,
I actually got back to Max about this patch and I'll handle getting it
merged and test it OTA as part of some security improvement stuff I'm
working on.
Cheers,
Sylvain
On Fri, Nov 22, 2013 at 4:40 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Dear Max,
>
> I'm getting back to this old thread about your kasumi, A5/3 and A5/4
> patches.
>
> There were lots of comments during the review in April, but I never saw
> a follow-up patchset that adressed those comments.
>
> Particularly, from the discussion, I remember:
> 1) follow kernel coding style
> 2) whitespace / tab spacing
> 3) line wrapping
> 4) naming of helper routines which are generic accessor functions.
>
> On Mon, Apr 08, 2013 at 04:10:32PM +0200, ☎ wrote:
>> > +uint16_t osmo_get2bytes(const uint8_t *a);
>> > +void osmo_64pack2pbit(uint64_t in, pbit_t *out);
>> >
>> > Theses essentially look like integer accessors, one is a read for
>> > uint16_t in big endian and the other a store for uint64_t in little
>> > endian, but same basic idea. But you're using completely different
>> > naming schemes for both ... I think they should reflect that their
>> > name should reflect the LE/BE part and the unaligned part as well, I
>> > even think there are already macro somewhere for that. I would also
>> > add other formats like LE/BE 16/32/64 bits store/load all at once
>> > rather than each format when needed. If we add accessort, might as
>> > well add all the basic types. And finally those should really be
>> > inline functions in the .h, no point of doing a function call for
>> > that.
>>
>> Is there some library I can use for that? It's indeed fairly trivial
>> accessors but I didn't managed to find those in osmocom code.
>
> If there is no function / macro in libosmo* yet, then looking for kernel
> function names is always a good idea.
>
> we have msgb_{put,get,pull}_u{8/16/32}() as accessors for working with
> message buffers. If msgb doesn't make sense in the context you are
> working in, then aligning the names to the same scheme might be another
> idea.
>
> 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)
>