Fix the prebuild libs dependency.

Fix /rescue.

Forgot to link liblzma with pthread.
Add a few more files to the build.

Add lzma.h to ObsoleteFiles.inc.

Closed by commit rP378420 (authored by @rpaulo).

Not sure why there was no context available.

Closed by commit rP377097 (authored by @rpaulo).

Fixed the install without LANG set.

The code looks good, but I'm not familiar with the RTC hardware. Still, I'll mark it as reviewed.

In D1428#5, @emaste wrote:

In D1428#3, @rpaulo wrote:

This looks odd. Why are we relying on magic numbers instead of constants/enums like before?

Some of the constants in the previous version are Linux-specific, and don't exist in our ELF headers.

We could make up our own constants (e.g. NT_LINUX_AUXV) but it doesn't seem like that would provide much value. The same constant name may have different values on different OSes.

This looks odd. Why are we relying on magic numbers instead of constants/enums like before?

In the commit log, I wouldn't use the pronoun "the" but instead you could make it clear you're talking about m_clrprotoflags().

Reviewed.

Committed.

Some developers have disabled PREEMPTION to work around problems in the drivers, but I agree it should be re-enabled and those drivers should be fixed.

Closed by commit rS275779 (authored by @rpaulo).

Closed by commit rP374569 (authored by @rpaulo).

Closed by commit rP374085 (authored by @rpaulo).

Closed by commit rP374069 (authored by @rpaulo).

Closed by commit rS274987 (authored by @rpaulo).

In D1183#5, @loos wrote:

Are we going to change gpioctl(1) to use libgpio ?

Thanks Rui!

In D1025#11, @ian wrote:

The other thing that bothers me about this driver is that typically frequency and voltage are scaled together... first voltage is increased, then frequency, to scale up. When scaling back, first frequency is reduced, then voltage. I see one line of code in the cpufreq set routine that lowers voltage, nothing that ever increases it except manual controls by the user.

D1031 will fix this.

It might be better to put these reviews under 'network'.

New diffs from Aoyama-san.

Only minor comments.

In D1031#4, @rakuco wrote:

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off).

Plus we tend to group all variables related to an option (so AVAHI_LIB_DEPENDS/AVAHI_CMAKE_* then the corresponding MDNSRESPONDER_* variables).

And don't bump PORTREVISION — there is no need for rebuilding the package.

Are you sure? Looking at kdelibs's dnssd/CMakeLists.txt, we were indeed never building the mDNSResponder backend at all, even with our MDNSRESPONDER option defaulting to on. Since we hard-depend on net/avahi-app, HAVE_AVAHI in CMakeLists.txt was always set and we were always building the Avahi code.

However, taking one step back this also means that we've never built the mDNSResponder backend at all, at least for a long time (this can be partially verified by looking at the beefy{1,2} logs for the port). The detection code in kdelibs was added in 2007, and our dependency on net/avahi-app has always existed (since area51 r3659).

