Page MenuHomeFreeBSD

sys/arm: Remove armv6 kernel configs
ClosedPublic

Authored by andrew on Jun 19 2024, 6:11 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 9:43 AM
Unknown Object (File)
Tue, Nov 5, 10:28 PM
Unknown Object (File)
Tue, Nov 5, 1:33 PM
Unknown Object (File)
Sun, Oct 20, 9:01 AM
Unknown Object (File)
Oct 16 2024, 10:34 PM
Unknown Object (File)
Oct 15 2024, 1:57 AM
Unknown Object (File)
Oct 12 2024, 11:33 PM
Unknown Object (File)
Oct 12 2024, 7:43 AM
Subscribers

Details

Summary

Only the Raspberry Pi config was supported on armv6. Remove it in
preparation for removing armv6 support from the kernel.

Sponsored by: Arm Ltd

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 58248
Build 55136: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jun 19 2024, 7:01 PM

Thanks for doing all this finding all bittlies and places!

I have a question? Do we need n+1 commits or can we squash them all and do it atomically? We live in git times and not CVS anymore so we could actually make use of it all going cleanly at once.

In some ways this is a more general observation but maybe people on Reviewers have an opinion too for now or the future.

In D45646#1041345, @bz wrote:

Thanks for doing all this finding all bittlies and places!

I have a question? Do we need n+1 commits or can we squash them all and do it atomically? We live in git times and not CVS anymore so we could actually make use of it all going cleanly at once.

In some ways this is a more general observation but maybe people on Reviewers have an opinion too for now or the future.

I'm kinda for one at a time. Makes MFC easier in general for smaller commits. Also makes it easier to back out one if it's an OOPS w/o doing the whole thing...

Though in this case, for comments and such, squashing those might be OK. But squashing anything that touches code is a bad idea. We live in git times. commits are free and smaller ones help with bisecting and MFCing.

Just my two cents.

In CVS times, we'd rush this in as one big commit, then have a mess to sort out later if something unforeseen happened or changes conflicted.

The smaller changes are to help simplify reviewing, and so if I need to revert something it should be a small change and not the full commit.

I have no plans to MFC most of these changes (man page changes could be), so there is no need to squash them for that.

This revision was automatically updated to reflect the committed changes.