In D16649#354035, @kib wrote:

Sounds good. The versioning stuff for libc looks ok.

Note that freebsd style is to use 'return (x);'.

In D16649#353911, @kib wrote:

IMO it is very bad practice for the library functions to terminate the main program. Besides, what is wrong with returning 0/errno = EFAULT when NULL is passed ?

I'll commit this later today if there's no objections

In D15592#353902, @cem wrote:

CAM has this pattern where at completion, it tries to submit any pending IO. So is the consensus that we're ok submitting any existing IO on the cam_iosched queue that happened to be there prior to panic — in addition to dump-related IO?

During a panic, we stop the scheduler. No scheduler, only dump will schedule I/Os that modify the disk. CAM needs to run many non-read/write I/Os during or after the dump to (a) flush the blocks written by the dump and (b) properly shutdown all devices. Since we don't call the biodone completion routines, we can't schedule any I/O via that route either. Finally, all interrupts are disabled during a panic, so fast interrupt handlers can't be the source of a chain of events that sets off new I/O via a non-biodone vector. Since there's nothing that can schedule I/O, this method is completely adequate to prevent dangerous things from happening, and is not dependent on hacking a bunch of CAM drivers to do unnatural things.

Was the larger size an issue for us?

Other than an inconsistency in how you're adding newlines after , I like it.

This looks OK, module the endian issue I highlighted. But that trick only works for fields that fall on even byte boundaries.

Perfect! Thank you for such a prompt cleanup.

generally I like it, but there's two unrelated changes, I think, in here.

Love it... do we need to update the u-boot ports to include this metadata...

And is there still an upstream for these files?

Seems fine. Normally, these files aren't in the control of users...

This is fine.

Assuming the testing worked for this, go for it!

Further research suggests pogo plug is not a good thing to add (it would be hard to support)
Maybe add the Seagate FreeAgent DockStar too. The config builds, but no .kwb. I have one of these, but maybe too much of a PITA
Finally, Maybe we just want DreamPlug and call it a day.

Remove already committed changes

Generally, I like this, modulo the couple of issues that need to be addressed. the biggest one is the ENXIO test being too specific.

If someone sets hw.uart.console, assume they know what they are doing
and don't second guess them.

https://reviews.freebsd.org/D16463 has a different approach.

https://pastebin.com/zxRTPX2A has the sketch of what I'd like to see:
change uart_probe to take a quirks argument. It sets a new sc_quirks member. The driver classes then look at this to know. We then add quirks to the FDT and ACPI driver tables as needed. Lots of the FDT ifdefs may go away if I'm reading the code right...

We should remove the GUMSTIX image too.

kill stray comment

Move things earlier in the file.

In D16397#348166, @manu wrote:

In D16397#348163, @brd wrote:

I would like to see the u-boot-rpi and u-boot-rpi2 ports MAINTAINER be set to uboot@ as well, but I am not worried about it.

We can do that in another review, I'm perfectly fine with this.

• Remove MAINTAINER lines. They are set by the master port and all these

That's a clever idea...