This could very well be an argument in favor of removing the MDNSRESPONDER option altogether (it's not clear to me how it was ever used even though miwi added it as a missing dependency in area51 r3671).

In D1025#4, @loos wrote:

I tried to build this code but it fails with:

cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I/data/rpi/head/src/sys -I/data/rpi/head/src/sys/contrib/altq -I/data/rpi/head/src/sys/contrib/libfdt -I/data/rpi/head/src/sys/gnu/dts/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables -ffreestanding -gdwarf-2 -mfpu=none -mllvm -arm-enable-ehabi -Werror /data/rpi/head/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
/data/rpi/head/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c:161:19: error: use of undeclared identifier 'BCM2835_MBOX_CHAN_PROP'

MBOX_WRITE(mbox, BCM2835_MBOX_CHAN_PROP, (uint32_t)sc->dma_phys);
                 ^

/data/rpi/head/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c:162:18: error: use of undeclared identifier 'BCM2835_MBOX_CHAN_PROP'

MBOX_READ(mbox, BCM2835_MBOX_CHAN_PROP, &err);
                ^

2 errors generated.

Overall it's good. We just need to make it more FreeBSD source code friendly.

In D1021#13, @makc wrote:

I would like to hear the reason for this change. Currently only three ports depend on avahi-libdns (and one of them the avahi meta port), while mDNSResponder is used by 25 ports + 450 kde ports via kdelibs. This change will cause package conflicts, particularly between kde ports and cups ports.

In D1021#7, @rakuco wrote:

Thanks. Someone pointed out on IRC that Avahi might not be a fully functional replacement for mDNSResponder. I have no idea about the accuracy of this information, do you? And is there something in mDNSResponder that's actively causing problems at the moment other than that it is not maintained anymore?

In D1021#3, @rakuco wrote:

It would be helpful to understand why you want to do this though. Is it because mDNSResponder is unmaintained? If it is, why not remove the MDNSRESPONDER option altogether?

There are a bunch of empty lines that you might want to remove.

What if the packet was encapsulated? Does the flag get copied over to the inner packet? If it does, then that's a bug because the flowid needs to be recalculated.

I'm not sure how make anchors work and I've run into this problem before, so if it fixes it, great.
Right now, this code only lets you work with one DTrace script. I had some ideas on how to improve that, but I never worked on them.

Closed by commit rS273257 (authored by @rpaulo).

Fixing the compatible string.

Fixing the previous revision.

Changes based on review comments.

Closed by commit rP371024 (authored by @rpaulo).

Some #defines are still unused, but good for now.

What happens if you remove the battery? Shouldn't the thread have some condition variable to let it terminate?

There are more references to OMAP3 in other files. For example: ti/omap4/omap4_prcm_clks.c (fix the comments?), ti/ti_cpuid.c (does it even compile now?), ti/ti_mmchs.c, ti/ti_prcm.c, ti/ti_prcm.h, ti/ti_sdhci.c, ti/ti_sdma.c, ti/usb/omap_ehci.c and ti/usb/omap_usb.h.

Makes sense to me.

I've reviewed this, but I think it needs to be reviewed by someone else more experienced in VFP.

This looks great, thanks! Symbol lookup caching has been in my TODO for a while, so I'd be grateful if you could do that :-)

Did you generate this patch with arc? There's no context available.

In D506#95, @sbruno wrote:

In D506#94, @rpaulo wrote:

In D506#93, @sbruno wrote:

In D506#92, @rpaulo wrote:

In D506#91, @sbruno wrote:

Yep, no argument there. True in both the ipv6 and ipv4 case because of the default values that are being chosen for the tuneables. This will not be the case if the users choose different values based on their networks. So I think the code is still correct.

Then I don't understand the choice of default values if this is a no-op by default. I'm fine with it if you plan to fix it in the future.

I'm trying to think if there's a case where the user enables the blackhole functionality and the value of the blackhole mss would NOT be less than the default mss. I think that this code might be more of a safety check. If the user sets a blackhole value that its way out of bounds in the large direction, this would catch it and set it to the default.

To me, that's how it was supposed to be in the first place. First drop to the blackhole MSS and then drop to the minimum MSS. The blackhole MSS could be 1200.

If I read the original revisions in XNu, there's no way that could have happened as the code clear the PMTU flag on the first pass. It would never fall back down the blackhole detection code path to try and use the minmss value.

Perhaps that's a bug and we should try and take two attempts (set blackhole mss to something not the minimum like 1200) and try to let the code be more robust?

I think it's a good cleanup and it's easy to verify that nothing changed.

In D506#93, @sbruno wrote:

In D506#92, @rpaulo wrote:

In D506#91, @sbruno wrote:

Yep, no argument there. True in both the ipv6 and ipv4 case because of the default values that are being chosen for the tuneables. This will not be the case if the users choose different values based on their networks. So I think the code is still correct.

Then I don't understand the choice of default values if this is a no-op by default. I'm fine with it if you plan to fix it in the future.

I'm trying to think if there's a case where the user enables the blackhole functionality and the value of the blackhole mss would NOT be less than the default mss. I think that this code might be more of a safety check. If the user sets a blackhole value that its way out of bounds in the large direction, this would catch it and set it to the default.

In D506#91, @sbruno wrote:

Yep, no argument there. True in both the ipv6 and ipv4 case because of the default values that are being chosen for the tuneables. This will not be the case if the users choose different values based on their networks. So I think the code is still correct.