This contains all the delete as svn would.

In D18558#396096, @alvisen_gmail.com wrote:

This broke boot on my laptop.
Single SATA SSD. UEFI boot.
loader.efi does not find my ZFS pool, which is on GPT partition 3.

=>       40  250069600  ada0  GPT  (119G)
         40       1024     1  freebsd-boot  (512K)
       1064     131072     2  efi  (64M)
     132136        984        - free -  (492K)
     133120  249935872     3  freebsd-zfs  (119G)
  250068992        648        - free -  (324K)

I haven't figured out how to diff deleted files in git yet. I'll upload it soon.

I prefer to deprecate chips / sub-arch, but not removal. Honestly approach with "unimplementable" atomic_64_swap looks too aggressive.
I and @yamori813_yahoo.co.jp have boards with mips4k SoCs and to be honest such chips do their job well.
Another point: I saw plenty of emails with information that 8Mb is very slow. If it looks small for certain group of people, it doesn't mean that it's small in wide audience. I see that firmware with kernel, modules, 20Mb of uncompressed UFS/CD9660 filesystem is powerful to handle plenty of tasks: routing, monitoring of sensors, graphical output to LCD, keyboard/IR control and so on.

Looks good to me.

In D18579#396118, @rgrimes wrote:

Age should not be a criteria for removal. BSD is old, very old, shall we remove it simply cause it is old? IMHO you all are getting way ahead of the process, having reviews to remove code before the cost/benefit and open discussions happens is backwards.

Age should not be a criteria for removal. BSD is old, very old, shall we remove it simply cause it is old? IMHO you all are getting way ahead of the process, having reviews to remove code before the cost/benefit and open discussions happens is backwards.

Addressed more reviewer's comments.

This broke boot on my laptop.
Single SATA SSD. UEFI boot.
loader.efi does not find my ZFS pool, which is on GPT partition 3.

Addressed more reviewer's comments.

This review is enormous. Might I suggest that you cancel it, and then create two smaller reviews? The first would cover adding openrc to contrib, and the second would cover everything else.

In D18451#396062, @mat wrote:

In D18451#395629, @voidanix_420blaze.it wrote:

@tobik is there any way I can get this port committed? I can't commit this yet :p

This tool, here, Phabricator, is a code review tool, not a patch queue for things to be committed, which is what Bugzilla is for.
If you are not a committer, or do not plan to commit it yourself, it is best to always open a PR on our bugzilla in parallel so that the change actually goes in our pipeline.

In D18451#395629, @voidanix_420blaze.it wrote:

@tobik is there any way I can get this port committed? I can't commit this yet :p

In D18574#396028, @rgrimes wrote:

In D18574#395995, @araujo wrote:

Hi guys,

...

One possible solution would be to give the options for users to choose between tap and vmnet style to be used and also document it (we can add some info on our bhyve wiki page)!

There already is a documented -t option that allows one to change this setting on the command line, it is in the usage() message. vmrun.sh is an example script and needs to die sooner, rather than later, with less effort spent on it and more effort on a new config file syntax that gets us out of using this "temporary" script.

In D18574#395995, @araujo wrote:

Hi guys,

...

One possible solution would be to give the options for users to choose between tap and vmnet style to be used and also document it (we can add some info on our bhyve wiki page)!