- User Since
- Nov 14 2018, 8:11 PM (80 w, 1 d)
Apr 7 2020
Updating D24289: map capability string for VM_CAP_BPT_EXIT
Apr 4 2020
Aug 1 2019
You’re welcome to finish it up..
@araujo, sounds like you are taking over this review?
Jul 1 2019
May 12 2019
May 11 2019
Apr 19 2019
Apr 13 2019
Sounds good, I will do that. You can expect to see an updated revision in the next few days.
Mar 30 2019
Updating D19650: Don't check if the dataset is mounted when destroying a snapshot (libbe)
Mar 19 2019
Mar 8 2019
Mar 7 2019
The channel programs look like a cool feature - I have a few questions about it:
Mar 4 2019
I'm not sure why the history is clobbered for this updated diff revision with regards to target_prog.c being copied from be_impl.h.
Feb 28 2019
Feb 24 2019
A question about the added files - am I supposed to include the copyright/license information or...?
Feb 22 2019
Feb 14 2019
Jan 4 2019
Do you use IRC or anything of the sort? Some of this might be easier to hash out in real-time, and we can summarize the results of said discussion back in this review.
Dec 27 2018
It's probably poor style to change the user interface for bectl but, it's
already recursive by default - could always ignore the '-r' flag and add a flag
for shallow creation. Upside here is the current behavior remains unchanged.
Downside being, confusion for current users (i.e. the shell game of
Dec 26 2018
I agree, the default be_create is adequate for most cases. If anything, I would lean
towards a be_create_shallow, here's my thinking. be_create is, effectively,
a recursive snapshot that gets cloned - which is consistent with the zfs
behavior of 'zfs snapshot -r'. be_create_shallow would be consistent with
a 'zfs snapshot', minus the recursive flag.
Dec 22 2018
Added tests in sbin/bectl/test and fixed styling issues.