- User Since
- Jan 29 2016, 5:27 AM (185 w, 3 d)
Mon, Jul 22
Jul 1 2019
Document usage scenario bit further. Fix some mandoc formattings nits. Suggested by @mckusick
I will keep it at reviews for 1 week and then it will land unless major objections are received. Thanks!
Hey @imp can you please review the latest revision and confirm that it looks OK now?
Jun 5 2019
Rename MTREE -> DISTR_MTREE for clarity and in hope to make @rgrimes happier.
src.bootools.mk -> src.tools.mk as suggested by @imp
Looks good, as long as it compiles.
Jun 3 2019
Jun 2 2019
May 22 2019
Apr 10 2019
Mar 28 2019
Looks good to my VFS-naive eye. Thanks!
Mar 27 2019
Overall looks like a good start, however there are some things that I personally dislike:
Mar 26 2019
Not sure why this is still open. @mizhka_gmail.com please GC?
Check read-only flag in an unified manner.
Mar 22 2019
Feb 25 2019
Document "update" option, as suggested by @mckusick
Feb 23 2019
Feb 22 2019
Feb 21 2019
Also "device xz" needs to be added to the conf/NOTES.
Looks good overall. I am little bit puzzled over usage of "option GEOM_UZIP" vs. "device geom_uzip + device xz". I suspect those are functionally equivalent. Half of the kernel configs in the tree use former (including NOTES) and half the latter. Some subset of the two use both. :( Since you are touching those files anyways, perhaps you can go and convert all cases of "device geom_uzip" into plain "option GEOM_UZIP" and not patch it up by adding device xz? It might be also a good idea to adjust geom_uzip(4) accordingly to provide "One-True-Way" to compile geom_uzip(4) statically into the kernel? Thanks!
Jan 17 2019
Keep clist array in the args.c sorted by the name so that bsearch() DTRT.
Dec 19 2018
Dec 18 2018
Dec 17 2018
Dec 14 2018
@eugen_grosbein.net actually upon thinking a little bit more about the difference between this proposed change and r336195 I came to a conclusion that those two are not necessarily mutually exclusive, but rather complementing each other. The problem with just r336195 alone is that it invalidates implicit expectations that dhclient should not try to touch interface at all after initial configuration, unless there are some changes on the DHCP side. As an administrator, I'd not expect dhclient to be actively policing interface parameters and try to enforce them, which would be the case for MTU now. Consider the following hypothetical scenario:
Dec 13 2018
Dec 12 2018
Make sure we have enough data for ethernet header.
Dec 9 2018
Dec 6 2018
Dec 4 2018
Nov 30 2018
o Due to popular request rename "erase" into "trim".