Do you mind elaborating why cleaning up like that is wrong? The reason I did it was to avoid creating multiple md devices. Here we only have 8 iterations of the loop, but I could easly imagine tests were I'd have hundreds and cleaning as I go would be a good thing then, IMHO. But maybe I'm missing something obvious here, so if you could explain that would be great. Thanks.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 9 2019
Apr 4 2019
Apr 3 2019
Mar 30 2019
Mar 1 2019
Feb 20 2019
Feb 19 2019
Jan 9 2019
Dec 7 2018
Oct 20 2018
Change looks good, my only suggestion would be to use maybe NAME2ADDR and ADDR2NAME, so the intentions are obvious.
Oct 4 2018
Jul 13 2018
Jul 10 2018
Revert style changes.
Remove #ifdef INET checks from radlib.h, it prevents some consumers from compiling.
Implement some of oshogbo suggestions.
- Allow for optional compilation without IPv4 or IPv6 support.
- Make it possible to use IPv6 addresses in configuration file.
- Call getaddrinfo(3) with flags set to AI_ADDRCONFIG.
You are probably talking about this one: https://markmail.org/message/e3zkukh7oggutrvw
I've tried it, but it is very out-dated and has some bugs. It also keeps server on a TAILQ, which is nice, but I don't think it should be combined. The nice thing about that patch was to add multiple servers when a hostname resolves to multiple IP addresses, which I also implemented.
Jul 9 2018
Feb 3 2017
I agree with delphij that we should not introduce lower limit.
Looks good, but I agree that hastctl should use libmd too in that case.
Could you please explain why you implemented that in the kernel and not in userland geli command?
Nov 8 2016
May 31 2016
Apr 3 2016
Apr 2 2016
In D4712#124230, @cem wrote:I agree with kib@. It would be nice not to have separate userspace tools here.
In fact we already have encrypted GEOM providers (g_eli, ...). All we lack is a way to dump core through them—maybe? I'm not even sure we lack that.
In D4712#99936, @kib wrote:I looked over the patch, it looks fine to me.
Still, I have a question. You choice was to modify the dump code, which resulted in spreading the patch over the MI dump and all MD minidump code. Semi-obvious alternate approach is to introduce a geom which would write the generated encrypted symmetric key into the first block and write data block N into encrypted block N+1 of the underlying provider. Then you do not have to touch the kernel dump code at all.
Is it possible technically ?
Feb 24 2016
Hi Pascal.
Dec 29 2015
It looks good overall, but please be sure you run GELI regression tests. Thanks!
Dec 16 2015
Oct 25 2015
Oct 21 2015
Thanks John, both good suggestions.
Oct 5 2015
Oct 4 2015
Aug 8 2015
Aug 6 2015
Jul 10 2015
Jul 2 2015
Jun 2 2015
Apr 22 2015
Feb 19 2015
Other that the minor nit above, it looks good.
Looks good to me.
Looks good to me, apart from the small nit above.
Nov 16 2014
Overall looks good to me. I do agree with Jonathan that we should also limit std descriptors. You can find example in the go_daemon() function in sbin/dhclient/dhclient.c.