sys: purge EOL release compatibility

[ehem_freebsd_m5p.com]

Summary

Remove conditionals checking for End-of-Life releases. Some
pre-FreeBSD-13.0 conditionals remain, but remove everything before
FreeBSD 12.3. For version checks in headers, check for 12.3 and #error
otherwise.

[ehem_freebsd_m5p.com]

Several configurations passed build testing, so I'm hopeful I didn't flip any conditionals (I don't know whether I tried everything though). I suspect some additional blank lines are worthy of removal. Possibly comments are worthy of adjustment.

Appears many portions became conditional before FreeBSD 7 and FreeBSD 11. Though that conditional for FreeBSD 3.0 in altq_rmclass.c is impressive.

sys/net/altq/altq_rmclass.c

1451–1453

FreeBSD 3.0, that is just a bit in the past. I think that is the oldest conditional here, but don't quote me on that. Since I just noticed this, I'll update this declaration in an update.

[ehem_freebsd_m5p.com]

Upon checking appears no test configurations for enabling altq, even LINT. Bit odd...

[ehem_freebsd_m5p.com]

Then yet another configuration and an unexpected spot shows up.

[imp]

A few nits.
The ideal way forward is to fix the couple of nits, have me look at them then do a pull request against github (or you can use git's format-patch function) that I can land that has your name as you'd like it in the commit, ideally broken down into one commit per directory to allow for easier MFCing of this piecemeal should the need arise.
And thank you.

sys/dev/netmap/netmap_freebsd.c

441 ↗

(On Diff #107273)

I'd delete 'New FreeBSD versions.' here

sys/dev/qlnx/qlnxe/qlnx_os.h

53–56 ↗

(On Diff #107273)

I'd just kill these lines.

sys/dev/qlnx/qlnxr/qlnxr_verbs.c

5020 ↗

(On Diff #107273)

There looks to be a nesting problem here, no?

sys/dev/qlxgb/qla_os.h

54–57 ↗

(On Diff #107273)

I'd just flat out remove these as well.

sys/dev/qlxgbe/ql_os.h

55–58 ↗

(On Diff #107273)

Ditto

sys/dev/qlxge/qls_os.h

55–58 ↗

(On Diff #107273)

ditto

sys/net/altq/altq_rmclass.c

1451–1453

I'm surprised we had a FreeBSD 3 left in the tree... I killed all < 6 some time ago.

[ehem_freebsd_m5p.com]

Updating as per comments.

[ehem_freebsd_m5p.com]

I believe the current nits are adjusted appropriately. Presently on GitLab, branch "D35560". Might be a bit before I'm on GitHub to do such.

The branch "D35560" has been broken apart as appropriate. The commits are roughly ordered by older compatibility bits are earlier, later compatibility bits are later.

sys/dev/qlnx/qlnxr/qlnxr_verbs.c

5020 ↗

(On Diff #107273)

Looks like a Phabricator diff issue to me. Mainly it matched lines with same text, but differing indentation. Did 5297->5018, 5309->5019, and 5315->5020. Whereas it should have done 5320->5018, 5321->5019, and 5322->5020.

Looks like moving the blank line made Phabricator choose a better fit.

sys/net/altq/altq_rmclass.c

1451–1453

Looks like sys/net/altq was missed, plus the one in sys/fs. Happens.

This one of course comes complete with K&R declaration which was adjusted.

[ehem_freebsd_m5p.com]

sys/dev/ixl/ixl_pf_main.c

2269–2279 ↗

(On Diff #107339)

Huh, taking a look for the heck of it... I'm guessing "rd64()" is read 64-bits. Should this perhaps instead be an atomic_load_64()? Certainly looks odd. Also noticing this driver is on AMD64 and PPC, so perhaps this should be unconditionally the first option?

[glebius]

I think the vendor-written drivers need to be checked with their respective vendors. It could be that they still want to support EOL-ed versions.

Ok from me for ALTQ.

sys/net/altq/altq_var.h

82

The empty line should go away, too.

[ehem_freebsd_m5p.com]

Removing the empty line. The mxge and qlnxr removals caused conditionals to always be true or false. Propogate the conditionals to remove yet more now dead pieces.

[ehem_freebsd_m5p.com]

In D35560#807099, @glebius wrote:

I think the vendor-written drivers need to be checked with their respective vendors. It could be that they still want to support EOL-ed versions.

Ick, I could believe it. Though hopefully pre-FreeBSD 11.0 is right out. That is the largest group of compatibility conditionals.

I imagine there are quite a few additional style issues here. I fixed some of the worst ones, but I imagine many more blank lines are worthy of removal or perhaps should be left in.

[ehem_freebsd_m5p.com]

So rd64() is a wrapper calling bus_space_read_8(). I have a strong suspicion this would be available on PPC64 systems, but I'm not sure. If this is so with recent versions, then always using rd64() is correct.

The pull on GitHub has been created.

[jhb]

vmm and acpi_container are ok with me. I think aside from altq and usb the rest of these are all in vendor drivers for which it would be good to probably try to solicit review from the vendor (though with a timeout to move ahead if there is no response)

[imp]

In D35560#808976, @jhb wrote:

vmm and acpi_container are ok with me. I think aside from altq and usb the rest of these are all in vendor drivers for which it would be good to probably try to solicit review from the vendor (though with a timeout to move ahead if there is no response)

I'd suggest that if we can't take the driver and build it on release X w/o changes, we should remove the ifdefs, even from the vendor drivers.

Stuff for FreeBSD 10 or 11 at this point likely is insufficient for the drivers to still build there.

Of course, it would be nice to ask, but I wouldn't wait too long if the #ifdef don't at least compile on those older versions.... Looking at qlnx, it seems there's a number of places where API changes were made w/o ifdefs for older systems (not picking on qlnx here, I just picked one at random).

Followup question: Do we have good info on who to contact for each of these drivers?

[glebius]

In D35560#809057, @imp wrote:

I'd suggest that if we can't take the driver and build it on release X w/o changes, we should remove the ifdefs, even from the vendor drivers.

That's a very nice criteria! Totally agreed.

[mjg]

Send me a diff to whack the hwpmc stuff (as in git format-patch) and I'll commit that bit. Commit message needs to start with "hwpmc: "