- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
I've added HMAC, it was easier than I thought, actually. I based my work on the Wikipedia description and some code borrowed from sys/geom/eli/g_eli_hmac.c. I did not bother with clearing the keys used since the source material is not really high security secrets in this case. I noticed SHA256_Final already zeroes the context value, so I decided to reuse it.
I thought the same, but manu asked me to do this.
Do not set *eofp when not at EOF, but copyout failed due to ENAMETOOLONG.
Yesterday
Can this land now?
In D51920#1186701, @des wrote:Apple's code is ours (including the insertion sort bug) with an added recursion limit.
I already benchmarked NetBSD's code, we're about twice as fast as them. Apple's code is ours (including the insertion sort bug) with an added recursion limit.
It will take a while.
From a brief series of tests[1] libkern's implementation is slightly more performant than libc's (Note that this test already has D51919 applied, as it prevents it from going quadratic.).
Also, I'd like to take a look at OpenBSD, NetBSD, and especially macOS' which perform really well overall.
In D51924#1186691, @kib wrote:In the description: s/eto/to/
jrtc4@amoracia:~/freebsd-src$ LD_UTRACE=1 ktrace -t u ~/freebsd-obj/home/jrtc4/freebsd-src/amd64.amd64/libexec/rtld-elf/ld-elf.so.1 /usr/bin/true && kdump | grep loaded 80756 ld-elf.so.1 USER RTLD: loaded 0x5a069ee03408 @ 0x3dae988c1000 - 0x3dae988c12e5 ([vdso]) 80756 ld-elf.so.1 USER RTLD: loaded 0x5a069ee03808 @ 0x3dae98deb000 - 0x3dae990edfff (/lib/libc.so.7)
In the description: s/eto/to/
Don't round up
fix generate-ucl to not create a dependency from -lib to the base package
be a little more idiomatic
This is wrong. The triplet of pic_post_filter/pic_post_ithread/pic_pre_ithread are always *required* to be implemented by all INTRNG PICs. Omitting pic_post_filter and pic_post_ithread is a violation of the interface.
remove some dead code
jrtc4@amoracia:~/freebsd-src$ LD_UTRACE=1 ktrace -t u /libexec/ld-elf.so.1 /usr/bin/true && kdump | grep loaded 6613 ld-elf.so.1 USER RTLD: loaded 0x47728f403408 @ 0x1dbb7f8e9000 - 0x1dbb7f8e8fff ([vdso]) 6613 ld-elf.so.1 USER RTLD: loaded 0x47728f403808 @ 0x1dbb7ff71000 - 0x1dbb80273fff (/lib/libc.so.7)
In D51920#1186616, @kevans wrote:In D51920#1186615, @jlduran wrote:In D51920#1186595, @kevans wrote:Have you looked into how feasible it would be to sync them up and just have libc reach into libkern for the bulk of the implementation?
OK, will look into that.
I would prefer to have it duplicated, but I guess it is prone to getting out of sync in the future.I'm curious to hear you're reasoning there... in general, these things frequently get out of sync and I can't imagine off-hand why we wouldn't want to reduce our maintenance burden if the implementations are (or should be) largely the same.