Re: [PATCH] base-files: reduce IPv6 ULA prefix generation to a single call
On Wed, Apr 03, 2024 at 12:50:50AM +0200, Paul D wrote:
> On 2024-04-02 23:00, Elliott Mitchell wrote:
> > Second, appears the ${parameter:offset:length} may not be POSIX. I
> > dislike this, but do not object since OpenWRT's shell is built with this
> > functionality enabled.
>
>
> UUOC! Ha. Yes, there are a few non POSIXy things in openwrt ash. A number of
> other scripts already take advantage of them so it's OK, if it avoids several
> external calls to e.g. cut or td.
>
Yes, which is why even though I disliked it, I wouldn't be able to reject
merely for that.
> How about POSIX native array IFS split?
>
>
> IFS=' ' set -- $(hexdump -vn 5 -e '5/1 "%02x "' /dev/urandom)
>
> uci -q batch <<-EOF >/dev/null
> set network.globals.ula_prefix=fd$1:$2$3:$4$5::/48
> commit network
> EOF
That is certainly better than the solution I came up with. More
importantly, it addresses concern #1. Now just need a better commit
message and hopefully the committers would find it acceptable.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: reduce IPv6 ULA prefix generation to a single call
On Tue, Apr 02, 2024 at 02:36:36PM +0200, Paul Donald wrote:
> Tested on: 23.05.3
>
> Signed-off-by: Paul Donald
> ---
> .../files/etc/uci-defaults/12_network-generate-ula | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git
> a/package/base-files/files/etc/uci-defaults/12_network-generate-ula
> b/package/base-files/files/etc/uci-defaults/12_network-generate-ula
> index 19d7ed7f2e..20b3237ec7 100644
> --- a/package/base-files/files/etc/uci-defaults/12_network-generate-ula
> +++ b/package/base-files/files/etc/uci-defaults/12_network-generate-ula
> @@ -1,11 +1,9 @@
> [ "$(uci -q get network.globals.ula_prefix)" != "auto" ] && exit 0
>
> -r1=$(dd if=/dev/urandom bs=1 count=1 |hexdump -e '1/1 "%02x"')
> -r2=$(dd if=/dev/urandom bs=2 count=1 |hexdump -e '2/1 "%02x"')
> -r3=$(dd if=/dev/urandom bs=2 count=1 |hexdump -e '2/1 "%02x"')
> +r1=$(hexdump -vn 5 -e '5/1 "%02x"' /dev/urandom)
>
> uci -q batch <<-EOF >/dev/null
> - set network.globals.ula_prefix=fd$r1:$r2:$r3::/48
> + set network.globals.ula_prefix=fd${r1:0:2}:${r1:2:4}:${r1:6:4}::/48
> commit network
> EOF
>
> --
First, since you got rid of "r2" and "r3", "r1" now seems a bad name.
I would suggest switching to simply "r".
Second, appears the ${parameter:offset:length} may not be POSIX. I
dislike this, but do not object since OpenWRT's shell is built with this
functionality enabled.
Third, you need a better commit message. Perhaps type something about
how this improves things.
Overall, I like the idea. This isn't a UUOC, but is pretty close.
Cleanup is always valuable. Only #1 and #3 need to be addressed.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
Reordering since I want to respond to different bits in a different order... On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote: > > Hiding a malicious change in a commit is infinitely harder than hiding > it in a tarball. Yet most of the exploit/payload found so far was in commits, disguised as test cases. On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote: > > unchanged. Git has a lot of security built-in, and by using tarballs > as a base for our package builds we are basically throwing all that > away, for the sake of saving a negligible amount of resources on > the build infrastructure. I sort of agree, sort of disagree with this. Having a cryptographic hash at the center of everything provides security comparable to the security of the hash. Alas, this means replacing that hash is a bit difficult. The design is good, but SHA-1 is no longer appropriately secure. Replacing SHA-1 is a work in progress, but until that completes SHA-1 is still the core of *everything*. I've been monitoring the situation and early work started in 2017, but it still isn't usable yet. Until it is ready there is this rather oversize elephant in the room. https://git-scm.com/docs/hash-function-transition (SHA-1 collisions aren't known to have been used for anything /yet/, but it is only a matter of time; this *really* worries me) On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote: > > However, after reading up about the details of this backdoored release > tarball, I believe that the current tendency to use tarballs rather > than (reproducible!) git checkouts is also problematic to begin with. > > Stuff like 'make dist' seems like a weird relic nowadays, creates more > problems than it could potentially solve, bandwidth is ubiquitous, and > we already got our own tarball mirror of git checkouts done by the > buildbots (see PKG_MIRROR_HASH). So why not **always** use that > instead of potentially shady and hard to verify tarballs? I don't think the issue is so much that tarballs are archiac, but that *everyone* is using Git now. One proposed patch from a pull: https://github.com/openwrt/openwrt/pull/14280/commits/1b29aadbbf07cb77498a0eb92fe7c171c65dab2e I don't see a single reference to a version control system besides Git anywhere in OpenWRT at this point. Tarballs were a reasonable choice when there were >4 source code handling systems in use, yet now Git is also a common point. So if everything is in Git, how does handling tarballs help builds? > Always using git checkouts instead of tarballs would also makes it > much easier for maintainers to at least have a quick look at the > changes made in an upstream project between versions (a quick scroll > over 'git diff oldtag..newtag' or even just 'git log --stat > oldtag..newtag' doesn't take much more time than manually validating a > release tarball GPG signature in most cases, if there even is any...). I see several issues with your argument, but I mostly agree with your conclusion. Git is *everywhere*, so why use tarballs? I disagree with your approach though. Git already has two tools for handling this situation and I think one of them should be chosen. The first is `git submodule`. My understanding it is pretty similar to OpenWRT's current approach. Difference is this lets `git` handle downloading other repositories instead of doing it in a Makefile. Since Git is already designed to handle this sort of task, I suspect this will be rather more reliable than the existing system. Second is `git subtree`. This is a tool for including other projects into a repository. The end result is the other project's history becomes merged into local history. One advantage is you download everything all at *once*, rather than individually grabbing tools. Other is their full history will make upgrades easier since differences will be more obvious. These will need major changes to the build system. On Sat, Mar 30, 2024 at 10:54:00PM +0100, Oldřich Jedlička wrote: > > so 30. 3. 2024 v 16:31 odesílatel Daniel Golle napsal: > > Hiding a malicious change in a commit is infinitely harder than hiding > > it in a tarball. > > Just a note: The malicious code was part of the tarball because it was > part of the main Git repository in the first place. Using Git would > not help in any way in this particular case. Just check [1] together > with findings [2]. > > [1]: https://git.tukaani.org/?p=xz.git;a=shortlog > [2]: https://boehs.org/node/everything-i-know-about-the-xz-backdoor One of the information sources (haha, one can wonder about *any* source of information): https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 Under "Design": >Normally upstream publishes release tarballs that are different than the >automatically generated ones in GitHub. In these modified tarballs, a >malicious version of build-to-host.m4 is included to execute a script >during the build process. So the malicious source code was part
Re: [PATCH] scripts: gen_image_generic: allow FAT fs on kernel partition for non-GPT targets
On Fri, Mar 29, 2024 at 04:32:18PM +0100, Paul D wrote: > Recommend avoiding -a and -o params. > > Use instead e.g. > > [ -n "$GUID" ] || [ "$KERNELPARTTYPE" = "6" ] || [ "$KERNELPARTTYPE" = "c" ] > > https://www.shellcheck.net/wiki/SC2166 The examples pointed to amounted to "be careful with untrusted input to shell scripts". Build systems must already be pretty much 100% trusted. If someone slips something problematic into one there is pretty much nothing to be done about it. I've been getting the feeling the whole community is slowly trying to recreate SunOS 5.7^WSolaris 2.7^WSoliaris 7 (used to be a Sun Thiing, but now everyone's version numbers tend to be inflated). Where /bin/false, /bin/true and /bin/test were all Korne Shell scripts. This nominally saved development work since Korne shell has implementations of all these internally. Problem is this killed performance for any shell script /not/ written in a shell with those as built-in. While Korne shell is very fast once it has finished parsing its input, it is slow at parsing its scripts. Having `gunzip` be a shell script seems headed in this direction. The above seems a similar sort of situation, adding an extra fork()/execve() to avoid warnings. I'm placing SC2166 on my disregard list. Yes, this is nominally not well defined, but unlike most warnings this one has a major impact on performance. (fork()/execve() are the two most expensive routinely used system calls) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: kmod-phy-smsc: add dependency on crc16
On Fri, Mar 29, 2024 at 09:57:04AM +0100, Robert Marko wrote: > On Thu, 28 Mar 2024 at 18:03, Tomasz Maciej Nowak wrote: > > > > From: Tomasz Maciej Nowak > > > > Introduced WoL feature needs CRC16 support. > > > > Signed-off-by: Tomasz Maciej Nowak > > --- > > package/kernel/linux/modules/netdevices.mk | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/package/kernel/linux/modules/netdevices.mk > > b/package/kernel/linux/modules/netdevices.mk > > index af1d8b485e00..724f35df74a2 100644 > > --- a/package/kernel/linux/modules/netdevices.mk > > +++ b/package/kernel/linux/modules/netdevices.mk > > @@ -363,7 +363,7 @@ define KernelPackage/phy-smsc > > SUBMENU:=$(NETWORK_DEVICES_MENU) > > TITLE:=SMSC PHY driver > > KCONFIG:=CONFIG_SMSC_PHY > > - DEPENDS:=+kmod-libphy > > + DEPENDS:=+kmod-libphy +!LINUX_5_15||!LINUX_6_1:kmod-lib-crc16 > I would prefer depending on 6.6 for the kmod, not the other way around. I am *very* strongly of the opposite opinion. Issue is detecting 5.15 and 6.1 is a stable state. At a future point when 6.10/6.11.6.12/7.0/7.1 are added, no additional maintenance is required if 5.15 and 6.1 are detected. Whereas if 6.6 is detected, this *must* be adjusted when the next kernel version shows up. The one advantage is by *forcing* maintenance sooner, the construct is likely to be removed sooner. Ultimately turns into an issue of which is more concerning, having this hang around longer, versus making this an urgent issue in the near future. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] scripts: create kernel configuration upgrade script
On Sat, Mar 23, 2024 at 07:56:01PM +0100, Stijn Segers wrote: > > Op zondag 3 maart 2024 om 15:24:50 -08:00:00 schreef Elliott Mitchell > : > > Date: Tue, 6 Feb 2024 17:16:41 -0800 > > > > Create a script for automating kernel version changes. This > > generates a pair of commits which cause history to remain attached to > > all versioned configuration files. > > > > Crucially this makes `git blame` work without needing > > --find-copies-harder, which is too slow for routine use. This also > > updates *everything*, which greatly simplifies rebasing patches > > which effect multiple devices. > > > > Credit to Christian Marangi who knew of the technique: > > <https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html> > > > > Signed-off-by: Elliott Mitchell > > > Is there a way to bump a specific target to a new kernel with your > script? It doesn't look like it, but I might be mistaken. Would it be a > lot of work to integrate that? With the shell equivalent being merged, > I can understand any reluctance to adding this functionality, but it's > worth asking. As originally written, no. I see significant advantages to that approach and it really is starting to look like the best balance. To add the ability to handle a single target, near trivial. To add the ability to do multiple target(s), very simple. To do this efficiently, still fairly simple. It does seem this list has become useless for patch submission, so it has been brought onto GitHub: https://github.com/openwrt/openwrt/pull/14907 -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sat, Mar 23, 2024 at 10:02:39PM +0100, Olliver Schinagl wrote: > On 23-03-2024 18:51, Elliott Mitchell wrote: > > On Sat, Mar 23, 2024 at 03:15:44AM +0100, Olliver Schinagl wrote: > > > >>> Odd thing about what you put in parentheses. I've been trying to get a > >>> discussion going about that for months, yet seems no one notices the > >>> suggestion. This was a distinct goal of the script, to hopefully get > >>> that discussion going. > >> > >> To update all targets at once? How is that useful?! > > > > Taking the unusual step of splitting a paragraph since that is needed > > in this case. > > > > I've cited two specific reasons in a recent message. I keep citing those > > reasons again and again and again. Yet get no response. > > > > This makes it *much* easier to change defaults in "generic". Instead of > > needing to touch a bunch of configurations with different versions, you > > can simply touch all configurations with one version. If you're unlucky > > and a new kernel cycle starts before approval or rejection, you can > > rebase one copy onto the rename commit and another onto the merge commit. > > You then rebase these on top of each other and then squash, the result is > > you're onto the latest with minimal trouble. Without this trying to > > modify values effecting multiple devices is an absolute nightmare > > (believe me, I know!). > > Hmm, afaik this is what openwrt does right now, the generic config is > applied to all targets, and you put your device specific configuration > in your platform config. This makes sense, because you don't want to > compile all drivers for all targets into your tiny router image, that is > restricted to 4MiB. > > So if there's something I'm missing, I do appologize :) Uh huh. If we were playing horseshoes with thermonuclear handgrenades, that response would get 0 points. You completely missed the point. Let me add another advantage of doing everything at once. The generated commits do not properly rebase. Rebasing retains much of the advantage, but degrades things. As such doing all the duplication in one event allows someone who can directly commit do the task for everyone *once* per update cycle (presently once per year). Device maintainers can then base off of that point and not worry about having non-rebasable commits. > >>> Then there are the things `kernel_upgrade.pl` can do which > >>> `kernel_bump.sh` has no equivalent. > >> > >> But what are they. And how are they relevant? > > > > You've been typing about how yours could upgrade everything by being > > called multiple times. Since I was aiming to get the above issue > > discussed `scripts/kernel_upgrade.pl` has featured the capability to > > update everything all at once, from the start. > > The kitchen sink :) But honestly, have that discussion first with the > maintainers. Hauke is already much against it; which I get. Having > worked on a few targets, they are so diverse, bumping two at once just > doesn't make sense (today!). I will not fully type up my viewpoint. Bisecting inherently involves heuristics. There may be an even number of changes between any two points, so bisecting involves arbitrarily choosing from a set. The `git bisect skip` command exists because it *cannot* be perfect. Meanwhile --find-copies-harder is sufficiently slow to call `git blame` effectively broken on OpenWRT. It is too slow to be used for most of its intended use cases. > > In fact only upgrading a single board was a feature which had to be > > added. Since I added fewer assumptions, mine makes no distinction > > between upgrading targets versus subtargets. It can do multiple of both > > at the same time without any restrictions and a single invocation. > > > > In the process, only 2 commits are generated. The under .5s is for > > updating *everything*. > > I have no idea how long it would take to update everything, but again, > the time factor is so irrelevant, it doesn't atter. Also, I too only > have 2 commits now, which until we get `git cp` will remain the minimum, > but more then a 'cp && git add'. I haven't tested, but isn't that simply abandoning the approach of having history on everything and resorting to only having history on the up to date version? I did think that was a viable approach, but it isn't what seemed to gain concensus. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sat, Mar 23, 2024 at 03:15:44AM +0100, Olliver Schinagl wrote: > > On March 21, 2024 10:28:29 p.m. GMT+01:00, Elliott Mitchell > wrote: > >On Thu, Mar 21, 2024 at 10:00:46AM +0100, Olliver Schinagl wrote: > >> On 20-03-2024 01:34, Elliott Mitchell wrote: > >> > On Mon, Mar 18, 2024 at 10:53:12AM +0100, Olliver Schinagl wrote: > >> >> I expect this to be done very rarely and by users that know what they > >> >> are doing, but just "automating" a few logical git commands. > >> >> > >> >> Performance is not a key-driver here. It's too rarely used. > >> > True, though being faster is nice. > >> > >> While true, I don't think we even have to start arguing if runtime is > >> less then a single second. This on my 12 year old PC, granted, the CPU > >> is only 8 years and the nvme SSD only 5. > >> > >> ./scripts/kernel_bump.sh -p realtek -s 5.15 -t 6.6 0,40s user 0,33s > >> system 105% cpu 0,694 total > >> > >> ./scripts/kernel_bump.sh -p ramips -s 6.1 -t 6.6 0,40s user 0,40s > >> system 106% cpu 0,753 total > >> > >> Even if you bumped all repo's (with a dumb for-loop) we'd be talking 30 > >> seconds to do _all_ of them at once (which never happens). > > > >On a computer of similar class, but with *much* slower storage > >(fileserver is sick and underperforming): real0m0.477s > > > >So if this was directly to an SSD, 2 orders of magnitude. > > Sure, but not significant in any way or form. Its still in both cases > significantly less then one second. The script has executed before my finger > has left the enter key. There is no purpose or advantage here. If the script > ran 10 seconds, it wouldn't even matter IMO. > True enough. Though I will cite this as an example of the care used in the design. > >Odd thing about what you put in parentheses. I've been trying to get a > >discussion going about that for months, yet seems no one notices the > >suggestion. This was a distinct goal of the script, to hopefully get > >that discussion going. > > To update all targets at once? How is that useful?! Taking the unusual step of splitting a paragraph since that is needed in this case. I've cited two specific reasons in a recent message. I keep citing those reasons again and again and again. Yet get no response. This makes it *much* easier to change defaults in "generic". Instead of needing to touch a bunch of configurations with different versions, you can simply touch all configurations with one version. If you're unlucky and a new kernel cycle starts before approval or rejection, you can rebase one copy onto the rename commit and another onto the merge commit. You then rebase these on top of each other and then squash, the result is you're onto the latest with minimal trouble. Without this trying to modify values effecting multiple devices is an absolute nightmare (believe me, I know!). This can also generate a single non-buildable commit per year. Whereas if every single device configuration is handled individually you generate >=44 non-buildable commits per year. This is the difference between <1% of `git bisect` sessions hitting a non-buildable commit, versus 5-15% of `git bisect` sessions hitting a non-buildable commit. Given how obsessed some people are with `git bisect`, this is a major advantage. >>If a target is fully upstream, there is nearly nothing to migrate, no patches >>etc. So maybe the kernel config. Sure expanding (either script) to accept >>multiple platforms would be trivial or accept a commit pair per platform >>andere just loop over the script fort each target. But this is something not >>feasible for decades to come. > > Bumping a kernel version pretty much always requires additional work. Config > migration, rebasing patches, testing on actual hardware. Its just not even > worth considering. > > Also, a quick note on skipping kernel versions, generally openwrt seems to > only support two versions at a time. You could have just a single one, or > skip 5. The problem/work, is adapting the target to actually function again. > Bigger jumps just means different/more work on the patches, but nothing else > really. > Were you aware the sky is most often perceived as being blue (clear sky), white (clouds), or black (night)? Were you aware Google is a very large company? Were you aware PI is a transcendental number approximately equal to 3.14? I don't dispute any of the above. I don't see how any of the above is related to whether it is better to copy kernel configurations and patches for all boards at once, versus copying them per-board. Without a doubt cop
Re: Purpose of openwrt-devel?
On Thu, Mar 21, 2024 at 10:00:46AM +0100, Olliver Schinagl wrote: > On 20-03-2024 01:34, Elliott Mitchell wrote: > > On Mon, Mar 18, 2024 at 10:53:12AM +0100, Olliver Schinagl wrote: > >> I expect this to be done very rarely and by users that know what they > >> are doing, but just "automating" a few logical git commands. > >> > >> Performance is not a key-driver here. It's too rarely used. > > True, though being faster is nice. > > While true, I don't think we even have to start arguing if runtime is > less then a single second. This on my 12 year old PC, granted, the CPU > is only 8 years and the nvme SSD only 5. > > ./scripts/kernel_bump.sh -p realtek -s 5.15 -t 6.6 0,40s user 0,33s > system 105% cpu 0,694 total > > ./scripts/kernel_bump.sh -p ramips -s 6.1 -t 6.6 0,40s user 0,40s > system 106% cpu 0,753 total > > Even if you bumped all repo's (with a dumb for-loop) we'd be talking 30 > seconds to do _all_ of them at once (which never happens). On a computer of similar class, but with *much* slower storage (fileserver is sick and underperforming): real0m0.477s So if this was directly to an SSD, 2 orders of magnitude. Odd thing about what you put in parentheses. I've been trying to get a discussion going about that for months, yet seems no one notices the suggestion. This was a distinct goal of the script, to hopefully get that discussion going. > >> Leaving the tree in failed state imo is a feature. We switch from the > >> normal branch to a special branch to do all operations. The user can > >> always force ably switch back. Ultimately, this is a choice, can a user > >> fix things and inspect failures, or 'oh it failed, lets reset'. Reset > >> instructions during cleanup is a good idea however. > > Therein lines a concern. Why does yours switch to a special branch? > > It is not human, it doesn't need a computer to keep track of commits for > > it. As such it shouldn't need a branch. > > Why is this a problem? Why can't a script that is intended to remove > manual labor, behave like a human. There comes the readability and > maintainability argument once again. If a human can read it, he can > modify it. If the script fails, or a special case pops up, a human can > do those steps manually quite easily. > > I'm a big beliver in KISS. So yes, the script is not perfect and doesn't > have shiney gold plated parts. But it is simple, can be understood by a > human, by a non-developer even I'd argue. > > In the end, computers do what humans tell them to do. In the end, humans > reading things is far more important, then super-optimizing a script, > that's run once or twice a year by a human developer. > > And using a branch does have its advantages too. We can switch to the > branch and examine if things go wrong. Again, this is something a human > would do too :) A human can tell `git` to move to an unreferenced commit. Useful to know how if things go wrong. Though I will admit by having your script be so close to things many people do, does make it more obvious to more people. Yet if that is an issue they should be looking at the URL where the approach came from and reading that. > > If you examine the result, you might also discover its approach has some > > rather substantial advantages. At this time I believe with the second > > commit it offers a proper superset of your script's functionality. > > > I wonder what this super set is though and why it is so badly needed ... Your knowledge level is showing. Given a Set A and Set B: Set A is a superset of Set B, if: For all elements 'b' of Set B, element 'b' is also an element of Set A. Set A is a subset of Set B, if: For all elements 'a' of Set A, element 'a' is also an element of Set B. Set A is a degenerate superset of Set B, if: Set A is a superset of Set B; and there is NO element 'a' of Set A, which is NOT also an element of Set B. (ie they're the same set) Set A is a proper superset of Set B, if: Set A is a superset of Set B; and there is at least one element 'a' of Set A, which is NOT an element of Set B. ``` git remote add ehem https://github.com/ehem/openwrt.git git remote set-branches ehem bumper script git fetch ehem git rebase ehem/bumper ehem/script ``` The UI approach for `kernel_upgrade.pl` is rather distinct from what `kernel_bump.sh` has. I'm unsure how closely what it does matches the behavior of your script. Yet the modified `kernel_bump.sh` performs similar to what you have, by invoking `kernel_upgrade.pl` once with appropriate arguments. Then there are the things `kernel_upgrade.pl` can do which `kernel_bump.sh` has no equivalent. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem
Re: Purpose of openwrt-devel?
On Mon, Mar 18, 2024 at 10:53:12AM +0100, Olliver Schinagl wrote: > I expect this to be done very rarely and by users that know what they > are doing, but just "automating" a few logical git commands. > > Performance is not a key-driver here. It's too rarely used. True, though being faster is nice. > Leaving the tree in failed state imo is a feature. We switch from the > normal branch to a special branch to do all operations. The user can > always force ably switch back. Ultimately, this is a choice, can a user > fix things and inspect failures, or 'oh it failed, lets reset'. Reset > instructions during cleanup is a good idea however. Therein lines a concern. Why does yours switch to a special branch? It is not human, it doesn't need a computer to keep track of commits for it. As such it shouldn't need a branch. This is one of the things I meant by "Your shell script is essentially replicating the actions a human at a shell might take to perform the task". Some things work better for a shell script than the approaches humans would use. Since I went to the trouble of examining your script and testing it, might you reciprocate with similar courtesy? Even if you cannot fill the role of reviewer, you can still fill the role of tester. If you examine the result, you might also discover its approach has some rather substantial advantages. At this time I believe with the second commit it offers a proper superset of your script's functionality. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sat, Mar 16, 2024 at 02:19:27PM +0800, Chuanhong Guo wrote: > > On Sat, Mar 16, 2024 at 11:41 AM Elliott Mitchell > wrote: > > > > Since `git fast-import` is a direct interface to Git's back-end, the > > > > working tree doesn't need to be modified to operate. This also means > > > > mine is *much* faster and can create precisely tailored commits. > > > > > Ah, but! ... here I go drudging about maintainabiility again. Others in > > > the future will also look at it and go like 'hmm, what is this for, and > > > why the complexity' ... > > > > Anyone needing to figure out how the scripts work will need a fair bit > > of familiarity with Git. Being able to get good results really does need > > some deep familiarity with Git's structures, at which point > > `git fast-import` isn't a big step further. > > And more comments on the perl thing: > A maintainer needs to be familiar with perl to review or take your > patches. I could probably vaguely understand what a perl script > is doing by quickly learning the syntax, but I can't decide > whether the script is good or not. > Nobody is explicitly NACKing your patch or saying it's worse > than the bash version just because it's written in perl. Maintainers > who don't understand perl simply don't have the knowledge to > judge the script, so the patch is left for others. If such a maintainer > doesn't show up, your patch won't be taken. It doesn't matter if > your script is superior or not. I must complain about being held to a very different standard than Olliver Schinagl was. Take a look at commit 3561015efd, and: https://github.com/openwrt/openwrt/pull/14713 I see no evidence of a full review, but it was brought into OpenWRT's repository. Several people took cursory looks and commented on the messages, but that isn't a full review. In particular my comment about the two loops on lines 111-131, . A proper review would have required changing those, since there is an obvious rather superior approach. The issue of potentially writing the directory at the same time as reading the directory is harder to spot. Problem is that means the script has at least one fundamental problem. I might suggest a bit of testing of mine, then bringing it in... Though despite bringing up the issue time and again, a key question still has no response. I'm not egotistical enough to claim that as implicit approval. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sun, Mar 17, 2024 at 11:44:45AM +0100, p...@oranjevos.nl wrote: > Op 16 mrt. 2024, om 07:46 heeft Elliott Mitchell het > volgende geschreven: > > On Sat, Mar 16, 2024 at 02:19:27PM +0800, Chuanhong Guo wrote: > >> > >> And more comments on the perl thing: > >> A maintainer needs to be familiar with perl to review or take your > >> patches. I could probably vaguely understand what a perl script > >> is doing by quickly learning the syntax, but I can't decide > >> whether the script is good or not. > >> Nobody is explicitly NACKing your patch or saying it's worse > >> than the bash version just because it's written in perl. Maintainers > >> who don't understand perl simply don't have the knowledge to > >> judge the script, so the patch is left for others. If such a maintainer > >> doesn't show up, your patch won't be taken. It doesn't matter if > >> your script is superior or not. > > > > That makes forward progress impossible. If it provides superior results > > then perhaps the thing which only one person understands is acceptable? > > As long as they maintain it, provide reasonable explanations and help > > others work on gaining proper understanding, isn't that good enough? > Ever considered to implement the kernel bumps based on 'git fast-import' in > sh script in stead of perl ? Well... The choice of Perl+fast-import was guided by my aims. I wanted to do as little as possible as possible to the working tree in order to reduce problems from someone trying the script in a dirty tree. For POSIX shell this simply isn't so advantageous. Unfortunately you've caused me to wonder about it a bit, so... First thoughts. Should be possible. This isn't nearly so fast or robust since fast-import is a *binary* protocol, *not* a text protocol. In particular it uses line-feeds, *not* newlines (subtle, but critical difference). Second thought. Pretty difficult. Perl was simple due to being able to open a pipe and leave it around stuck to a variable. Shell isn't really well-suited to this. Third thought. Above I was thinking of an approach similar to what I did with Perl. If instead a more traditional fast-import fixed stream approach was used, this is actually suitable for shell operation. So, yes indeed shell+fast-import is quite doable. I'm unsure of it being particularly advantageous. This would need a *bunch* of temporary files to hold intermediate work before merging everything together. My goal though was to do the job well, not to show off fast-import. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sat, Mar 16, 2024 at 02:19:27PM +0800, Chuanhong Guo wrote: > > On Sat, Mar 16, 2024 at 11:41 AM Elliott Mitchell > wrote: > > > > Anyone needing to figure out how the scripts work will need a fair bit > > of familiarity with Git. Being able to get good results really does need > > some deep familiarity with Git's structures, at which point > > `git fast-import` isn't a big step further. > > And more comments on the perl thing: > A maintainer needs to be familiar with perl to review or take your > patches. I could probably vaguely understand what a perl script > is doing by quickly learning the syntax, but I can't decide > whether the script is good or not. > Nobody is explicitly NACKing your patch or saying it's worse > than the bash version just because it's written in perl. Maintainers > who don't understand perl simply don't have the knowledge to > judge the script, so the patch is left for others. If such a maintainer > doesn't show up, your patch won't be taken. It doesn't matter if > your script is superior or not. That makes forward progress impossible. If it provides superior results then perhaps the thing which only one person understands is acceptable? As long as they maintain it, provide reasonable explanations and help others work on gaining proper understanding, isn't that good enough? As Paul D mentioned, thanks to version control, if things really break there is an escape route. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Sat, Mar 16, 2024 at 01:47:38PM +0800, Chuanhong Guo wrote: > On Sat, Mar 16, 2024 at 11:51 AM Elliott Mitchell > wrote: > > > > On Tue, Mar 12, 2024 at 09:11:23PM -0700, Elliott Mitchell wrote: > > > On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote: > > > > On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell > > > > wrote: > > > > > > > > > > Then there is technical discussion. > > > > > > > > > > A rather serious problem with how kernel version changes are handled > > > > > was > > > > > brought up. This eventually lead to: > > > > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > > > > > Which seemed to gain a consensus of being the best solution to the > > > > > problem. > > > > > > > > > > Due to this not being the easiest process to implement, I went and > > > > > created a script for automating the process: > > > > > https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html > > > > > While some negotiation was expected, nothing has happened. I was > > > > > expecting to need some adjustment to match other's development > > > > > environments, yet no problems have been found. > > > > > > > > > > Yet now, 8a9273d51e simply throws the consensus in the garbage. Why > > > > > was > > > > > something which there was consensus on ignored? Perhaps this mailing > > > > > list is now >99% ignored and people should no longer be directed here? > > > > > > > > It is not ignored, it was just a case where kernel 6.6 support was > > > > already done > > > > by the time we merged the kernel bump script that does the GIT magic to > > > > preserve the history and with multiple people working on 6.6 target > > > > support > > > > based of the same PR it was not practical to stall it any further. > > > > > > > > I expect further kernel bumps, both generic and target ones will use > > > > the script > > > > and preserve history but it will take some time to get everybody > > > > familiar with it. > > > > > > Fascinating. > > > > > > The original technique, which does not require scripting was suggested > > > Tue Oct 24 05:05:25 PDT 2023. Scripting isn't necessary. Scripting is a > > > good idea since it would be done on a regular basis. > > > > > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > > > > Stating this explicitly, the procedure can be done manually. The > > approach appeared to have concensus in October, while 8a9273d51e was > > originally done in January. Yet the pull and 8a9273d51e ignored this. > > > > Also needs to be stated, these don't survive rebasing. > > If that's the case, the approach isn't practical. Kernel bump can be quite > a heavy task and it usually takes a long time for reviewing and testing, > during which a rebase is unavoidable. Also, we currently apply every > patches and pull requests by rebasing instead of a real merge, so > the merge to preserve history on the old version will get dropped > anyway. This wasn't why I took the approach, but this suggests the approach used by my script is the right one. When it is time to update generic for the new kernel, have a maintainer run the script. All devices simultaneously get new configurations which are copies of their previous ones. After this point updates happen to both old and new configurations to keep them synchronized. As long as they remain identical they don't use any additional space in Git. Git doesn't store file/directory timestamps, so if they're identical their hashes are identical and they reference the same object. > > Rebasing won't > > preserve the merges and will thus loses the history on the old versions > > (better than losing it on the newer ones, but still...). > > I think that's OK. We never add a kernel version newer than the one used > in the next stable release before branching off, so the history of the old > versions live in the stable branches. > > Maybe we should just drop all the git magic for the history of old versions, > and make the kernel_bump script do a commit for git mv and another one > for copying it back. I think this is suboptimal, but vastly superior to completely losing history. > > Given the number of pulls which already miss the use, doing all boards at > > the
Re: Purpose of openwrt-devel?
On Tue, Mar 12, 2024 at 09:11:23PM -0700, Elliott Mitchell wrote: > On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote: > > On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell wrote: > > > > > > Then there is technical discussion. > > > > > > A rather serious problem with how kernel version changes are handled was > > > brought up. This eventually lead to: > > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > > > Which seemed to gain a consensus of being the best solution to the > > > problem. > > > > > > Due to this not being the easiest process to implement, I went and > > > created a script for automating the process: > > > https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html > > > While some negotiation was expected, nothing has happened. I was > > > expecting to need some adjustment to match other's development > > > environments, yet no problems have been found. > > > > > > Yet now, 8a9273d51e simply throws the consensus in the garbage. Why was > > > something which there was consensus on ignored? Perhaps this mailing > > > list is now >99% ignored and people should no longer be directed here? > > > > It is not ignored, it was just a case where kernel 6.6 support was already > > done > > by the time we merged the kernel bump script that does the GIT magic to > > preserve the history and with multiple people working on 6.6 target support > > based of the same PR it was not practical to stall it any further. > > > > I expect further kernel bumps, both generic and target ones will use the > > script > > and preserve history but it will take some time to get everybody > > familiar with it. > > Fascinating. > > The original technique, which does not require scripting was suggested > Tue Oct 24 05:05:25 PDT 2023. Scripting isn't necessary. Scripting is a > good idea since it would be done on a regular basis. > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html Stating this explicitly, the procedure can be done manually. The approach appeared to have concensus in October, while 8a9273d51e was originally done in January. Yet the pull and 8a9273d51e ignored this. Also needs to be stated, these don't survive rebasing. Rebasing won't preserve the merges and will thus loses the history on the old versions (better than losing it on the newer ones, but still...). Given the number of pulls which already miss the use, doing all boards at the same time really does seem the way to go. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Thu, Mar 14, 2024 at 11:35:15PM +0100, Olliver Schinagl wrote: > On 14-03-2024 01:50, Elliott Mitchell wrote: > > On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote: > >> > >> The actual code of course has nothing to do with the perl script, as you > >> right full say 'I know nothing of perl', as does probably most of the > >> development community by now. Which is sad for perl, but 'it is what it > >> is'. > >> > >> In no way was there any ill intent. I just wanted my kernel tree bump > >> for the realtek target, and didn't want to install, learn etc perl to > >> try things out. Sorry for that on my part. > > > > The real problem here is you made two critical errors in your handling > > of this. > > But we're only talking textual strings, English language. Maybe I came > up with nearly similar sounding things because a) English is not my > native language and b) I've seen this before 'somewhere on the internet. > So re-using your 'code' is a bit of a stretch. Or are you suggesting I > am plagarizing everybody with these words I am writing right here? They > where all used too. ChatGPT could have been used. Your code in itself, I > didn't use, or look at really. The fact that the same goof appeared in both is strongly suggestive it was copied, rather than being manually typed in. True, could be were both thinking `git rebase` when it was typed, but it is very suspicious. Those messages aren't that large of a portion of the script. Whereas the harm done by getting the script in quickly is quite large. > > The biggest difference between the two isn't the language choice, but > > the overall designs. Your shell script is essentially replicating the > > actions a human at a shell might take to perform the task (more or less > > precisely the actions suggested by the original source). As such you > > likely recognize all the commands used in the script. > > And that is exactly the point. Human's have to read the script, humans > have to understand the script. Readability (in this case, more on this > later) is the biggest and most crucial part, as readability (by humans) > goes nearly hand-in-hand with maintainability. Whereas due to better design, mine will likely last rather longer before needing maintenance. > > The real reason everyone was having a hard time understanding my script > > was not that it was written in Perl. > Yes it was :p perl syntax is godawful :) and adds a layer of complexity > around, what in the end are, shell commands. And that's the partial also > a problem in my opinion. Many people do not know perl, readability > becomes an issue, and thus also maintainability. Yes, someone can argue > the same for shell scripts and its tricky syntax hacks. Though I pride > myself (and thank shellcheck a lot) for attempting to write as readabile > scripts as possible. Perl heavily copies features and capabilities from shell scripting, but Perl itself is not a shell-scripting language. If you're thinking of it as shell-scripting then, yes it will be confusing. Further it really does have some major quirks. At least it didn't fundamentally change the language and library between v2 and v3... > > Since `git fast-import` is a direct interface to Git's back-end, the > > working tree doesn't need to be modified to operate. This also means > > mine is *much* faster and can create precisely tailored commits. > Ah, but! ... here I go drudging about maintainabiility again. Others in > the future will also look at it and go like 'hmm, what is this for, and > why the complexity' ... Anyone needing to figure out how the scripts work will need a fair bit of familiarity with Git. Being able to get good results really does need some deep familiarity with Git's structures, at which point `git fast-import` isn't a big step further. > > I had been estimating the shell script would be 2-4 orders of > > magnitude slower than my Perl script. I now see the flaw in this belief. > > I had been operating on the assumption the shell script was doing a > > roughly comparable job to the Perl script. Turns out the shell script > > *strictly* targets the kernel configuration files. Whereas the Perl > > script targets *all* kernel-related files. > > If I/we took an oversight, due share. But the script looks at any file > (or directory) that has the kernel version suffix. If you look at the > realtek tree, you'll config files, but also all the other usual suspects > and also some hidden in some subdirectories. So what 'all' files are you > referring too that are not part of this pattern and where overlooked? No, it does not. It looks at "target/linux//" for anythi
Re: Purpose of openwrt-devel?
On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote: > On 13-03-2024 08:46, Felix Baumann wrote: > > Am 13. März 2024 05:11:23 MEZ schrieb Elliott > > Mitchell: > >> I must challenge this. If patches via the mailing list were accepted, > >> then we should see things sent to the mailing list getting into the > >> repository. Yet many patches get no attention. Some get reviews from > >> various people, yet then never get into the main repository. > > It's the same for Github, some stuff doesn't get in and remains there. > > There might be a difference what kind of PRs are send to the mailing list > > and you get attention of different committers when sending to mailing list > > vs sending to Github. Github patches might be accepted more easily when > > it's just a new device for a well established target. > > > > I feel like patches on the mailing list are ignored, when committers don't > > have time for review or don't feel confident enough to do it well (not > > their field of expertise). Or if it's written in a language they don't feel > > confident reviewing. > > *PERSONALLY* I think mailing list reviews are on their way out. People > have found that there are easier and better ways. Granted, some folks > still _prefer_ mailing list reviews. *I PERSONALLY* do not at all. I > hate my mailbox being full with threads of stuff I have no attention for > at that moment, it just adds noise for me. And ignoring it for a while > just puts huge amounts of e-mails in my mailbox, that become useless > after a while. Though I much rather would like to see GitLab then GitHub > use :p but that's more the FOSS spirit, and avoiding anything Microsoft > where possible :p Mailing list reviews do have their moments. Notably I thought some parts might deserve wider discussion. Also by sending it here I was trying to engage with the person who originally found the solution. I am another person who is concerned about GitHub. The degree of copyright infringement by AI isn't known to be large, but there are hints of trouble on the horizon. Good news is Git is very much P2P and moving things between Git servers is easy. > > Huh. Parts of that look suspicious. Those commit messages look *very* > > similar to my version 2. I was jumping between documentation sources > > when writing it. > Not sure what is surprising to you, since the mail thread was listed in > the MR and your perl code was even referenced (not _directly_ I admit). > Obviously I was using your messaging format as that was discussed on the > mailing list and I didn't want to deviate from those messages, also they > made a lot of sense anyway. "Fair Use" if anything :p A Court of Law would need to decide Fair Use, but I'm pretty sure this would fail. Good news is this isn't enough to bother. > The actual code of course has nothing to do with the perl script, as you > right full say 'I know nothing of perl', as does probably most of the > development community by now. Which is sad for perl, but 'it is what it is'. > > In no way was there any ill intent. I just wanted my kernel tree bump > for the realtek target, and didn't want to install, learn etc perl to > try things out. Sorry for that on my part. The real problem here is you made two critical errors in your handling of this. First, credit the original author for everything. Open source depends heavily on reputation so letting people know doing this as a script was my idea has high value to me. I take the above as an apology, so there there is little to do, besides drop this portion. Second, I knew nothing of https://github.com/openwrt/openwrt/pull/14713 until yesterday and Robert Marko mentioning something, triggering me to go searching: https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042423.html Had I known of the pull earlier I would have gone to #14713, but I had no idea the discussion had been diverted away to GitHub. In light of this, I think the qualities of the two scripts and their merits should be considered. One item I was trying to draw attention to was perhaps the current approach to handling kernel version changes isn't very good. If you're trying to change configuration which effects multiple devices, you end up having to *constantly* watch out for configuration files appearing and disappearing. This is painful to deal with. This has the useful advantage of producing fewer merge commits. Instead of 44 merges/kernel version, there would be only 1. I estimate OpenWRT is doing around 3000 commits/year, so this is 1.5% versus 0.03% commit merges. If a typical bisect session touches 12 commits then this is 16.5% versus 0.45% encountering a merge. Then there are sessions which encounter 2+ merges. The biggest diffe
Re: Purpose of openwrt-devel?
On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote: > On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell wrote: > > > > Well, what purpose does the openwrt-devel mailing list serve? > > > > As near as I can tell it looks suspiciously like it is a method to divert > > developers from where everything is done. There isn't too much review > > activity. Anything which does get a positive review tends to simply > > disappear unless it is later resubmitted via GitHub. > > > > According to https://openwrt.org/submitting-patches patch submission via > > GitHub or the openwrt-devel mailing list can be done. The amount of text > > seems to suggest the mailing list is preferred. Yet, can anyone cite a > > single patch which was sent to the mailing list, reviewed positively and > > brought into the main branch without resubmitting via GitHub? > Both methods of submitting changes are accepted. I must challenge this. If patches via the mailing list were accepted, then we should see things sent to the mailing list getting into the repository. Yet many patches get no attention. Some get reviews from various people, yet then never get into the main repository. > > Then there is technical discussion. > > > > A rather serious problem with how kernel version changes are handled was > > brought up. This eventually lead to: > > https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html > > Which seemed to gain a consensus of being the best solution to the > > problem. > > > > Due to this not being the easiest process to implement, I went and > > created a script for automating the process: > > https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html > > While some negotiation was expected, nothing has happened. I was > > expecting to need some adjustment to match other's development > > environments, yet no problems have been found. > > > > Yet now, 8a9273d51e simply throws the consensus in the garbage. Why was > > something which there was consensus on ignored? Perhaps this mailing > > list is now >99% ignored and people should no longer be directed here? > > It is not ignored, it was just a case where kernel 6.6 support was already > done > by the time we merged the kernel bump script that does the GIT magic to > preserve the history and with multiple people working on 6.6 target support > based of the same PR it was not practical to stall it any further. > > I expect further kernel bumps, both generic and target ones will use the > script > and preserve history but it will take some time to get everybody > familiar with it. Fascinating. The original technique, which does not require scripting was suggested Tue Oct 24 05:05:25 PDT 2023. Scripting isn't necessary. Scripting is a good idea since it would be done on a regular basis. https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html My second revision was visible Wed Feb 7 13:32:19 PST 2024. This version *needed* some discussion. Parts of what it produces are different from the way things had been previously done. I think this is a major improvement, but it did need discussion (and testing). https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html My third revision was visible Sun Mar 3 15:24:50 PST 2024. It had been ready for *weeks*, but I had been expecting more feedback. https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042405.html Now that I've found what you're refering to: https://github.com/openwrt/openwrt/pull/14713 AuthorDate: 2024-02-23 13:54:48 Huh. Parts of that look suspicious. Those commit messages look *very* similar to my version 2. I was jumping between documentation sources when writing it. Quoting my version: --8<-8<-- If you see this commit during a `git bisect` session, the recommended course of action is to run `git bisect --skip`. --8<-8<-- Whereas the "bumper script": --8<-8<-- During a `git bisect` session, `git bisect --skip` is recommended. --8<-8<-- Now when writing mine I was thinking of `git rebase --skip`, yet for `git bisect` the command is `git bisect skip`. Odd that precisely the same thinko occured in both. Quite a few other messages look like rewrites of mine too. I'm pretty sure an attorney would advise against filing a lawsuit. There amount which looks copied seems unlikely to get much. On the flip side that looks copied enough that I suspect the OpenWRT organization should have asked for a
Purpose of openwrt-devel?
Well, what purpose does the openwrt-devel mailing list serve? As near as I can tell it looks suspiciously like it is a method to divert developers from where everything is done. There isn't too much review activity. Anything which does get a positive review tends to simply disappear unless it is later resubmitted via GitHub. According to https://openwrt.org/submitting-patches patch submission via GitHub or the openwrt-devel mailing list can be done. The amount of text seems to suggest the mailing list is preferred. Yet, can anyone cite a single patch which was sent to the mailing list, reviewed positively and brought into the main branch without resubmitting via GitHub? Then there is technical discussion. A rather serious problem with how kernel version changes are handled was brought up. This eventually lead to: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html Which seemed to gain a consensus of being the best solution to the problem. Due to this not being the easiest process to implement, I went and created a script for automating the process: https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html While some negotiation was expected, nothing has happened. I was expecting to need some adjustment to match other's development environments, yet no problems have been found. Yet now, 8a9273d51e simply throws the consensus in the garbage. Why was something which there was consensus on ignored? Perhaps this mailing list is now >99% ignored and people should no longer be directed here? If action is taken quickly, the breakage in 8a9273d51e might be mostly fixed. Check out 71360660e6, use the script to do an update and check out the result. Then run `git merge --no-commit main` and then run `git commit --amend`. I *think* this should generate the correct result (squashing two merge commits together, creating a 3-way merge). Yet in the end, does this mailing list continue to serve any purpose what-so-ever? Perhaps I should just give up and opt for Alpine instead. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] scripts: create kernel configuration upgrade script
Date: Tue, 6 Feb 2024 17:16:41 -0800
Create a script for automating kernel version changes. This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.
Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use. This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.
Credit to Christian Marangi who knew of the technique:
<https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html>
Signed-off-by: Elliott Mitchell
---
v3:
Dust off knowledge of PerlOO. Confine the fast-importer interface
to an object.
Better layer the lowest I/O layer. If fast-import grows a \0 command
separation mode, we should be mostly ready (issue will be the commit
message).
Switch to SPDX. Try to match what the other scripts have.
I was kind of hoping for more review activity, the near-silence is
almost deafening. Using a script to handle this job seems best. I
feel what this script produces is rather easier for most developers
to handle.
v2:
Major tweaking. No longer try to do `git merge --ff-only `,
but instead advise user to do so.
Add usage message.
Add statement about strategy.
Adjust commit messages. Add advice to run `git bisect skip` if
someone ends up on that commit.
---
scripts/kernel_upgrade.pl | 280 ++
1 file changed, 280 insertions(+)
create mode 100755 scripts/kernel_upgrade.pl
diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..c2e5fb6078
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,280 @@
+#!/usr/bin/env perl
+#
+# SPDX-License-Identifier: GPL-3.0-or-later#
+# #
+# Copyright (C) 2024 Elliott Mitchell#
+#
+
+use warnings;
+use strict;
+
+#
+# I'm not certain the technique originated here, but this comes from:
+# <https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904>
+#
+# Problem is copying a file in git causes the new file to be created
+# without any history. Files can move around without losing their
+# history, but that only leaves the history on the new location.
+#
+# As such this can be solved with two commits. The first commit moves
+# files from their old name to their new name. The second merges the
+# original commit with the rename commit. The merge commit then has
+# files in both locations with the full history.
+#
+#
+# Note, git handles discarded data by garbage collection. When doing
+# development on this script, beware this script is an excellent
+# garbage generator. Frequent use of `git gc` and `git prune` may be
+# needed.
+#
+
+
+sub gethead()
+{
+ open(my $fd, '-|', 'git', 'rev-parse', 'HEAD');
+ $_=<$fd>;
+ chop;
+ return $_;
+}
+
+sub getlist($$)
+{
+ my ($target, $from)=@_;
+ my $ret=[];
+
+ local $/="\0";
+ open(my $fd, '-| :raw :bytes', 'git', 'ls-tree', '-trz', '--full-name',
+'--name-only', 'HEAD', '--', $target)||die("failed to read git tree");
+
+ while(<$fd>) {
+ chop($_);
+ push(@$ret, substr($_, 0, -length($from)))
+if(substr($_, -length($from)) eq $from);
+ }
+
+ @$ret=sort({length($b)-length($a)} @$ret);
+
+ return $ret;
+}
+
+{ # start of interface to git fast-import
+package GitImporter;
+
+# git fast-import's protocol uses *linefeeds*
+local $/="\n";
+
+sub new()
+{
+ my $class=shift;
+ my $self={};
+ my @child;
+ (pipe($child[0], $self->{out})&($self->{in}, $child[1])) ||
+die("pipe() failed");
+ binmode($self->{out});
+ binmode($self->{in});
+
+ $self->{pid}=fork();
+ if($self->{pid}==0) {
+ close($self->{out});
+ close($self->{in});
+
+ open(STDIN, '<&', $child[0]);
+ close($child[0]);
+
+ open(STDOUT, '>&', $child[1]);
+ close($child[1]);
+
+ exec('git', 'fast-import', '--done');
+ die('exec() of git failed');
+ } elsif(!$self->{pid}) {
+ die('fork() failed');
+ }
+ close($child[0]);
+ close($child[1]);
+ $self->{out}->autoflush(1);
+
+ return bless($self, $class);
+}
+
+sub send($)
+{
+ my $self=shift;
+ my ($data)=@_;
+ return print({$self->{out}} $data);
+}
+
+sub putcmd($)
+{
+ my $self=shift;
+ my ($data)=@_;
+ return $self->send("$data\n");
+}
+
+sub recv()
+{
+ my $self=shift;
+ return $_=readline($self->{in});
+}
+
+sub getr
Re: [PATCH v2] scripts: create kernel configuration upgrade script
On Wed, Feb 14, 2024 at 10:03:00AM +0100, Rafał Miłecki wrote: > On 7.02.2024 02:16, Elliott Mitchell wrote: > > diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl > > new file mode 100755 > > index 00..b9fe5882a3 > > --- /dev/null > > +++ b/scripts/kernel_upgrade.pl > > @@ -0,0 +1,261 @@ > > +#!/usr/bin/env perl > > +##### > > +# Copyright (C) 2024 Elliott Mitchell > > # > > +# # > > +# This is free software, licensed under the GNU General Public License > > # > > +# v3. See /LICENSE for more information. # > > +# > > OpenWrt is GPL 2.0 licensed. This this is GPL 3.0 only. > > It seems to be independent script (right now) but: > 1. What if one day we make it share some common code? Then you have GPLv3. Question is whether the common portion comes from this script? If yes, then we consider LGPL versus everything being GPLv3. This seems pretty unlikely as this is a rather specific task. `git fast-import` isn't likely to be useful in very many places. Also, `git` isn't something I would expect to see on a 128MB RAM device. > 2. What about using it to produce GPL 2.0 code? This is very well-understood. GPL applies to source code and the tools. GIMP is routinely used to produce non-GPL images. `git` is now used by MS for handling their source code, most of it remains non-GPL and no lawsuits have resulted. GCC is routinely used to build non-GPL software. Anything not directly linked in is completely uneffected. In particular while it does manipulate git's data, none of that is linked into the script and therefore has no license effects. This won't have any particularly notable effects. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] scripts: create kernel configuration upgrade script
On Tue, Feb 06, 2024 at 05:16:41PM -0800, Elliott Mitchell wrote: > Create a script for automating kernel version changes. This > generates a pair of commits which cause history to remain attached to > all versioned configuration files. > > Crucially this makes `git blame` work without needing > --find-copies-harder, which is too slow for routine use. This also > updates *everything*, which greatly simplifies rebasing patches > which effect multiple devices. Seems I goofed and should have Cc'd Christian Marangi when sending this. The script seems to work fine. One remaining issue is whether any adjustment to the commit messages on the generated commits is desired. I'm unsure they need "Signed-off-by" since they're tool-generated. I also wonder whether the script should claim to be the author. The one difference is this does all kernel configs in one pass. This seems superior as it makes rebasing proposed patches *much* simpler. Specifically there is far less update work without continuously appearing and disappearing configs. This also means only a single commit per year which troubles bisecting. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] scripts: create kernel configuration upgrade script
Create a script for automating kernel version changes. This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.
Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use. This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.
Signed-off-by: Elliott Mitchell
---
v2:
Major tweaking. No longer try to do `git merge --ff-only `,
but instead advise user to do so.
Add usage message.
Add statement about strategy.
Adjust commit messages. Add advice to run `git bisect --skip` if
someone ends up on that commit.
---
scripts/kernel_upgrade.pl | 261 ++
1 file changed, 261 insertions(+)
create mode 100755 scripts/kernel_upgrade.pl
diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..b9fe5882a3
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,261 @@
+#!/usr/bin/env perl
+#
+# Copyright (C) 2024 Elliott Mitchell#
+# #
+# This is free software, licensed under the GNU General Public License #
+# v3. See /LICENSE for more information. #
+#
+
+use warnings;
+use strict;
+
+use feature 'state';
+
+use Digest::SHA qw(sha1_hex);
+
+#
+# Credit to the person who knew about this workable solution:
+# <https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html>
+#
+# Which originated from:
+# <https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904>
+#
+# Problem is copying a file in git causes the new file to be created
+# without any history. Files can move around without losing their
+# history, but that only leaves the history on the new location.
+#
+# As such this can be solved with two commits. The first commit moves
+# files from their old name to their new name. The second merges the
+# original commit with the rename commit. The merge commit then has
+# files in both locations with the full history.
+#
+#
+# Note, git handles discarded data by garbage collection. When doing
+# development on this script, beware this script is an excellent
+# garbage generator. Frequent use of `git gc` and `git prune` may be
+# needed.
+#
+
+
+sub gethead()
+{
+ open(my $fd, '-|', 'git', 'rev-parse', 'HEAD');
+ $_=<$fd>;
+ chop;
+ return $_;
+}
+
+sub getlist($$)
+{
+ my ($target, $from)=@_;
+ my $ret=[];
+
+ local $/="\0";
+ open(my $fd, '-| :raw :bytes', 'git', 'ls-tree', '-trz', '--full-name',
+'--name-only', 'HEAD', '--', $target)||die("failed to read git tree");
+
+ while(<$fd>) {
+ chop($_);
+ push(@$ret, substr($_, 0, -length($from)))
+if(substr($_, -length($from)) eq $from);
+ }
+
+ @$ret=sort({length($b)-length($a)} @$ret);
+
+ return $ret;
+}
+
+# start of interface to git fast-import
+my $gitpid;
+my $gitfds=[undef, undef];
+
+sub startgit()
+{
+ my $child=[];
+ (pipe($child->[0], $gitfds->[0])&($gitfds->[1], $child->[1])) ||
+die("pipe() failed");
+ binmode($gitfds->[0]);
+ binmode($gitfds->[1]);
+
+ $gitpid=fork();
+ if($gitpid==0) {
+ close($gitfds->[0]);
+ close($gitfds->[1]);
+
+ open(STDIN, '<&', $child->[0]);
+ close($child->[0]);
+
+ open(STDOUT, '>&', $child->[1]);
+ close($child->[1]);
+
+ exec('git', 'fast-import', '--done');
+ die('exec() of git failed');
+ } elsif(!$gitpid) {
+ die('fork() failed');
+ }
+ close($child->[0]);
+ close($child->[1]);
+ $gitfds->[0]->autoflush(1);
+
+}
+
+sub gitsend
+{
+ return print({$gitfds->[0]} @_);
+}
+
+sub gitrecv()
+{
+ return $_=readline(${$gitfds}[1]);
+}
+
+sub gitls($$)
+{
+ my ($commit, $name)=@_;
+ local $/="\n";
+
+ $commit.=' ' if($commit);
+ gitsend("ls $commit$name\n");
+ gitrecv();
+
+ die('git ls failed') unless(/^([0-8]+)\s+[a-z]+\s+([0-9a-z]+)\s+.+$/);
+
+ return [$1, $2];
+}
+
+sub gitcommit($$$)
+{
+ my ($dest, $message, $mark)=@_;
+ local $/="\n";
+ local $|=1;
+ state $author=undef;
+ unless($author) {
+ $author=['', ''];
+ open(my $user, '-|', 'git', 'config', '--get', 'user.name');
+ while(<$user>) {
+ chomp;
+ $author->[0].=$_;
+ }
+ $author->[0]=[split(
Re: [PATCH 1/1] scripts: create kernel configuration upgrade script
On Wed, Feb 07, 2024 at 11:53:55AM +0100, Jonas Gorski wrote: > On Wed, 7 Feb 2024 at 02:48, Elliott Mitchell wrote: > > > > Create a script for automating kernel version changes. This > > generates a pair of commits which cause history to remain attached > > to all versioned configuration files. > > Why is this script needed? What exactly does it do? Does it preserve > bisectability? How would you use it? I see neither a help message nor > any usage examples. > > Please provide more detailed explanation in the commit message, > especially since perl isn't the most common or easy to read language. Hmm, true. This might be closer to PoC/WIP status since I was under major time pressure. I rather urgently wanted to get this out *before* the 6.6 configs were added. Use is supposed to be fairly simple: ``` scripts/kernel_upgrade.pl 6.1 6.6 git merge --ff-only ``` The script is *meant* to take care of that second step, but git has so far been refusing to do that in an automated fashion. People wanting to test could instead create a temporary branch at the specified commit and examine whether they like the result. On Wed, Feb 07, 2024 at 01:33:11PM +0100, Jonas Gorski wrote: > On Wed, 7 Feb 2024 at 12:58, Felix Baumann via openwrt-devel > wrote: > > > > This might be of help > > <https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html> > > Elliott linked it in his previous mail. > > > > It explains the problem fairly well. > > > > Short version: > > Right now every new kernel version creates a new kernel config file as a > > copy of the old one which doesn't preserve the git history which hinders > > the usage of git blame. > > I'm aware of the discussion, my point is that the information / > context should to be in the commit description, not in an external > place with no reference to it. If someone not aware of the email > thread looks at the commit I doubt they will be able to understand the > issue this is trying to solve, or how it is solving it. And since > neither the issue, the solution, nor the script itself are trivial all > three need some sort of explanation in the commit message. I'll see about some updating. > FWIW, git blame also supports a find copies harder (-C) that can > detect copies, not just delete/adds as renames (can be passed multiple > times for even harder finding). Unfortunately it's rather slow and > does not work as well as other git command's find copies harder. Not > sure why. Might be worth investigating. Rather slow is an understatement. More than an order of magnitude slower. This is the difference between something where you can freely run the command if you're curious about something you notice. Versus something you can occasionally start when you urgently need to examine a major oddity, but then go off taking a coffee, tea, or other break while waiting for the result. Right now `git blame` is too slow to be useful in many places where it should be used. > > git bisect should still work fairly well even without the change. > > What does "fairly well" mean? Either this produces commits that work, > or it produces commits that break the build. There is no in between. Due to the method, inherently a single non-buildable commit is created. If `git bisect` lands on that, you will need to run `git bisect --skip` to continue the bisect process. The commit message could readily be modified to state this. I conservatively estimate OpenWRT is generating around 3000 commits per year. If the kernel version changes once per year, then there is a 0.03% chance of landing on the commit. If your typical bisect session touches 12 commits (this seems excessive) then 0.2% of your bisect sessions will hit these. While infinitely greater than zero, that is a worthy trade for making `git blame` functional on configuration files. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] scripts: create kernel configuration upgrade script
Create a script for automating kernel version changes. This
generates a pair of commits which cause history to remain attached
to all versioned configuration files.
Signed-off-by: Elliott Mitchell
---
scripts/kernel_upgrade.pl | 191 ++
1 file changed, 191 insertions(+)
create mode 100755 scripts/kernel_upgrade.pl
diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..6cebaec201
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,191 @@
+#!/usr/bin/env perl
+#
+# Copyright (C) 2024 Elliott Mitchell
+#
+# This is free software, licensed under the GNU General Public License v3.
+# See /LICENSE for more information.
+#
+
+use warnings;
+use strict;
+
+use feature 'state';
+
+die("wrong number of arguments") if(@ARGV!=2);
+
+my $start;
+
+my ($from, $to)=@ARGV;
+
+sub load()
+{
+ my $ret=[];
+
+ open(my $fd, '-|', 'git rev-parse HEAD');
+ $start=<$fd>;
+ chop($start);
+
+ local $/="\0";
+ open($fd, '-| :raw :bytes', "git ls-tree -trz --full-name --name-only
HEAD -- target/linux")||die("failed to read git tree");
+
+ while(<$fd>) {
+ chop($_);
+ push(@$ret, substr($_, 0, -length($from))) if(substr($_,
-length($from)) eq $from);
+ }
+
+ @$ret=sort({length($b)-length($a)} @$ret);
+
+ return $ret;
+}
+
+my $gitpid;
+my $gitfds=[undef, undef];
+
+sub startgit()
+{
+ my $child=[];
+ (pipe($child->[0], $gitfds->[0])&($gitfds->[1], $child->[1])) ||
+die("pipe() failed");
+ binmode($gitfds->[0]);
+ binmode($gitfds->[1]);
+
+ $gitpid=fork();
+ if($gitpid) {
+ close($child->[0]);
+ close($child->[1]);
+ $gitfds->[0]->autoflush(1);
+ } elsif($gitpid==0) {
+ close($gitfds->[0]);
+ close($gitfds->[1]);
+
+ open(STDIN, '<&', $child->[0]);
+ close($child->[0]);
+
+ open(STDOUT, '>&', $child->[1]);
+ close($child->[1]);
+
+ exec('git', 'fast-import', '--done');
+ die('exec() of git failed');
+ } else {
+ die('fork() failed');
+ }
+}
+
+sub gitsend
+{
+ return print({$gitfds->[0]} @_);
+}
+
+sub gitrecv()
+{
+ return $_=readline(${$gitfds}[1]);
+}
+
+sub gitls($$)
+{
+ my ($commit, $name)=@_;
+ local $/="\n";
+ gitsend("ls $commit $name\n");
+ gitrecv();
+
+ die('git ls failed') unless(/^([0-8]+)\s+[a-z]+\s+([0-9a-z]+)\s+.+$/);
+
+ return [$1, $2];
+}
+
+sub gitcommit()
+{
+ my ($dest, $message, $mark, $branch)=@_;
+ local $/="\n";
+ local $|=1;
+ state $author=undef;
+ unless($author) {
+ $author=['', ''];
+ open(my $user, '-|', 'git', 'config', '--get', 'user.name');
+ while(<$user>) {
+ chomp;
+ $author->[0].=$_;
+ }
+ $author->[0]=[split(/,/, [getpwuid($<)]->[6])]->[0]
unless($author->[0]);
+
+ open(my $email, '-|', 'git', 'config', '--get', 'user.email');
+ while(<$email>) {
+ chomp;
+ $author->[1].=$_;
+ }
+ $author->[1]='anonym...@example.com' unless($author->[1]);
+
+ $author=$author->[0].' <'.$author->[1].'>';
+ }
+ gitsend("commit $branch\n");
+ gitsend("mark $mark\n");
+ gitsend("committer $author ".time()." +\n");
+
+ $_=length($message);
+ gitsend("data $_\n");
+ gitsend($message);
+ gitsend("from $dest\n");
+}
+
+sub gitdone()
+{
+ local $/="\n";
+ gitsend("done\n");
+ close($gitfds->[0]);
+ $gitfds->[0]=undef;
+ 0 while(waitpid($gitpid, 0) != $gitpid);
+ print(STDERR "WARNING: git returned error exit status\n") if($?);
+ close($gitfds->[1]);
+ $gitfds->[1]=undef;
+}
+
+my $list=load();
+
+die("no files matching \"$from\" found") unless(@$list);
+
+startgit();
+
+
+gitcommit($start, <<"__TMP__", ':1', 'tmp');
+kernel: add configs and patches for $to
+
+Copy the configuration and patches from $from to $to.
+
+This is a special tool-generated commit.
+__TMP__
+
+foreach my $name (@$list) {
+ my $new=gitls($start, "$name$from");
+ gitsend("M $new->[0] $new->[1] $name$to\n");
+ gitsend("D $name$from\n");
+}
+gitsend("\n");
+
+
+gitcommit(':1', <<"__TMP__", ':2', "end");
+
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On Sat, Feb 03, 2024 at 11:21:45AM -0800, Elliott Mitchell wrote:
> On Sat, Feb 03, 2024 at 01:06:13PM +0100, Hauke Mehrtens wrote:
> >
> > Which kernel should we use for the next major OpenWrt release?
> > We have two options and I would like to get some feedback on these:
>
> Since this means the main branch will likely be moving to 6.6 soon, I
> would like to point back to this message:
>
> https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html
>
> After a few versions, `git blame` on the configuration files should
> become rather more valuable. This could be automated with the use of
> Perl and some of Git's interesting functionality.
>
>
> I would like to see this done for *everything* all in one go. Problem is
> with the current system, configuration files are constantly appearing and
> disappearing. This is a nightmare for trying to change default options
> (such as target/linux/generic currently has CONFIG_HW_RANDOM=n).
>
> As such I would suggest the copy step should be done for *all* devices
> at the same time. The changing of the default could then rebase onto
> the intermediate commit to ensure coverage of everything. It is much
> simpler to handle conflicts when particular devices decide to delete
> older configurations.
I had been thinking it was possible. Seems I really did have the
knowledge needed, so I have successfully created a mostly working script.
This should be attached to this message, but will also be doing out to
the list as a follow-up.
I haven't quite fully debugged this yet. Git's fast-import functionality
has some quirks. This was meant to update the current branch, but seems
the fast-import process may be exiting before everything has been fully
written to storage. As such you will likely need to run
`git merge --ff-only ` after the script is run.
This is *not* quite 100%, but it does work.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>From 41e9cda304814eca2066a87cf2477c83933358f7 Mon Sep 17 00:00:00 2001
Message-Id: <41e9cda304814eca2066a87cf2477c83933358f7.1707269880.git.ehem+open...@m5p.com>
In-Reply-To:
References:
From: Elliott Mitchell
Date: Tue, 6 Feb 2024 17:16:41 -0800
Subject: [PATCH 1/1] scripts: create kernel configuration upgrade script
To: Hauke Mehrtens
Cc: OpenWrt Development List
Create a script for automating kernel version changes. This
generates a pair of commits which cause history to remain attached
to all versioned configuration files.
Signed-off-by: Elliott Mitchell
---
scripts/kernel_upgrade.pl | 191 ++
1 file changed, 191 insertions(+)
create mode 100755 scripts/kernel_upgrade.pl
diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..6cebaec201
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,191 @@
+#!/usr/bin/env perl
+#
+# Copyright (C) 2024 Elliott Mitchell
+#
+# This is free software, licensed under the GNU General Public License v3.
+# See /LICENSE for more information.
+#
+
+use warnings;
+use strict;
+
+use feature 'state';
+
+die("wrong number of arguments") if(@ARGV!=2);
+
+my $start;
+
+my ($from, $to)=@ARGV;
+
+sub load()
+{
+ my $ret=[];
+
+ open(my $fd, '-|', 'git rev-parse HEAD');
+ $start=<$fd>;
+ chop($start);
+
+ local $/="\0";
+ open($fd, '-| :raw :bytes', "git ls-tree -trz --full-name --name-only HEAD -- target/linux")||die("failed to read git tree");
+
+ while(<$fd>) {
+ chop($_);
+ push(@$ret, substr($_, 0, -length($from))) if(substr($_, -length($from)) eq $from);
+ }
+
+ @$ret=sort({length($b)-length($a)} @$ret);
+
+ return $ret;
+}
+
+my $gitpid;
+my $gitfds=[undef, undef];
+
+sub startgit()
+{
+ my $child=[];
+ (pipe($child->[0], $gitfds->[0])&($gitfds->[1], $child->[1])) ||
+die("pipe() failed");
+ binmode($gitfds->[0]);
+ binmode($gitfds->[1]);
+
+ $gitpid=fork();
+ if($gitpid) {
+ close($child->[0]);
+ close($child->[1]);
+ $gitfds->[0]->autoflush(1);
+ } elsif($gitpid==0) {
+ close($gitfds->[0]);
+ close($gitfds->[1]);
+
+ open(STDIN, '<&', $child->[0]);
+ close($child->[0]);
+
+ open(STDOUT, '>&', $child->[1]);
+ close($child->[1]);
+
+ exec('git', 'fast-import', '--done');
+ die('exec() of git failed');
+ } else {
+ die('fork() failed');
+ }
+}
+
+sub gitsend
+{
+ return print({$gitfds->[0]} @_);
+}
+
+sub gitrecv()
+{
+ return $_=readline(${$gitfds}[1]);
+}
+
+sub gitls($$)
+{
+ my ($commit, $name)=@_;
+ local $/="\n";
+ gitsend("ls $commit $name\n");
+ gitrecv
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On Sat, Feb 03, 2024 at 01:06:13PM +0100, Hauke Mehrtens wrote: > > Which kernel should we use for the next major OpenWrt release? > We have two options and I would like to get some feedback on these: Unless it turns out there is a pattern of people in favor of 6.1 needing longer to respond, there seems to be a consensus on 6.6. Since this means the main branch will likely be moving to 6.6 soon, I would like to point back to this message: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html After a few versions, `git blame` on the configuration files should become rather more valuable. This could be automated with the use of Perl and some of Git's interesting functionality. I would like to see this done for *everything* all in one go. Problem is with the current system, configuration files are constantly appearing and disappearing. This is a nightmare for trying to change default options (such as target/linux/generic currently has CONFIG_HW_RANDOM=n). As such I would suggest the copy step should be done for *all* devices at the same time. The changing of the default could then rebase onto the intermediate commit to ensure coverage of everything. It is much simpler to handle conflicts when particular devices decide to delete older configurations. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/1] kernel/x86: merge "generic" into "legacy"
On Tue, Jan 02, 2024 at 04:44:04PM -0800, Elliott Mitchell wrote: > There is a desire to reduce the time spent on x86 OpenWRT platforms. > "generic" is most suitable for removal. The few systems which could > use "generic" must now opt for "legacy" (or for a lucky few "64"). In case it wasn't obvious, I simply grabbed everything in "generic"'s config-6.1 file and merged it into the "legacy" version. I did a little bit of filtering, alas I definitely missed some crucial bits. OTOH some of the things which had gotten into the "generic" config-6.1 file seem revealing... > diff --git a/target/linux/x86/legacy/config-6.1 > b/target/linux/x86/legacy/config-6.1 > index d4b05e4642..325909c409 100644 > --- a/target/linux/x86/legacy/config-6.1 > +++ b/target/linux/x86/legacy/config-6.1 > @@ -92,35 +113,91 @@ CONFIG_DRM_RADEON=y > CONFIG_DRM_SCHED=y > CONFIG_DRM_TTM=y > CONFIG_DRM_TTM_HELPER=y > +CONFIG_DRM_VIRTIO_GPU=y > CONFIG_DRM_VRAM_HELPER=y > +CONFIG_EFI=y > +CONFIG_EFIVAR_FS=m I'm unsure about this. I don't know whether any P4s actually had EFI firmware. According to the handy resource, initial versions of EFI were out by 2004 so some P4s might have had EFI. I never touched them due to their terrible characteristics so I don't actually know. > +CONFIG_HIGHMEM64G=y > +CONFIG_HOTPLUG_CPU=y > +CONFIG_HOTPLUG_PCI=y > +CONFIG_HOTPLUG_PCI_ACPI=y > +# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set > +# CONFIG_HOTPLUG_PCI_COMPAQ is not set > +# CONFIG_HOTPLUG_PCI_CPCI is not set > +# CONFIG_HOTPLUG_PCI_IBM is not set > +CONFIG_HOTPLUG_PCI_PCIE=y > +# CONFIG_HOTPLUG_PCI_SHPC is not set > +CONFIG_HOTPLUG_SMT=y Some of Intel's Xeons might have allowed for 64GB. More than 4GB were quite few and far between. Other than USB actual hot-plug hardware was rather sparse, yet "generic" did have these. > @@ -154,15 +237,38 @@ CONFIG_ISA_BUS_API=y > CONFIG_ISO9660_FS=y > # CONFIG_JOLIET is not set > CONFIG_KCMP=y > +CONFIG_KVM=y > +CONFIG_KVM_AMD=y > +CONFIG_KVM_ASYNC_PF=y > +CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y > +CONFIG_KVM_GUEST=y > +CONFIG_KVM_INTEL=y > +CONFIG_KVM_MMIO=y > +CONFIG_KVM_VFIO=y > +# CONFIG_KVM_XEN is not set > +CONFIG_KVM_XFER_TO_GUEST_WORK=y Apparently it is genuinely possible to use KVM on some non-amd64 x86 processors. > @@ -178,13 +284,35 @@ CONFIG_MOUSE_PS2_SYNAPTICS=y > CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y > # CONFIG_MOUSE_PS2_TOUCHKIT is not set > CONFIG_MOUSE_PS2_TRACKPOINT=y > +# CONFIG_MOUSE_PS2_VMMOUSE is not set > # CONFIG_MOUSE_SERIAL is not set > # CONFIG_MOUSE_VSXXXAA is not set > +CONFIG_MPENTIUM4=y Oops. Goof with the very limited filtering I did. This one needs to be pulled. > +CONFIG_NR_CPUS=4 > +CONFIG_NR_CPUS_DEFAULT=8 > +CONFIG_NR_CPUS_RANGE_BEGIN=2 > +CONFIG_NR_CPUS_RANGE_END=8 4 processors is very high-end for this type of machine, but they did exist. > @@ -202,24 +331,77 @@ CONFIG_PCIEASPM_DEFAULT=y > # CONFIG_PCIEASPM_POWERSAVE is not set > # CONFIG_PCIEASPM_POWER_SUPERSAVE is not set > CONFIG_PCIEPORTBUS=y > +CONFIG_PCIE_PME=y > CONFIG_PCI_MMCONFIG=y > +CONFIG_PCI_XEN=y > # CONFIG_PCWATCHDOG is not set > # CONFIG_PEAQ_WMI is not set > +CONFIG_PGTABLE_LEVELS=3 > +CONFIG_PHYS_ADDR_T_64BIT=y > +CONFIG_PINCTRL=y > +CONFIG_PINCTRL_ALDERLAKE=y > +CONFIG_PINCTRL_BAYTRAIL=y > +CONFIG_PINCTRL_BROXTON=y > +CONFIG_PINCTRL_CANNONLAKE=y > +CONFIG_PINCTRL_CHERRYVIEW=y > +CONFIG_PINCTRL_DENVERTON=y > +CONFIG_PINCTRL_ELKHARTLAKE=y > +CONFIG_PINCTRL_EMMITSBURG=y > +CONFIG_PINCTRL_GEMINILAKE=y > +CONFIG_PINCTRL_INTEL=y > +CONFIG_PINCTRL_JASPERLAKE=y > +CONFIG_PINCTRL_LAKEFIELD=y > +CONFIG_PINCTRL_LEWISBURG=y > +CONFIG_PINCTRL_LYNXPOINT=y > +CONFIG_PINCTRL_METEORLAKE=y > +CONFIG_PINCTRL_SUNRISEPOINT=y > +CONFIG_PINCTRL_TIGERLAKE=y Yes, CONFIG_X86_INTEL_LPSS=y made its way into "generic" and thus it got here. I'm unaware of any of these ever being paired with a non-amd64 processor. This seems wrong, but that is what was in "generic". > +CONFIG_SENSORS_CORETEMP=y > +CONFIG_SENSORS_FAM15H_POWER=y > +CONFIG_SENSORS_I5500=y > +CONFIG_SENSORS_K10TEMP=y > +CONFIG_SENSORS_K8TEMP=y > +CONFIG_SENSORS_VIA_CPUTEMP=y I might complain about all the silly Intel-specific choices, but these AMD-specific ones are equally ridiculous. These couldn't be paired with anything you would use with "generic" or "legacy". Yet this *is* what was there! > +CONFIG_SMP=y Much less common with "legacy" and "generic" hardware, but there were plenty of these machines around. This should already have been in "legacy". > @@ -228,34 +410,101 @@ CONFIG_SERIAL_8250_PNP=y >
[PATCH 1/1] kernel/x86: merge "generic" into "legacy"
There is a desire to reduce the time spent on x86 OpenWRT platforms.
"generic" is most suitable for removal. The few systems which could
use "generic" must now opt for "legacy" (or for a lucky few "64").
Signed-off-by: Elliott Mitchell
---
target/linux/x86/Makefile | 2 +-
target/linux/x86/generic/config-6.1 | 508 --
target/linux/x86/generic/target.mk| 10 -
target/linux/x86/image/generic.mk | 9 -
target/linux/x86/image/legacy.mk | 2 +-
.../base-files/lib/preinit/45_mount_xenfs | 0
target/linux/x86/legacy/config-6.1| 259 -
target/linux/x86/legacy/target.mk | 1 +
8 files changed, 257 insertions(+), 534 deletions(-)
delete mode 100644 target/linux/x86/generic/config-6.1
delete mode 100644 target/linux/x86/generic/target.mk
delete mode 100644 target/linux/x86/image/generic.mk
rename target/linux/x86/{generic =>
legacy}/base-files/lib/preinit/45_mount_xenfs (100%)
diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index 39f0a6e825..19b18b6fb4 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -8,7 +8,7 @@ ARCH:=i386
BOARD:=x86
BOARDNAME:=x86
FEATURES:=squashfs ext4 vdi vmdk vhdx pcmcia targz fpu boot-part rootfs-part
-SUBTARGETS:=generic legacy geode 64
+SUBTARGETS:=legacy geode 64
KERNEL_PATCHVER:=6.1
diff --git a/target/linux/x86/generic/config-6.1
b/target/linux/x86/generic/config-6.1
deleted file mode 100644
index 0b5da9ff0e..00
--- a/target/linux/x86/generic/config-6.1
+++ /dev/null
@@ -1,508 +0,0 @@
-# CONFIG_3C515 is not set
-# CONFIG_ACER_WMI is not set
-CONFIG_ACPI=y
-CONFIG_ACPI_AC=y
-CONFIG_ACPI_BATTERY=y
-# CONFIG_ACPI_BGRT is not set
-CONFIG_ACPI_BUTTON=y
-# CONFIG_ACPI_CMPC is not set
-CONFIG_ACPI_CONTAINER=y
-CONFIG_ACPI_CPU_FREQ_PSS=y
-# CONFIG_ACPI_DEBUG is not set
-# CONFIG_ACPI_DEBUGGER is not set
-# CONFIG_ACPI_DOCK is not set
-# CONFIG_ACPI_DPTF is not set
-# CONFIG_ACPI_EC_DEBUGFS is not set
-# CONFIG_ACPI_FAN is not set
-CONFIG_ACPI_HOTPLUG_CPU=y
-CONFIG_ACPI_HOTPLUG_IOAPIC=y
-# CONFIG_ACPI_I2C_OPREGION is not set
-CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
-# CONFIG_ACPI_PCI_SLOT is not set
-CONFIG_ACPI_PROCESSOR=y
-# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
-CONFIG_ACPI_PROCESSOR_CSTATE=y
-CONFIG_ACPI_PROCESSOR_IDLE=y
-CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
-# CONFIG_ACPI_SBS is not set
-CONFIG_ACPI_SPCR_TABLE=y
-CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
-CONFIG_ACPI_TAD=y
-CONFIG_ACPI_THERMAL=y
-# CONFIG_ACPI_TOSHIBA is not set
-CONFIG_ACPI_VIDEO=y
-# CONFIG_ACPI_WMI is not set
-# CONFIG_ADV_SWBUTTON is not set
-CONFIG_AGP=y
-# CONFIG_AGP_ALI is not set
-# CONFIG_AGP_AMD is not set
-# CONFIG_AGP_AMD64 is not set
-# CONFIG_AGP_ATI is not set
-# CONFIG_AGP_EFFICEON is not set
-CONFIG_AGP_INTEL=y
-# CONFIG_AGP_NVIDIA is not set
-# CONFIG_AGP_SIS is not set
-# CONFIG_AGP_SWORKS is not set
-# CONFIG_AGP_VIA is not set
-# CONFIG_AMD_PMC is not set
-# CONFIG_AMD_PMF is not set
-# CONFIG_APM is not set
-CONFIG_ARCH_CPUIDLE_HALTPOLL=y
-CONFIG_ARCH_DMA_ADDR_T_64BIT=y
-CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
-# CONFIG_ASUS_TF103C_DOCK is not set
-# CONFIG_ASUS_WMI is not set
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_BALLOON_COMPACTION=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_BLK_MQ_VIRTIO=y
-CONFIG_BLK_PM=y
-# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
-CONFIG_BTT=y
-CONFIG_CDROM=y
-CONFIG_CONNECTOR=y
-CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y
-CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
-# CONFIG_CPU_IDLE_GOV_HALTPOLL is not set
-CONFIG_CPU_IDLE_GOV_MENU=y
-CONFIG_CPU_RMAP=y
-CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
-# CONFIG_CS89x0_ISA is not set
-# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
-CONFIG_DMA_ACPI=y
-CONFIG_DMA_SHARED_BUFFER=y
-CONFIG_DRM=y
-CONFIG_DRM_BOCHS=y
-CONFIG_DRM_BRIDGE=y
-CONFIG_DRM_FBDEV_EMULATION=y
-CONFIG_DRM_FBDEV_OVERALLOC=100
-CONFIG_DRM_GEM_SHMEM_HELPER=y
-# CONFIG_DRM_HYPERV is not set
-CONFIG_DRM_I915=y
-CONFIG_DRM_I915_CAPTURE_ERROR=y
-CONFIG_DRM_I915_COMPRESS_ERROR=y
-# CONFIG_DRM_I915_DEBUG is not set
-# CONFIG_DRM_I915_DEBUG_GUC is not set
-# CONFIG_DRM_I915_DEBUG_MMIO is not set
-# CONFIG_DRM_I915_DEBUG_RUNTIME_PM is not set
-# CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
-CONFIG_DRM_I915_FENCE_TIMEOUT=1
-CONFIG_DRM_I915_FORCE_PROBE=""
-CONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500
-# CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
-CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000
-CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
-CONFIG_DRM_I915_REQUEST_TIMEOUT=2
-# CONFIG_DRM_I915_SELFTEST is not set
-CONFIG_DRM_I915_STOP_TIMEOUT=100
-# CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
-# CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
-CONFIG_DRM_I915_TIMESLICE_DURATION=1
-CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250
-CONFIG_DRM_I915_USERPTR=y
-# CONFIG_DRM_I915_WERROR is not set
-CONFIG_DRM_KMS_HELPER=y
-CONFIG_DRM_MIPI_DSI=y
-CONFIG_DRM_PANEL=y
-CONFIG_DRM_PANEL_BRIDGE=y
-CO
[PATCH 0/1] Nuking x86 "generic"
For anyone who is reading this mailing list and expecting to read
everything, a fair amount also gets discussed on GitHub.
Seems consensus on reducing x86 by one target is emerging. In fact
someone proposed getting rid of x86-32 completely.
(https://github.com/openwrt/openwrt/pull/13924#discussion_r1395516142)
In light of this, I guess someone needs to go ahead and send a patch
proposing a removal. As such here is one to remove "generic". My
reasoning is "generic" is about the least generic target possible. While
many P4s were made, they weren't the most popular due to power
consumption and poor performance.
Elliott Mitchell (1):
kernel/x86: merge "generic" into "legacy"
target/linux/x86/Makefile | 2 +-
target/linux/x86/generic/config-6.1 | 508 --
target/linux/x86/generic/target.mk| 10 -
target/linux/x86/image/generic.mk | 9 -
target/linux/x86/image/legacy.mk | 2 +-
.../base-files/lib/preinit/45_mount_xenfs | 0
target/linux/x86/legacy/config-6.1| 259 -
target/linux/x86/legacy/target.mk | 1 +
8 files changed, 257 insertions(+), 534 deletions(-)
delete mode 100644 target/linux/x86/generic/config-6.1
delete mode 100644 target/linux/x86/generic/target.mk
delete mode 100644 target/linux/x86/image/generic.mk
rename target/linux/x86/{generic =>
legacy}/base-files/lib/preinit/45_mount_xenfs (100%)
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Sat, Nov 25, 2023 at 07:08:20AM +0100, Felix Fietkau wrote: > On 25.11.23 03:28, Elliott Mitchell wrote: > > > > All of these are plausible. I think modules selected in device > > configurations should get built and installed into the root filesystem. > > Otherwise setting a device kernel configuration option to =m is broken. > > > > Whereas forcing the explicit creation of packages for each and every > > kernel module forces duplication of Kconfig functionality. > The duplication you wish to avoid is there for a reason. The way the > kernel build system is set up, it makes it easy to build a highly > customized build for one target, or make a distribution build with > pretty much everything built as module. What it offers no solution for > is to maintain and keep in sync kernel configurations for a wide array > of different (often storage constrained) targets, while keeping a lot of > extra features/drivers optionally installable. > That's exactly what our packaging around kernel modules + our kernel > config handling scripts were made for. What needs to catch the attention of the core of the Linux kernel developers is Linux is no longer a niche OS. 1.5GB of *source* and producing 400MB of modules. Providing individual descriptions of each and every module is really a task for the kernel developers. The descriptions in Kconfig files don't readily convert to individually packaged modules. I hope other Linux distributions are also concerned about how large the package for all built modules has become. > Since there is no perfect solution, there are always some trade-offs > involved. One of these trade-offs was our choice to not support adding > kernel modules in the device kernel config by selecting them as =m > there. I didn't consider that feature useful enough to justify the cost > of dealing with all the corner cases. > > I still don't fully understand your motivation for adding this feature. > Is it just because you're bothered by having to write some extra > boilerplate code for adding kernel modules? Are there some cases where > the existing system cannot work for what you're trying to do? > Or is there some other reason why you need this? > > Just to be clear, I'm not opposed to the feature you're proposing in any > way. What I want to avoid is adding something that works for your > special case but quickly breaks in weird ways when other people start > using it. I've already stated a concern. Having things configured =m in device kernel configurations simply getting dropped is wrong. The kernel configurations for bmips/bcm6318 and bmips/bcm6328 set CONFIG_HW_RANDOM=n. Turns out despite this, KernelPackage/b43 overrides the value and those device kernels actually have CONFIG_HW_RANDOM=y. This is a very unpleasant surprise if you're trying work with one of these devices. x86 really demonstrates the need for better module handling. Every single Intel pinctrl driver is present in the kernel. If you need the functionality then this is valuable. Alas there are >15 drivers you don't need. Further, these would work well as modules since they could readily be loaded from /. On top of this, what about someone whose system has the feature, but doesn't want to use it? I've got what seems a workable approach, but it isn't yet finished. While there are some differences between building an in-tree module versus building an out-of-tree module, the differences are quite small. I've presently got a PoC of building in-tree modules using the out of tree system. This present method I've got is roughly: `make -C M= CONFIG_=m .ko` Where is a copy of the Kbuild system. The list of files can be extracted from `scripts/package/build`. This really needs a "kbuild_install" so those can share it, and various other uses can come from it. Presently I hope the approach of simply specifying all the package CONFIG_* values on the Make command-line will work. Alas what may instead be needed is to generate a variant of the .config file. Right now I'm seeing two issues. First, this ends up bypassing the kernel handling of dependencies. Due to the impressive nature of OpenWRT's Makefiles (I'm no slouch, but these are impressive) I'm still trying to figure out how targets are named for dependency use. Specifically, what dependency is needed to cause Make to try building the "compile" target for "package/kernel/linux" before proceeding? (external modules can depend on an in-tree ones) Second, this ends up needing slightly different handling between in-tree modules and out-of-tree. In particular there is a need to specify each .ko on Kbuild/Make's command-line. An ideal differentiator is whether the package sets KCONFIG. The result is presently rather more sensitive to package setup and several OpenWRT packages are less than
Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"
On Thu, Dec 14, 2023 at 10:38:34AM +0100, Jonas Gorski wrote: > On Wed, 13 Dec 2023 at 23:55, Elliott Mitchell wrote: > > > > If my belief no one is using CONFIG_PINCTRL on a Geode platform is > > correct, then the original patch is correct. From examination of the > > Linux kernel source, I believe none of Geode's normal peripherals go > > through the PINCTRL subsystem. > > > > Problem is too few people have systems with Geode processors in use, so > > support is difficult. > > Here, I'll do some research work for you: > > 1. To select the MCP23S08 driver you need to have PINCTRL enabled > since 4.13 (see also [1]). > 2. At time of Linux 4.14, PINCTRL was a non user-selectable symbol [2]. > 3. Therefore, a driver selecting this was needed in the kernel config > (it didn't matter which one). I didn't specifically check these, but I was operating on believing the situation was roughly this. > 4. In a later Linux release (4.15), PINCTRL was changed to a > user-selectable symbol [3]. Kconfig isn't my enemy, but nor is it my friend. I can believe that was sufficient to have that effect. I was unaware it had actually changed since that delta is rather small to cause such a change. > 5. Therefore, the intel driver is not needed anymore, but PINCTRL > needs to stay enabled. > > And since we build the MCP23S08 driver as a module/kmod package, it > really doesn't matter if this driver is used or not; having it > available makes sure it can be installed if needed. I remain doubtful of anyone having used CONFIG_PINCTRL on a Geode system, but I was never planning to do anything beyond reverting 4eda2fddf2. Notice how the patch does nothing more or less than reverting 4eda2fddf2? I have noticed rather a lot of Intel-only features sneaking into OpenWRT's kernels. As someone who relies on ECC for reliability, Intel is presently unacceptable so those are bloat to me. There was a problem of 4eda2fddf2 looking quite strange since it chose to enable an option ill-suited to the hardware. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Sat, Nov 25, 2023 at 09:36:33AM -0800, Elliott Mitchell wrote: > On Sat, Nov 25, 2023 at 07:08:20AM +0100, Felix Fietkau wrote: > > On 25.11.23 03:28, Elliott Mitchell wrote: > > > > Since there is no perfect solution, there are always some trade-offs > > involved. One of these trade-offs was our choice to not support adding > > kernel modules in the device kernel config by selecting them as =m > > there. I didn't consider that feature useful enough to justify the cost > > of dealing with all the corner cases. I should also add, I rather dislike package building modifying kernel configuration. Due to this you can't be sure the kernel specified by configuration is the one you're actually building. > > Just to be clear, I'm not opposed to the feature you're proposing in any > > way. What I want to avoid is adding something that works for your > > special case but quickly breaks in weird ways when other people start > > using it. > > That is quite reasonable. I've pushed this later in my queue since I > concluded the aim of the later patches will make a more acceptable > approach possible. > > Hopefully I'll be able to resend the series in a few days, just need > some build testing to ensure I didn't break anything. The first two > patches are going to remain unchanged as there simply isn't anything > which can be done to them. Famous last words. Took rather longer than expected since I went fairly far with an approach which towards the end became clear would not be accepted. Then I tried an alternative and ran into a major weakness of Kbuild. Hopefully I've brought the issue to the attention of the right person and it will be fixed in the kernel soon. Alas I've no idea how long that will take to fix. In the mean time I've got a suboptimal workaround. I seem to have about 3 patch series going. First patch series is a VM oriented build (smallest kernel to boot in multiple VMs). Second patch series is trying to split kernel source/build/module directories apart and implementing better handling of modules. Third series is misc build system cleanup which I've run into while fighting these issues. First two have been partially sent, their later stages are still in flux. Would be helpful to start getting some of the earlier patches committed. I need a lot of reviewer and committer time... -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"
On Wed, Dec 13, 2023 at 01:59:07PM +0100, Martin Schiller wrote: > On 2023-12-13 02:45, Elliott Mitchell wrote: > > > > No idea, I wasn't able to find very much information when I looked at > > this. > > > > I did find: > > https://lists.openwrt.org/pipermail/openwrt-devel/2018-August/019479.html > > > > This doesn't tell me what platform Martin Schiller was trying for. > > 17f30bfcf7 makes me suspect Martin Schiller was simply trying to do > > this > > to all x86 platforms and didn't realize geode was a specialized target. > > > > Alternatively Martin Schiller may have been trying to use a MCP23S08 on > > a > > Geode processor. Unfortunately using CONFIG_X86_INTEL_LPSS is a > > bizzare > > choice since CONFIG_X86_AMD_PLATFORM_DEVICE has fewer side-effects and > > then current Geodes were AMD processors. > > > > With sparse information the former is my present belief. Is anyone > > reading this list using a Geode processor with a MCP23S08? Otherwise > > my > > present belief is only people with Intel x86 processors are interested > > in > > the MCP23S08. > The problem was and is that the PINCTRL subsystem can only be used on > x86 > platforms if either X86_INTEL_LPSS or X86_AMD_PLATFORM_DEVICE is > activated. > I no longer know why I chose the former at the time. Which leaves me suspecting the reason was you had a computer with a processor from Intel. > X86_AMD_PLATFORM_DEVICE is now activated for x86/generic and x86/64. > > From my point of view, we can deactivate X86_INTEL_LPSS if no one else > need it. Seeing how Xiaopo Zhang submitted patches to enable them, I assume at least 1 other person used them on x86/64 at some point. What situation/hardware were YOU using CONFIG_PINCTRL for? Were you using CONFIG_PINCTRL on a desktop which had an Intel processor? Were you using CONFIG_PINCTRL on a system which had a Geode processor? If someone out there is actively using CONFIG_PINCTRL on a system with a Geode processor, I would disable CONFIG_X86_INTEL_LPSS and enable CONFIG_X86_AMD_PLATFORM_DEVICE. The reason is both options select CONFIG_COMMON_CLK and CONFIG_PINCTRL, but CONFIG_X86_INTEL_LPSS additionally selects CONFIG_IOSF_MBI (less bloat). If my belief no one is using CONFIG_PINCTRL on a Geode platform is correct, then the original patch is correct. From examination of the Linux kernel source, I believe none of Geode's normal peripherals go through the PINCTRL subsystem. Problem is too few people have systems with Geode processors in use, so support is difficult. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"
On Tue, Dec 12, 2023 at 04:54:05PM +0100, Jonas Gorski wrote: > > On Sun, 10 Dec 2023 at 18:51, Elliott Mitchell wrote: > > > > Date: Fri, 3 Nov 2023 22:57:43 -0700 > > > > Enabling an Intel chipset feature on a platform originally made by > > National Semiconductor and later bought by AMD. Could we cut the Intel > > enthusiasm? > > > > This reverts commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f. > > commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f says "This makes it > possible to use the MCP23S08 i/o expander on geode platforms with > linux 4.14." Problem is this is nonsensical. A Geode processor CANNOT be paired with an Intel chipset (the original Geode GX1 came out of National Semiconductor/Cyrix and was later bought by AMD). > So we don't need to enable PINCTRL (via other symbols) anymore for this? No idea, I wasn't able to find very much information when I looked at this. I did find: https://lists.openwrt.org/pipermail/openwrt-devel/2018-August/019479.html This doesn't tell me what platform Martin Schiller was trying for. 17f30bfcf7 makes me suspect Martin Schiller was simply trying to do this to all x86 platforms and didn't realize geode was a specialized target. Alternatively Martin Schiller may have been trying to use a MCP23S08 on a Geode processor. Unfortunately using CONFIG_X86_INTEL_LPSS is a bizzare choice since CONFIG_X86_AMD_PLATFORM_DEVICE has fewer side-effects and then current Geodes were AMD processors. With sparse information the former is my present belief. Is anyone reading this list using a Geode processor with a MCP23S08? Otherwise my present belief is only people with Intel x86 processors are interested in the MCP23S08. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RESEND 02/11] kernel/generic: remove CONFIG_FB_NOTIFY
On Tue, Dec 12, 2023 at 04:48:32PM +0100, Jonas Gorski wrote: > > On Sun, 10 Dec 2023 at 18:49, Elliott Mitchell wrote: > > > > Date: Tue, 25 Apr 2023 16:23:20 -0700 > > > > This option is automatically enabled by CONFIG_FB=y. There is no > > reason to specifically enable it. > > Unfortunately this change will cause the symbol to appear in target > configs when using make kernel_*config. Ideally a make kernel_*config > without any changes should result in no changed files (currently it > does so for many targets). I strongly dislike this approach. Problem is forces the configuration files to contain both values which were deliberately chosen and values which are simply defaults (and defaults can change due to drivers becoming mature). Perhaps my other project could invalidate the reasoning behind this choice. Hmm. > To avoid that, I guess adding the symbol to > target/linux/generic/config-filter should do the trick so it becomes > properly ignored for config management. I'm okay with that. Presently have this is in my repository. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 11/11] kernel/x86: isolate board-specific files to associated architecture
Split the board.d files to isolate their data to associated
architectures. Seems wasteful to include all board-specific data
with every single build.
Signed-off-by: Elliott Mitchell
---
.../{ => 64}/base-files/etc/board.d/01_leds | 5 -
.../base-files/etc/board.d/02_network | 7 ---
.../x86/geode/base-files/etc/board.d/01_leds | 18
.../geode/base-files/etc/board.d/02_network | 21 +++
4 files changed, 39 insertions(+), 12 deletions(-)
rename target/linux/x86/{ => 64}/base-files/etc/board.d/01_leds (85%)
rename target/linux/x86/{ => 64}/base-files/etc/board.d/02_network (93%)
create mode 100644 target/linux/x86/geode/base-files/etc/board.d/01_leds
create mode 100644 target/linux/x86/geode/base-files/etc/board.d/02_network
diff --git a/target/linux/x86/base-files/etc/board.d/01_leds
b/target/linux/x86/64/base-files/etc/board.d/01_leds
similarity index 85%
rename from target/linux/x86/base-files/etc/board.d/01_leds
rename to target/linux/x86/64/base-files/etc/board.d/01_leds
index 47ea0929e6..2d65997d99 100644
--- a/target/linux/x86/base-files/etc/board.d/01_leds
+++ b/target/linux/x86/64/base-files/etc/board.d/01_leds
@@ -23,11 +23,6 @@
sophos-sg-105wr2|sophos-sg-125wr2|sophos-sg-135wr2|sophos-xg-105wr2|sophos-xg-12
sophos-sg-105wr3|sophos-sg-125wr3|sophos-sg-135wr3|sophos-xg-105wr3|sophos-xg-125wr3|sophos-xg-135wr3)
ucidef_set_led_netdev "wlan" "WiFi" "ath10k-phy0" "phy0tpt"
;;
-traverse-technologies-geos)
- ucidef_set_led_netdev "lan" "LAN" "geos:1" "br-lan" "tx rx"
- ucidef_set_led_netdev "wlan" "WiFi" "geos:2" "phy0tpt"
- ucidef_set_led_default "diag" "DIAG" "geos:3" "1"
- ;;
silicom-80500-0214-*)
ucidef_set_led_netdev "wan" "WAN" "multicolor:fp_center" "wan0"
ucidef_set_led_netdev "lan" "LAN" "multicolor:fp_right" "br-lan"
diff --git a/target/linux/x86/base-files/etc/board.d/02_network
b/target/linux/x86/64/base-files/etc/board.d/02_network
similarity index 93%
rename from target/linux/x86/base-files/etc/board.d/02_network
rename to target/linux/x86/64/base-files/etc/board.d/02_network
index b18ab60120..c47f79b607 100644
--- a/target/linux/x86/base-files/etc/board.d/02_network
+++ b/target/linux/x86/64/base-files/etc/board.d/02_network
@@ -71,13 +71,6 @@ sophos-sg-135r3|sophos-xg-135r3| \
sophos-sg-135wr3|sophos-xg-135wr3)
ucidef_set_interfaces_lan_wan "eth0 eth1 eth2 eth3 eth5 eth7 eth8"
"eth6"
;;
-traverse-technologies-geos)
- ucidef_set_interface_lan "eth0 eth1"
- ucidef_add_atm_bridge "0" "35" "llc" "bridged"
- ucidef_set_interface_wan "nas0" "dhcp"
- macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null
- [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr"
- ;;
silicom-80500-0214-*)
ucidef_set_network_device_path "wan0"
"pci:00/:00:16.0/:03:00.0"
ucidef_set_network_device_path "wan1"
"pci:00/:00:16.0/:03:00.1"
diff --git a/target/linux/x86/geode/base-files/etc/board.d/01_leds
b/target/linux/x86/geode/base-files/etc/board.d/01_leds
new file mode 100644
index 00..75fd60c1f9
--- /dev/null
+++ b/target/linux/x86/geode/base-files/etc/board.d/01_leds
@@ -0,0 +1,18 @@
+#
+# Copyright © 2017 OpenWrt.org
+#
+
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+traverse-technologies-geos)
+ ucidef_set_led_netdev "lan" "LAN" "geos:1" "br-lan" "tx rx"
+ ucidef_set_led_netdev "wlan" "WiFi" "geos:2" "phy0tpt"
+ ucidef_set_led_default "diag" "DIAG" "geos:3" "1"
+ ;;
+esac
+board_config_flush
+
+exit 0
diff --git a/target/linux/x86/geode/base-files/etc/board.d/02_network
b/target/linux/x86/geode/base-files/etc/board.d/02_network
new file mode 100644
index 00..53cc0f8261
--- /dev/null
+++ b/target/linux/x86/geode/base-files/etc/board.d/02_network
@@ -0,0 +1,21 @@
+#
+# Copyright © 2017 OpenWrt.org
+#
+
+. /lib/functions/system.sh
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+traverse-technologies-geos)
+ ucidef_set_interface_lan "eth0 eth1"
+ ucidef_add_atm_bridge "0" "35" "llc" "bridged"
+ ucidef_set_interface_wan "nas0" "dhcp"
+ macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null
+ [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr"
+ ;;
+esac
+board_config_flush
+
+exit 0
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 09/11] kernel/x86: remove CONFIG_M686 from common configuration
Date: Mon, 17 Apr 2023 08:21:26 -0700 All of the sublevels choose their own values, so there is no point in the common file having anything. This also removes a warning from the kernel build process. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/x86/config-5.15 | 2 +- target/linux/x86/config-6.1 | 2 +- target/linux/x86/generic/config-5.15 | 1 - target/linux/x86/generic/config-6.1 | 1 - target/linux/x86/geode/config-5.15 | 1 - target/linux/x86/geode/config-6.1| 1 - target/linux/x86/legacy/config-5.15 | 1 - target/linux/x86/legacy/config-6.1 | 1 - 8 files changed, 2 insertions(+), 8 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index e4ec6520e5..71f06ad470 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -204,7 +204,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_M586 is not set # CONFIG_M586MMX is not set # CONFIG_M586TSC is not set -CONFIG_M686=y +# CONFIG_M686 is not set # CONFIG_MACHZ_WDT is not set # CONFIG_MATOM is not set # CONFIG_MCORE2 is not set diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index 1253e266a2..362be84697 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -214,7 +214,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_M586 is not set # CONFIG_M586MMX is not set # CONFIG_M586TSC is not set -CONFIG_M686=y +# CONFIG_M686 is not set # CONFIG_MACHZ_WDT is not set # CONFIG_MATOM is not set # CONFIG_MCORE2 is not set diff --git a/target/linux/x86/generic/config-5.15 b/target/linux/x86/generic/config-5.15 index a06175f33a..940a0b1da6 100644 --- a/target/linux/x86/generic/config-5.15 +++ b/target/linux/x86/generic/config-5.15 @@ -240,7 +240,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y # CONFIG_LANCE is not set CONFIG_LIBNVDIMM=y CONFIG_LOCK_SPIN_ON_OWNER=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MEMORY_BALLOON=y CONFIG_MEMREGION=y diff --git a/target/linux/x86/generic/config-6.1 b/target/linux/x86/generic/config-6.1 index e62dc6575e..746ae3f47d 100644 --- a/target/linux/x86/generic/config-6.1 +++ b/target/linux/x86/generic/config-6.1 @@ -254,7 +254,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y # CONFIG_LG_LAPTOP is not set CONFIG_LIBNVDIMM=y CONFIG_LOCK_SPIN_ON_OWNER=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MEMORY_BALLOON=y CONFIG_MEMREGION=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index b5a1a641bb..977cfbd4aa 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -75,7 +75,6 @@ CONFIG_ISA_BUS_API=y # CONFIG_ISCSI_IBFT is not set # CONFIG_LANCE is not set CONFIG_LEDS_GPIO=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_CS5535=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index f459583c02..08972ed5d0 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -81,7 +81,6 @@ CONFIG_ISA_BUS_API=y # CONFIG_ISCSI_IBFT is not set # CONFIG_LANCE is not set CONFIG_LEDS_GPIO=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_CS5535=y diff --git a/target/linux/x86/legacy/config-5.15 b/target/linux/x86/legacy/config-5.15 index b6a29d57c9..64af1fbf5a 100644 --- a/target/linux/x86/legacy/config-5.15 +++ b/target/linux/x86/legacy/config-5.15 @@ -146,7 +146,6 @@ CONFIG_ISO9660_FS=y CONFIG_KCMP=y # CONFIG_LANCE is not set CONFIG_M586MMX=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_INTEL_LPSS=y diff --git a/target/linux/x86/legacy/config-6.1 b/target/linux/x86/legacy/config-6.1 index c1b132d834..fbadad9d15 100644 --- a/target/linux/x86/legacy/config-6.1 +++ b/target/linux/x86/legacy/config-6.1 @@ -156,7 +156,6 @@ CONFIG_KCMP=y # CONFIG_LANCE is not set # CONFIG_LG_LAPTOP is not set CONFIG_M586MMX=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_INTEL_LPSS=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 10/11] packages/x86: detect architecture, not x86/64 target
Date: Mon, 27 Feb 2023 17:24:27 -0800 These spots should be detecting the amd64 architecture, not the specific target name. If additional amd64 targets were added, or the target was renamed, these would fail to build. Signed-off-by: Elliott Mitchell --- package/firmware/intel-microcode/Makefile | 2 +- package/kernel/linux/modules/crypto.mk| 2 +- package/kernel/linux/modules/virt.mk | 4 ++-- package/libs/wolfssl/Makefile | 2 +- target/linux/x86/modules.mk | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/package/firmware/intel-microcode/Makefile b/package/firmware/intel-microcode/Makefile index 9e87dccc12..f6e9c2def7 100644 --- a/package/firmware/intel-microcode/Makefile +++ b/package/firmware/intel-microcode/Makefile @@ -19,7 +19,7 @@ PKG_CPE_ID:=cpe:/a:intel:microcode PKG_BUILD_DEPENDS:=iucode-tool/host -ifdef CONFIG_TARGET_x86_64 +ifdef CONFIG_x86_64 MICROCODE:="intel-microcode-64" else MICROCODE:="intel-microcode" diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index dd17d868fa..5e6fed631a 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -777,7 +777,7 @@ define KernelPackage/crypto-misc $(call AddDepends/crypto) endef -ifndef CONFIG_TARGET_x86_64 +ifndef CONFIG_x86_64 define KernelPackage/crypto-misc/x86 FILES+= \ $(LINUX_DIR)/arch/x86/crypto/twofish-i586.ko \ diff --git a/package/kernel/linux/modules/virt.mk b/package/kernel/linux/modules/virt.mk index f45cb17614..82fb1af2de 100644 --- a/package/kernel/linux/modules/virt.mk +++ b/package/kernel/linux/modules/virt.mk @@ -77,7 +77,7 @@ $(eval $(call KernelPackage,kvm-amd)) define KernelPackage/vfio SUBMENU:=Virtualization TITLE:=VFIO Non-Privileged userspace driver framework - DEPENDS:=@TARGET_x86_64||TARGET_armsr_armv8 + DEPENDS:=@x86_64||TARGET_armsr_armv8 KCONFIG:= \ CONFIG_VFIO \ CONFIG_VFIO_NOIOMMU=n \ @@ -99,7 +99,7 @@ $(eval $(call KernelPackage,vfio)) define KernelPackage/vfio-pci SUBMENU:=Virtualization TITLE:=Generic VFIO support for any PCI device - DEPENDS:=@TARGET_x86_64||TARGET_armsr_armv8 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass + DEPENDS:=@x86_64||TARGET_armsr_armv8 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass KCONFIG:= \ CONFIG_VFIO_PCI \ CONFIG_VFIO_PCI_IGD=n diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 6451dca68d..4326d1483e 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -185,7 +185,7 @@ else ifdef CONFIG_aarch64 CONFIGURE_ARGS += --enable-armasm TARGET_CFLAGS:=$(TARGET_CFLAGS:-mcpu%=-mcpu%+crypto) Package/libwolfsslcpu-crypto/preinst=$(Package/libwolfsslcpu-crypto/preinst-aarch64) -else ifdef CONFIG_TARGET_x86_64 +else ifdef CONFIG_x86_64 CONFIGURE_ARGS += --enable-intelasm endif diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk index cdae01bce6..29834d096b 100644 --- a/target/linux/x86/modules.mk +++ b/target/linux/x86/modules.mk @@ -5,7 +5,7 @@ define KernelPackage/amd-xgbe SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=AMD Ethernet on SoC support - DEPENDS:=@PCI_SUPPORT @TARGET_x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy +kmod-mdio-devres + DEPENDS:=@PCI_SUPPORT @x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy +kmod-mdio-devres KCONFIG:=CONFIG_AMD_XGBE FILES:=$(LINUX_DIR)/drivers/net/ethernet/amd/xgbe/amd-xgbe.ko AUTOLOAD:=$(call AutoLoad,35,amd-xgbe) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 05/11] kernel/x86: remove CONFIG_HDMI
Date: Tue, 31 Oct 2023 11:06:58 -0700 This is an internal boolean value. The value routinely gets overriden and should never be overtly set. Signed-off-by: Elliott Mitchell --- target/linux/x86/64/config-5.15 | 1 - target/linux/x86/64/config-6.1 | 1 - target/linux/x86/generic/config-5.15 | 1 - target/linux/x86/generic/config-6.1 | 1 - target/linux/x86/legacy/config-5.15 | 1 - target/linux/x86/legacy/config-6.1 | 1 - 6 files changed, 6 deletions(-) diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 index 28a4758e57..1db3180c84 100644 --- a/target/linux/x86/64/config-5.15 +++ b/target/linux/x86/64/config-5.15 @@ -207,7 +207,6 @@ CONFIG_GPIO_ICH=y CONFIG_GPIO_SCH=y CONFIG_HALTPOLL_CPUIDLE=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/64/config-6.1 b/target/linux/x86/64/config-6.1 index 66ae3e35f0..6609f555ba 100644 --- a/target/linux/x86/64/config-6.1 +++ b/target/linux/x86/64/config-6.1 @@ -227,7 +227,6 @@ CONFIG_GPIO_ICH=y CONFIG_GPIO_SCH=y CONFIG_HALTPOLL_CPUIDLE=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/generic/config-5.15 b/target/linux/x86/generic/config-5.15 index c10e1b610b..a06175f33a 100644 --- a/target/linux/x86/generic/config-5.15 +++ b/target/linux/x86/generic/config-5.15 @@ -157,7 +157,6 @@ CONFIG_GPIO_ACPI=y CONFIG_GPIO_CDEV=y CONFIG_GUP_GET_PTE_LOW_HIGH=y CONFIG_HALTPOLL_CPUIDLE=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/generic/config-6.1 b/target/linux/x86/generic/config-6.1 index b7c79de273..e62dc6575e 100644 --- a/target/linux/x86/generic/config-6.1 +++ b/target/linux/x86/generic/config-6.1 @@ -166,7 +166,6 @@ CONFIG_GPIO_ACPI=y CONFIG_GPIO_CDEV=y CONFIG_GUP_GET_PTE_LOW_HIGH=y CONFIG_HALTPOLL_CPUIDLE=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/legacy/config-5.15 b/target/linux/x86/legacy/config-5.15 index 8e17703cbc..b6a29d57c9 100644 --- a/target/linux/x86/legacy/config-5.15 +++ b/target/linux/x86/legacy/config-5.15 @@ -108,7 +108,6 @@ CONFIG_FONT_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set -CONFIG_HDMI=y CONFIG_HID_BATTERY_STRENGTH=y # CONFIG_HIGHMEM4G is not set CONFIG_HPET=y diff --git a/target/linux/x86/legacy/config-6.1 b/target/linux/x86/legacy/config-6.1 index efa1eabe82..c1b132d834 100644 --- a/target/linux/x86/legacy/config-6.1 +++ b/target/linux/x86/legacy/config-6.1 @@ -113,7 +113,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_GIGABYTE_WMI is not set -CONFIG_HDMI=y CONFIG_HID_BATTERY_STRENGTH=y # CONFIG_HIGHMEM4G is not set CONFIG_HPET=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 07/11] kernel/x86: move Geode HW random from generic to geode
Date: Wed, 19 Apr 2023 14:07:47 -0700 Quite reasonable to have support for the Geode HW random number generator. On the Geode kernel. Signed-off-by: Elliott Mitchell --- target/linux/x86/config-5.15 | 1 - target/linux/x86/config-6.1| 1 - target/linux/x86/geode/config-5.15 | 1 + target/linux/x86/geode/config-6.1 | 1 + 4 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index 57941a53bf..e1efc44fbe 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -158,7 +158,6 @@ CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET_TIMER=y # CONFIG_HP_WATCHDOG is not set CONFIG_HW_CONSOLE=y -CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y # CONFIG_HYPERVISOR_GUEST is not set CONFIG_HZ_PERIODIC=y diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index 30ed7c84e3..b91575dcf5 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -166,7 +166,6 @@ CONFIG_HIGHPTE=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET_TIMER=y CONFIG_HW_CONSOLE=y -CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y # CONFIG_HYPERVISOR_GUEST is not set CONFIG_HZ_PERIODIC=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 6463934b77..22c9c031e8 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -52,6 +52,7 @@ CONFIG_GPIO_CS5535=y # CONFIG_HPET is not set # CONFIG_HP_ACCEL is not set CONFIG_HWMON=y +CONFIG_HW_RANDOM_GEODE=y CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCA=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index e19cf7ea10..d45a2aa170 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -56,6 +56,7 @@ CONFIG_GPIO_CS5535=y # CONFIG_HPET is not set # CONFIG_HP_ACCEL is not set CONFIG_HWMON=y +CONFIG_HW_RANDOM_GEODE=y CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCA=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 08/11] kernel/x86: move SCx200 support from generic to geode
Date: Thu, 13 Apr 2023 17:07:20 -0700 The SCx200 is part of the Geode platform. As such generic x86 doesn't need the driver, but Geode does. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/x86/config-5.15 | 5 + target/linux/x86/config-6.1| 5 + target/linux/x86/geode/config-5.15 | 3 +++ target/linux/x86/geode/config-6.1 | 3 +++ 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index e1efc44fbe..e4ec6520e5 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -309,10 +309,7 @@ CONFIG_SATA_HOST=y CONFIG_SCSI=y CONFIG_SCSI_COMMON=y CONFIG_SCSI_SPI_ATTRS=y -CONFIG_SCx200=y -CONFIG_SCx200HR_TIMER=y -# CONFIG_SCx200_GPIO is not set -# CONFIG_SCx200_WDT is not set +# CONFIG_SCx200 is not set CONFIG_SERIAL_8250_PCI=y # CONFIG_SERIAL_LANTIQ is not set CONFIG_SERIO=y diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index b91575dcf5..1253e266a2 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -328,10 +328,7 @@ CONFIG_SATA_HOST=y CONFIG_SCSI=y CONFIG_SCSI_COMMON=y CONFIG_SCSI_SPI_ATTRS=y -CONFIG_SCx200=y -CONFIG_SCx200HR_TIMER=y -# CONFIG_SCx200_GPIO is not set -# CONFIG_SCx200_WDT is not set +# CONFIG_SCx200 is not set CONFIG_SERIAL_8250_PCI=y # CONFIG_SERIAL_LANTIQ is not set CONFIG_SERIAL_MCTRL_GPIO=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 22c9c031e8..b5a1a641bb 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -104,7 +104,10 @@ CONFIG_RTC_I2C_AND_SPI=y # CONFIG_SAMSUNG_Q10 is not set CONFIG_SC1200_WDT=y # CONFIG_SCSI_FDOMAIN_ISA is not set +CONFIG_SCx200=y +CONFIG_SCx200HR_TIMER=y CONFIG_SCx200_ACB=y +# CONFIG_SCx200_GPIO is not set CONFIG_SCx200_WDT=y CONFIG_SENSORS_LM90=y CONFIG_SERIAL_8250_PNP=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index d45a2aa170..f459583c02 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -113,7 +113,10 @@ CONFIG_RTC_I2C_AND_SPI=y # CONFIG_SAMSUNG_Q10 is not set CONFIG_SC1200_WDT=y # CONFIG_SCSI_FDOMAIN_ISA is not set +CONFIG_SCx200=y +CONFIG_SCx200HR_TIMER=y CONFIG_SCx200_ACB=y +# CONFIG_SCx200_GPIO is not set CONFIG_SCx200_WDT=y # CONFIG_SENSORS_ASUS_EC is not set # CONFIG_SENSORS_ASUS_WMI is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"
Date: Fri, 3 Nov 2023 22:57:43 -0700 Enabling an Intel chipset feature on a platform originally made by National Semiconductor and later bought by AMD. Could we cut the Intel enthusiasm? This reverts commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f. Signed-off-by: Elliott Mitchell --- target/linux/x86/geode/config-5.15 | 18 +- target/linux/x86/geode/config-6.1 | 20 +--- 2 files changed, 2 insertions(+), 36 deletions(-) diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 0104b1e7b3..6463934b77 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -94,22 +94,6 @@ CONFIG_PC8736x_GPIO=y # CONFIG_PCENGINES_APU2 is not set CONFIG_PCI_MMCONFIG=y # CONFIG_PCWATCHDOG is not set -CONFIG_PINCTRL=y -# CONFIG_PINCTRL_ALDERLAKE is not set -# CONFIG_PINCTRL_BAYTRAIL is not set -# CONFIG_PINCTRL_BROXTON is not set -# CONFIG_PINCTRL_CANNONLAKE is not set -# CONFIG_PINCTRL_CHERRYVIEW is not set -# CONFIG_PINCTRL_DENVERTON is not set -# CONFIG_PINCTRL_ELKHARTLAKE is not set -# CONFIG_PINCTRL_EMMITSBURG is not set -# CONFIG_PINCTRL_GEMINILAKE is not set -# CONFIG_PINCTRL_JASPERLAKE is not set -# CONFIG_PINCTRL_LAKEFIELD is not set -# CONFIG_PINCTRL_LEWISBURG is not set -# CONFIG_PINCTRL_LYNXPOINT is not set -# CONFIG_PINCTRL_SUNRISEPOINT is not set -# CONFIG_PINCTRL_TIGERLAKE is not set # CONFIG_PMIC_OPREGION is not set CONFIG_PNP=y CONFIG_PNPACPI=y @@ -138,7 +122,7 @@ CONFIG_X86_ALIGNMENT_16=y # CONFIG_X86_AMD_PLATFORM_DEVICE is not set CONFIG_X86_CPUID=y # CONFIG_X86_E_POWERSAVER is not set -CONFIG_X86_INTEL_LPSS=y +# CONFIG_X86_INTEL_LPSS is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_MCE is not set CONFIG_X86_MINIMUM_CPU_FAMILY=5 diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index cf02d2b9b0..e19cf7ea10 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -104,24 +104,6 @@ CONFIG_PC8736x_GPIO=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCWATCHDOG is not set # CONFIG_PEAQ_WMI is not set -CONFIG_PINCTRL=y -# CONFIG_PINCTRL_ALDERLAKE is not set -# CONFIG_PINCTRL_BAYTRAIL is not set -# CONFIG_PINCTRL_BROXTON is not set -# CONFIG_PINCTRL_CANNONLAKE is not set -# CONFIG_PINCTRL_CHERRYVIEW is not set -# CONFIG_PINCTRL_DENVERTON is not set -# CONFIG_PINCTRL_ELKHARTLAKE is not set -# CONFIG_PINCTRL_EMMITSBURG is not set -# CONFIG_PINCTRL_GEMINILAKE is not set -# CONFIG_PINCTRL_JASPERLAKE is not set -# CONFIG_PINCTRL_LAKEFIELD is not set -# CONFIG_PINCTRL_LEWISBURG is not set -# CONFIG_PINCTRL_LYNXPOINT is not set -# CONFIG_PINCTRL_METEORLAKE is not set -# CONFIG_PINCTRL_SUNRISEPOINT is not set -# CONFIG_PINCTRL_TIGERLAKE is not set -# CONFIG_PMIC_OPREGION is not set CONFIG_PNP=y CONFIG_PNPACPI=y # CONFIG_PNPBIOS is not set @@ -165,7 +147,7 @@ CONFIG_X86_ALIGNMENT_16=y # CONFIG_X86_AMD_PSTATE_UT is not set CONFIG_X86_CPUID=y # CONFIG_X86_E_POWERSAVER is not set -CONFIG_X86_INTEL_LPSS=y +# CONFIG_X86_INTEL_LPSS is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_MCE is not set CONFIG_X86_MINIMUM_CPU_FAMILY=5 -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 04/11] kernel: remove ext2 support from kernel
Date: Tue, 9 May 2023 13:57:31 -0700 While functional and small during its time, ext2 support should no longer be enabled by default. For most purposes aside from memory footprint, ext4 is rather superior. Time to play Taps. Signed-off-by: Elliott Mitchell --- I haven't done builds to confirm the size delta. I suspect it won't be very large. Mostly this is to finish killing off ext2 and make sure no one tries to install a new system with ext2. --- target/linux/generic/config-5.15 | 3 +-- target/linux/generic/config-6.1 | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 index 09bd33c3d6..c005d0c3f9 100644 --- a/target/linux/generic/config-5.15 +++ b/target/linux/generic/config-5.15 @@ -1891,14 +1891,13 @@ CONFIG_EXPERT=y CONFIG_EXPORTFS=y # CONFIG_EXPORTFS_BLOCK_OPS is not set # CONFIG_EXT2_FS is not set -CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT3_FS is not set # CONFIG_EXT4_DEBUG is not set # CONFIG_EXT4_ENCRYPTION is not set # CONFIG_EXT4_FS is not set # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set -CONFIG_EXT4_USE_FOR_EXT2=y +# CONFIG_EXT4_USE_FOR_EXT2 is not set # CONFIG_EXTCON is not set # CONFIG_EXTCON_ADC_JACK is not set # CONFIG_EXTCON_ARIZONA is not set diff --git a/target/linux/generic/config-6.1 b/target/linux/generic/config-6.1 index 5e0362ee49..e1c2f42a07 100644 --- a/target/linux/generic/config-6.1 +++ b/target/linux/generic/config-6.1 @@ -1978,14 +1978,13 @@ CONFIG_EXPERT=y CONFIG_EXPORTFS=y # CONFIG_EXPORTFS_BLOCK_OPS is not set # CONFIG_EXT2_FS is not set -CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT3_FS is not set # CONFIG_EXT4_DEBUG is not set # CONFIG_EXT4_ENCRYPTION is not set # CONFIG_EXT4_FS is not set # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set -CONFIG_EXT4_USE_FOR_EXT2=y +# CONFIG_EXT4_USE_FOR_EXT2 is not set # CONFIG_EXTCON is not set # CONFIG_EXTCON_ADC_JACK is not set # CONFIG_EXTCON_ARIZONA is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND 03/11] kernel: purge CONFIG_FS_MBCACHE
Date: Tue, 9 May 2023 14:36:00 -0700 There is no point in attempting to set CONFIG_FS_MBCACHE. The way the Kconfig files are setup, your choice will be overridden. As such there isn't any point in documenting a default. Signed-off-by: Elliott Mitchell --- target/linux/archs38/config-5.15 | 1 - target/linux/armsr/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 1 - target/linux/at91/sama5/config-5.15 | 1 - target/linux/at91/sama7/config-5.15 | 1 - target/linux/bcm27xx/bcm2708/config-6.1 | 1 - target/linux/bcm27xx/bcm2709/config-6.1 | 1 - target/linux/bcm27xx/bcm2710/config-6.1 | 1 - target/linux/bcm27xx/bcm2711/config-6.1 | 1 - target/linux/gemini/config-6.1| 1 - target/linux/imx/config-5.15 | 1 - target/linux/ixp4xx/config-6.1| 1 - target/linux/layerscape/armv7/config-5.15 | 1 - target/linux/layerscape/armv7/config-6.1 | 1 - target/linux/layerscape/armv8_64b/config-5.15 | 1 - target/linux/layerscape/armv8_64b/config-6.1 | 1 - target/linux/malta/config-5.15| 1 - target/linux/malta/config-6.1 | 1 - target/linux/mediatek/filogic/config-5.15 | 1 - target/linux/mediatek/filogic/config-6.1 | 1 - target/linux/mediatek/mt7622/config-5.15 | 1 - target/linux/mediatek/mt7622/config-6.1 | 1 - target/linux/mediatek/mt7623/config-5.15 | 1 - target/linux/mediatek/mt7623/config-6.1 | 1 - target/linux/mvebu/config-5.15| 1 - target/linux/mvebu/config-6.1 | 1 - target/linux/mxs/config-5.15 | 1 - target/linux/mxs/config-6.1 | 1 - target/linux/octeon/config-5.15 | 1 - target/linux/omap/config-5.15 | 1 - target/linux/oxnas/ox810se/config-default | 1 - target/linux/pistachio/config-5.15| 1 - target/linux/qoriq/config-5.15| 1 - target/linux/rockchip/armv8/config-6.1| 1 - target/linux/sifiveu/config-6.1 | 1 - target/linux/sunxi/config-5.15| 1 - target/linux/sunxi/config-6.1 | 1 - target/linux/tegra/config-5.15| 1 - target/linux/uml/config-5.15 | 1 - target/linux/uml/config-6.1 | 1 - target/linux/x86/config-5.15 | 1 - target/linux/x86/config-6.1 | 1 - target/linux/zynq/config-5.15 | 1 - 43 files changed, 43 deletions(-) diff --git a/target/linux/archs38/config-5.15 b/target/linux/archs38/config-5.15 index b526c0efe0..9e537951df 100644 --- a/target/linux/archs38/config-5.15 +++ b/target/linux/archs38/config-5.15 @@ -87,7 +87,6 @@ CONFIG_FB=y CONFIG_FB_CMDLINE=y CONFIG_FIXED_PHY=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_FWNODE_MDIO=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/armsr/config-6.1 b/target/linux/armsr/config-6.1 index d1dac69da4..745a5caf9d 100644 --- a/target/linux/armsr/config-6.1 +++ b/target/linux/armsr/config-6.1 @@ -138,7 +138,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FRAME_POINTER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ARCH_TOPOLOGY=y diff --git a/target/linux/at91/sam9x/config-5.15 b/target/linux/at91/sam9x/config-5.15 index 2c29ca2369..5a902d5cd1 100644 --- a/target/linux/at91/sam9x/config-5.15 +++ b/target/linux/at91/sam9x/config-5.15 @@ -95,7 +95,6 @@ CONFIG_FIXED_PHY=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_FREEZER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_CACHE=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/at91/sama5/config-5.15 b/target/linux/at91/sama5/config-5.15 index 6130e288dd..4cf28c5f33 100644 --- a/target/linux/at91/sama5/config-5.15 +++ b/target/linux/at91/sama5/config-5.15 @@ -163,7 +163,6 @@ CONFIG_FIX_EARLYCON_MEM=y CONFIG_FORCE_MAX_ZONEORDER=15 CONFIG_FREEZER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_CACHE=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/at91/sama7/config-5.15 b/target/linux/at91/sama7/config-5.15 index 23b74890ea..86187089bf 100644 --- a/target/linux/at91/sama7/config-5.15 +++ b/target/linux/at91/sama7/config-5.15 @@ -150,7 +150,6 @@ CONFIG_FIXED_PHY=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_FORCE_MAX_ZONEORDER=15 CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ALLOCATOR=y diff --git a/target/linux/bcm27xx/bcm2708/config-6.1 b/target/linux/bcm27xx/bcm2708/config-6.1 index 244fa67656..913063ef1a 100644 --- a/target/linux/bcm27xx/bcm2708/config-6.1 +++ b/target/linux/bcm27xx/bcm2708/config-6.1 @@ -164,7 +164,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FREEZER=y CONFIG_FS_IOMAP=y
[PATCH RESEND 01/11] kernel: change CONFIG_HW_RANDOM default to y
Date: Sat, 22 Apr 2023 10:46:30 -0700 Many devices do not have hardware random number generators. Yet more do than don't, and they are becoming more common. Signed-off-by: Elliott Mitchell --- v2: As requested, since there is a dislike of =n even though it works fine with all tools. --- target/linux/airoha/config-5.15 | 1 - target/linux/apm821xx/config-5.15 | 1 + target/linux/apm821xx/config-6.1 | 1 + target/linux/archs38/config-5.15 | 1 + target/linux/armsr/armv7/config-6.1 | 1 + target/linux/armsr/armv8/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 1 - target/linux/at91/sama5/config-5.15 | 1 - target/linux/at91/sama7/config-5.15 | 1 - target/linux/ath25/config-5.15| 1 - target/linux/ath79/config-5.15| 1 + target/linux/ath79/config-6.1 | 1 + target/linux/bcm27xx/bcm2708/config-6.1 | 1 - target/linux/bcm27xx/bcm2709/config-6.1 | 1 - target/linux/bcm27xx/bcm2710/config-6.1 | 1 - target/linux/bcm27xx/bcm2711/config-6.1 | 1 - target/linux/bcm47xx/config-5.15 | 1 - target/linux/bcm4908/config-5.15 | 1 + target/linux/bcm4908/config-6.1 | 1 + target/linux/bcm53xx/config-5.15 | 1 - target/linux/bcm53xx/config-6.1 | 1 - target/linux/bcm63xx/config-5.15 | 1 - target/linux/bmips/bcm6318/config-5.15| 1 + target/linux/bmips/bcm6318/config-6.1 | 1 + target/linux/bmips/bcm63268/config-5.15 | 1 - target/linux/bmips/bcm63268/config-6.1| 1 - target/linux/bmips/bcm6328/config-5.15| 1 + target/linux/bmips/bcm6328/config-6.1 | 1 + target/linux/bmips/bcm6358/config-5.15| 1 + target/linux/bmips/bcm6358/config-6.1 | 1 + target/linux/bmips/bcm6362/config-5.15| 1 - target/linux/bmips/bcm6362/config-6.1 | 1 - target/linux/bmips/bcm6368/config-5.15| 1 - target/linux/bmips/bcm6368/config-6.1 | 1 - target/linux/gemini/config-6.1| 1 - target/linux/generic/config-5.15 | 2 +- target/linux/generic/config-6.1 | 2 +- target/linux/imx/config-5.15 | 1 - target/linux/ipq40xx/config-6.1 | 1 - target/linux/ipq806x/config-6.1 | 1 - target/linux/ixp4xx/config-6.1| 1 - target/linux/kirkwood/config-5.15 | 1 - target/linux/lantiq/ase/config-5.15 | 1 - target/linux/lantiq/falcon/config-5.15| 1 + target/linux/lantiq/xrx200/config-5.15| 1 - target/linux/lantiq/xway/config-5.15 | 1 - target/linux/lantiq/xway_legacy/config-5.15 | 1 + target/linux/layerscape/armv7/config-5.15 | 1 - target/linux/layerscape/armv7/config-6.1 | 1 - target/linux/layerscape/armv8_64b/config-5.15 | 1 - target/linux/layerscape/armv8_64b/config-6.1 | 1 - target/linux/malta/config-5.15| 1 + target/linux/malta/config-6.1 | 1 + target/linux/mediatek/filogic/config-5.15 | 1 - target/linux/mediatek/filogic/config-6.1 | 1 - target/linux/mediatek/mt7622/config-5.15 | 1 - target/linux/mediatek/mt7622/config-6.1 | 1 - target/linux/mediatek/mt7623/config-5.15 | 1 - target/linux/mediatek/mt7623/config-6.1 | 1 - target/linux/mediatek/mt7629/config-5.15 | 1 - target/linux/mediatek/mt7629/config-6.1 | 1 - target/linux/mpc85xx/config-5.15 | 1 - target/linux/mvebu/config-5.15| 1 - target/linux/mvebu/config-6.1 | 1 - target/linux/mxs/config-5.15 | 1 + target/linux/mxs/config-6.1 | 1 + target/linux/octeon/config-5.15 | 1 - target/linux/octeontx/config-5.15 | 1 - target/linux/omap/config-5.15 | 1 - target/linux/oxnas/config-5.15| 1 + target/linux/pistachio/config-5.15| 1 + target/linux/qoriq/config-5.15| 1 - target/linux/qualcommax/config-6.1| 1 + target/linux/ramips/mt7620/config-5.15| 1 + target/linux/ramips/mt7621/config-5.15| 1 + target/linux/ramips/mt76x8/config-5.15| 1 + target/linux/ramips/rt288x/config-5.15| 1 + target/linux/ramips/rt305x/config-5.15| 1 + target/linux/ramips/rt3883/config-5.15| 1 + target/linux/realtek/rtl838x/config-5.15 | 1 + target/linux/realtek/rtl839x/config-5.15 | 1 + target/linux/realtek/rtl930x/config-5.15 | 1 + target/linux/realtek/rtl931x/config-5.15 | 1 + target/linux/rockchip/armv8/config-6.1| 1 + target/linux/sifiveu/config-6.1 | 1 + target/linux/sunxi/config-5.15| 1 - target/linux/sunxi/config-6.1 | 1 - target/linux/tegra/config-5.15| 1 + target/linux/uml/config-5.15
[PATCH RESEND 00/11] Misc kernel config cleanup and small adjustments
Pretty well resending the entire batch. With trivial action, there isn't much else I can do. Did swap out the end patches, the one was low priority and something extra jumped in front of me. Daniel Golle, there isn't a strong theme here other than cleanup. The aim is to get x86 cleaned up, since a VM target would likely start as a copy of the x86/64 setup. This batch is most of the portion which can be shared with non-VM targets. After this there are two questions. First, should x86virt be a TARGET versus a SUBTARGET of x86? Second, it is possible to start from the x86/64 subtarget and remove inapplicable pieces (subtractive configuration), but it is also possible to start from an empty configuration and build up (additive configuration). I'm rather inclined towards the former (subtractive configuration), but the latter is also possible. Right now, getting these pieces of cleanup done sooner, rather than later would be helpful. Elliott Mitchell (11): kernel: change CONFIG_HW_RANDOM default to y kernel/generic: remove CONFIG_FB_NOTIFY kernel: purge CONFIG_FS_MBCACHE kernel: remove ext2 support from kernel kernel/x86: remove CONFIG_HDMI Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL" kernel/x86: move Geode HW random from generic to geode kernel/x86: move SCx200 support from generic to geode kernel/x86: remove CONFIG_M686 from common configuration packages/x86: detect architecture, not x86/64 target kernel/x86: isolate board-specific files to associated architecture package/firmware/intel-microcode/Makefile | 2 +- package/kernel/linux/modules/crypto.mk| 2 +- package/kernel/linux/modules/virt.mk | 4 +-- package/libs/wolfssl/Makefile | 2 +- target/linux/airoha/config-5.15 | 1 - target/linux/apm821xx/config-5.15 | 1 + target/linux/apm821xx/config-6.1 | 1 + target/linux/archs38/config-5.15 | 2 +- target/linux/armsr/armv7/config-6.1 | 1 + target/linux/armsr/armv8/config-6.1 | 1 - target/linux/armsr/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 2 -- target/linux/at91/sama5/config-5.15 | 2 -- target/linux/at91/sama7/config-5.15 | 2 -- target/linux/ath25/config-5.15| 1 - target/linux/ath79/config-5.15| 1 + target/linux/ath79/config-6.1 | 1 + target/linux/bcm27xx/bcm2708/config-6.1 | 2 -- target/linux/bcm27xx/bcm2709/config-6.1 | 2 -- target/linux/bcm27xx/bcm2710/config-6.1 | 2 -- target/linux/bcm27xx/bcm2711/config-6.1 | 2 -- target/linux/bcm47xx/config-5.15 | 1 - target/linux/bcm4908/config-5.15 | 1 + target/linux/bcm4908/config-6.1 | 1 + target/linux/bcm53xx/config-5.15 | 1 - target/linux/bcm53xx/config-6.1 | 1 - target/linux/bcm63xx/config-5.15 | 1 - target/linux/bmips/bcm6318/config-5.15| 1 + target/linux/bmips/bcm6318/config-6.1 | 1 + target/linux/bmips/bcm63268/config-5.15 | 1 - target/linux/bmips/bcm63268/config-6.1| 1 - target/linux/bmips/bcm6328/config-5.15| 1 + target/linux/bmips/bcm6328/config-6.1 | 1 + target/linux/bmips/bcm6358/config-5.15| 1 + target/linux/bmips/bcm6358/config-6.1 | 1 + target/linux/bmips/bcm6362/config-5.15| 1 - target/linux/bmips/bcm6362/config-6.1 | 1 - target/linux/bmips/bcm6368/config-5.15| 1 - target/linux/bmips/bcm6368/config-6.1 | 1 - target/linux/gemini/config-6.1| 2 -- target/linux/generic/config-5.15 | 6 ++--- target/linux/generic/config-6.1 | 6 ++--- target/linux/imx/config-5.15 | 2 -- target/linux/ipq40xx/config-6.1 | 1 - target/linux/ipq806x/config-6.1 | 1 - target/linux/ixp4xx/config-6.1| 2 -- target/linux/kirkwood/config-5.15 | 1 - target/linux/lantiq/ase/config-5.15 | 1 - target/linux/lantiq/falcon/config-5.15| 1 + target/linux/lantiq/xrx200/config-5.15| 1 - target/linux/lantiq/xway/config-5.15 | 1 - target/linux/lantiq/xway_legacy/config-5.15 | 1 + target/linux/layerscape/armv7/config-5.15 | 2 -- target/linux/layerscape/armv7/config-6.1 | 2 -- target/linux/layerscape/armv8_64b/config-5.15 | 2 -- target/linux/layerscape/armv8_64b/config-6.1 | 2 -- target/linux/malta/config-5.15| 2 +- target/linux/malta/config-6.1 | 2 +- target/linux/mediatek/filogic/config-5.15 | 2 -- target/linux/mediatek/filogic/config-6.1 | 2 -- target/linux/mediatek/mt7622/config-5.15 | 2 -- target/linux/mediatek/mt7622/config-6.1 | 2 -- target/linux/mediatek/mt7623/config-5.15 | 2 -- target/linu
[PATCH RESEND 02/11] kernel/generic: remove CONFIG_FB_NOTIFY
Date: Tue, 25 Apr 2023 16:23:20 -0700 This option is automatically enabled by CONFIG_FB=y. There is no reason to specifically enable it. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/generic/config-5.15 | 1 - target/linux/generic/config-6.1 | 1 - 2 files changed, 2 deletions(-) diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 index 09628ef0da..09bd33c3d6 100644 --- a/target/linux/generic/config-5.15 +++ b/target/linux/generic/config-5.15 @@ -1984,7 +1984,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set diff --git a/target/linux/generic/config-6.1 b/target/linux/generic/config-6.1 index 25c5eb0863..5e0362ee49 100644 --- a/target/linux/generic/config-6.1 +++ b/target/linux/generic/config-6.1 @@ -2072,7 +2072,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Fri, Dec 08, 2023 at 06:53:31PM +0100, Thibaut wrote:
>
> > Le 8 déc. 2023 à 16:39, Elliott Mitchell a écrit :
> >
> > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> >> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote:
> >>>
> >>> On 8.12.2023 11:02, Robert Marko wrote:
> >>>> On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote:
> >>>>>
> >>>>> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> >>>>> just another subtarget of it (I'm aware of A53 vs. A73)?
> >>>>
> >>>> That depends on how much is shared between the AX SoC-s and the BE
> >>>> ones(IPQ95xx and IPQ53xx).
> >>>
> >>> I would say enough to keep them together.
> >>>
> >>>> But, I would prefer that or qualcommbe target where new BE SoC-s will
> >>>> be subtargets.
> >>>
> >>> I'm personally more a fan of limiting number of top targets and deal
> >>> with differences under subtargets.
> >>
> >> Same here, better than to add more targets especially since a lot is
> >> shared.
> >
> > This leads to needing more levels of organization. Instead of simply
> > TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET. If
> > this is going to be done, then the implementation should allow for an
> > arbitrary number of levels.
> >
> > A makefile fragment I created for testing:
> >
> > foo := foo0
> > SUBfoo := foo1
> > SUBSUBfoo := foo2
> >
> > define recur
> > $(info current is $(1), value is $($(1
> > ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> > endef
> >
> > ignore := $(call recur,foo)
> >
> > all: test.make
> > @true
> >
> > So an arbitrary number of levels seems doable.
>
> No.
>
> > Will mean rather
> > substantial changes to the build system though. I tend to favor this
> > as the 2 level limitation is already placing restrictions on the scaling
> > of the build count.
>
> It appears most people do not understand that {sub}+targets use the exact
> same amount of build resources *each* as a whole target. There is no benefit,
> from the PoV of the (phase1) builders, to having more subtargets vs more
> targets: either way, growing either number indefinitely is simply not
> sustainable. Please don’t do that.
>
So, you would prefer to have all of a small cupcake, to a slice of a
much larger cake?
You would prefer to be the big fish in the small pond to the small fish
in the much larger lake?
This is not an invalid choice, but usually projects prefer to grow than
shrink. Also, while having more levels should allow better organization
and then more growth; making growth possible does not force growth to
occur.
What I've observed from rather a lot of wildly different builds in the
past month differs. Most of any OpenWRT build is unshared, but some
portions are reused and substantially greater portions could be reused.
Notably the compiler was reused. If steps were taken to allow reusing
unpacked kernel source, the kernel would only need to be unpacked once
(some of the patches I've sent aim in this direction).
One thing I've noticed is the single-thread portions are a *major*
holdback at this point. The single-thread unpacking of various tarballs
completely overwhelmed the portions of builds which used multiple
processors.
Right now my storage is sick and providing poor write performance (wow,
that battery-backed cache was *impressive*!), yet all OpenWRT builds
averaged less than a single processor in use. That is rather concerning.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: > On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: > > > > On 8.12.2023 11:02, Robert Marko wrote: > > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > >> > > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx > > >> just another subtarget of it (I'm aware of A53 vs. A73)? > > > > > > That depends on how much is shared between the AX SoC-s and the BE > > > ones(IPQ95xx and IPQ53xx). > > > > I would say enough to keep them together. > > > > > But, I would prefer that or qualcommbe target where new BE SoC-s will > > > be subtargets. > > > > I'm personally more a fan of limiting number of top targets and deal > > with differences under subtargets. > > Same here, better than to add more targets especially since a lot is shared. This leads to needing more levels of organization. Instead of simply TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET. If this is going to be done, then the implementation should allow for an arbitrary number of levels. A makefile fragment I created for testing: foo := foo0 SUBfoo := foo1 SUBSUBfoo := foo2 define recur $(info current is $(1), value is $($(1 ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1))) endef ignore := $(call recur,foo) all: test.make @true So an arbitrary number of levels seems doable. Will mean rather substantial changes to the build system though. I tend to favor this as the 2 level limitation is already placing restrictions on the scaling of the build count. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] build: remove shell.sh
Handling common shell usage may have been valuable in the past. Yet now
this is almost unused, so inline the single remaining use. Then delete
the old file.
Signed-off-by: Elliott Mitchell
---
I've tried to test the removal. I'm unsure I actually achieved
coverage, so a careful look at package/kernel/mac80211/Makefile by
someone else would be good.
---
include/shell.sh | 15 ---
include/unpack.mk| 4 ++--
package/kernel/mac80211/Makefile | 2 +-
rules.mk | 1 -
4 files changed, 3 insertions(+), 19 deletions(-)
delete mode 100644 include/shell.sh
diff --git a/include/shell.sh b/include/shell.sh
deleted file mode 100644
index 6ee0cf6030..00
--- a/include/shell.sh
+++ /dev/null
@@ -1,15 +0,0 @@
-getvar() {
- eval "echo \"\${$1}\""
-}
-
-var2file() {
- local var
- eval "var=\"\${$1}\""
- if [ -n "$var" ]; then echo "$var" > "$2"; fi
-}
-
-isset() {
- local var
- eval "var=\"\${$1}\""
- [ -n "$var" ]
-}
diff --git a/include/unpack.mk b/include/unpack.mk
index 5959d55f4b..a120a6093d 100644
--- a/include/unpack.mk
+++ b/include/unpack.mk
@@ -62,10 +62,10 @@ ifeq ($(strip $(UNPACK_CMD)),)
endif
ifdef PKG_BUILD_DIR
- PKG_UNPACK ?= $(SH_FUNC) $(call UNPACK_CMD,$(PKG_BUILD_DIR))
+ PKG_UNPACK ?= $(call UNPACK_CMD,$(PKG_BUILD_DIR))
endif
ifdef HOST_BUILD_DIR
- HOST_UNPACK ?= $(SH_FUNC) $(call UNPACK_CMD,$(HOST_BUILD_DIR))
+ HOST_UNPACK ?= $(call UNPACK_CMD,$(HOST_BUILD_DIR))
endif
endif # PKG_SOURCE
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 9016e2a525..8aef63d868 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -365,7 +365,7 @@ define Quilt/Refresh/Package
endef
define Build/Compile
- $(SH_FUNC) var2file "$(call shvar,mac80211_config)"
$(PKG_BUILD_DIR)/.config
+ [ -z "{$(call shvar,mac80211_config)}" ] || echo "{$(call
shvar,mac80211_config)}" > "$(PKG_BUILD_DIR)/.config"
$(MAKE) $(MAKE_OPTS) allnoconfig
$(call Build/Compile/kmod)
endef
diff --git a/rules.mk b/rules.mk
index 6f05047f26..f09ea1ecc4 100644
--- a/rules.mk
+++ b/rules.mk
@@ -234,7 +234,6 @@ endif
export ORIG_PATH:=$(if $(ORIG_PATH),$(ORIG_PATH),$(PATH))
export PATH:=$(TARGET_PATH)
export STAGING_DIR STAGING_DIR_HOST STAGING_DIR_HOSTPKG
-export SH_FUNC:=. $(INCLUDE_DIR)/shell.sh;
PKG_CONFIG:=$(STAGING_DIR_HOST)/bin/pkg-config
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] scripts/kconfig.pl: consistently call parse_expr() with 2 args
The inconsistent calling had already been noticed. Now the trap
has been spotted, so clean this up.
Signed-off-by: Elliott Mitchell
---
scripts/kconfig.pl | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/kconfig.pl b/scripts/kconfig.pl
index 5a53e2154b..5f0741ee5c 100755
--- a/scripts/kconfig.pl
+++ b/scripts/kconfig.pl
@@ -125,9 +125,9 @@ sub dump_config($) {
}
}
-sub parse_expr {
- my $pos = shift;
- my $mod_plus = shift;
+sub parse_expr($$);
+sub parse_expr($$) {
+ my ($pos, $mod_plus) = @_;
my $arg = $arg[$$pos++];
my %ops = (
@@ -142,7 +142,7 @@ sub parse_expr {
die "Parse error" if (!$arg);
if (exists($ops{$arg})) {
- my $arg1 = parse_expr($pos);
+ my $arg1 = parse_expr($pos, 0);
my $arg2 = parse_expr($pos, ($arg eq 'm+') ? 1 : 0);
return &{$ops{$arg}->[0]}($arg1, $arg2, $ops{$arg}->[1]);
} else {
@@ -163,5 +163,5 @@ while (@ARGV > 0 and $ARGV[0] =~ /^-\w+$/) {
@arg = @ARGV;
my $pos = 0;
-dump_config(parse_expr(\$pos));
+dump_config(parse_expr(\$pos, 0));
die "Parse error" if ($arg[$pos]);
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/5] scripts/kconfig.pl: switch to using function references/hash for operators
Ah, the wonders of pointers. Simplifies the configuration parsing
as all these cases are otherwise identical.
Signed-off-by: Elliott Mitchell
---
Oy vey. I only spotted passing the second arg to parse_expr() *just*
before I was initially planning to send this. That is quite the boody
trap lurking there.
---
scripts/kconfig.pl | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/scripts/kconfig.pl b/scripts/kconfig.pl
index dd286479b3..5a53e2154b 100755
--- a/scripts/kconfig.pl
+++ b/scripts/kconfig.pl
@@ -130,32 +130,21 @@ sub parse_expr {
my $mod_plus = shift;
my $arg = $arg[$$pos++];
+ my %ops = (
+ '&' => [\_and, undef],
+ '+' => [\_add, 0],
+ 'm+'=> [\_add, 1],
+ '>' => [\_diff, 0],
+ '>+'=> [\_diff, 1],
+ '-' => [\_sub, undef],
+ );
+
die "Parse error" if (!$arg);
- if ($arg eq '&') {
- my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos);
- return config_and($arg1, $arg2, undef);
- } elsif ($arg =~ /^\+/) {
- my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos);
- return config_add($arg1, $arg2, 0);
- } elsif ($arg =~ /^m\+/) {
- my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos, 1);
- return config_add($arg1, $arg2, 1);
- } elsif ($arg eq '>') {
- my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos);
- return config_diff($arg1, $arg2, 0);
- } elsif ($arg eq '>+') {
- my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos);
- return config_diff($arg1, $arg2, 1);
- } elsif ($arg eq '-') {
+ if (exists($ops{$arg})) {
my $arg1 = parse_expr($pos);
- my $arg2 = parse_expr($pos);
- return config_sub($arg1, $arg2, undef);
+ my $arg2 = parse_expr($pos, ($arg eq 'm+') ? 1 : 0);
+ return &{$ops{$arg}->[0]}($arg1, $arg2, $ops{$arg}->[1]);
} else {
return load_config($arg, $mod_plus);
}
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/5] scripts/kconfig.pl: modify config_and()/config_sub() to match other ops
Having all operator-handling functions match the same prototype has
advantages.
Signed-off-by: Elliott Mitchell
---
scripts/kconfig.pl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig.pl b/scripts/kconfig.pl
index f7b3814cdd..dd286479b3 100755
--- a/scripts/kconfig.pl
+++ b/scripts/kconfig.pl
@@ -43,8 +43,8 @@ sub load_config($$) {
}
-sub config_and($$) {
- my ($cfg1, $cfg2) = @_;
+sub config_and($$$) {
+ my ($cfg1, $cfg2, $mod_plus_discarded) = @_;
my %config;
foreach my $config (keys %$cfg1) {
@@ -89,8 +89,8 @@ sub config_diff($$$) {
return \%config
}
-sub config_sub($$) {
- my ($cfg1, $cfg2) = @_;
+sub config_sub($$$) {
+ my ($cfg1, $cfg2, $mod_plus_discarded) = @_;
my %config = %{$cfg1};
my @keys = map {
my $expr = $_;
@@ -135,7 +135,7 @@ sub parse_expr {
if ($arg eq '&') {
my $arg1 = parse_expr($pos);
my $arg2 = parse_expr($pos);
- return config_and($arg1, $arg2);
+ return config_and($arg1, $arg2, undef);
} elsif ($arg =~ /^\+/) {
my $arg1 = parse_expr($pos);
my $arg2 = parse_expr($pos);
@@ -155,7 +155,7 @@ sub parse_expr {
} elsif ($arg eq '-') {
my $arg1 = parse_expr($pos);
my $arg2 = parse_expr($pos);
- return config_sub($arg1, $arg2);
+ return config_sub($arg1, $arg2, undef);
} else {
return load_config($arg, $mod_plus);
}
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/5] Scripting tweaks
Due to needing to figure out how the build process functions, I ended up looking at scripts/kconfig.pl. Part of figuring out any program is looking at them and figuring out their operation. My understanding is still incomplete, but I do know more about the function. I can state `kconfig.pl` takes arguments in a form similar to `expr`, but uses operator prefix notation. I decided I didn't need to dig further. I'm glad I spotted the situation with parse_expr() during my review, I almost sent a version with a bug. The file is presently marked as GPLv2. I propose moving to GPLv2 or later, which is easy right now with only 2 authors. Then when looking at this, the situation with include/shell.sh jumped out. Seems like a good removal. I've attempted to test, but I fear I may not have quite confirmed I got the removal right. I fear the e-mail situation is still unresolved. Alas, this is what spam has done to e-mail. It used to be rather faster and more reliable than letters, yet now. Elliott Mitchell (5): scripts/kconfig.pl: fixup subroutine style scripts/kconfig.pl: modify config_and()/config_sub() to match other ops scripts/kconfig.pl: switch to using function references/hash for operators scripts/kconfig.pl: consistently call parse_expr() with 2 args build: remove shell.sh include/shell.sh | 15 --- include/unpack.mk| 4 +- package/kernel/mac80211/Makefile | 2 +- rules.mk | 1 - scripts/kconfig.pl | 76 5 files changed, 30 insertions(+), 68 deletions(-) delete mode 100644 include/shell.sh -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/5] scripts/kconfig.pl: fixup subroutine style
Match usual Perl style to make the operation of the script easier
to understand for future developers.
Signed-off-by: Elliott Mitchell
---
scripts/kconfig.pl | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/scripts/kconfig.pl b/scripts/kconfig.pl
index 392f1d5841..f7b3814cdd 100755
--- a/scripts/kconfig.pl
+++ b/scripts/kconfig.pl
@@ -13,10 +13,7 @@ my @arg;
my $PREFIX = "CONFIG_";
sub set_config() {
- my $config = shift;
- my $idx = shift;
- my $newval = shift;
- my $mod_plus = shift;
+ my ($config, $idx, $newval, $mod_plus) = @_;
if (!defined($config->{$idx}) or !$mod_plus or
$config->{$idx} eq '#undef' or $newval eq 'y') {
@@ -25,8 +22,7 @@ sub set_config() {
}
sub load_config($$) {
- my $file = shift;
- my $mod_plus = shift;
+ my ($file, $mod_plus) = @_;
my %config;
open FILE, "$file" or die "can't open file '$file'";
@@ -48,8 +44,7 @@ sub load_config($$) {
sub config_and($$) {
- my $cfg1 = shift;
- my $cfg2 = shift;
+ my ($cfg1, $cfg2) = @_;
my %config;
foreach my $config (keys %$cfg1) {
@@ -64,9 +59,7 @@ sub config_and($$) {
sub config_add($$$) {
- my $cfg1 = shift;
- my $cfg2 = shift;
- my $mod_plus = shift;
+ my ($cfg1, $cfg2, $mod_plus) = @_;
my %config;
for ($cfg1, $cfg2) {
@@ -84,9 +77,7 @@ sub config_add($$$) {
}
sub config_diff($$$) {
- my $cfg1 = shift;
- my $cfg2 = shift;
- my $new_only = shift;
+ my ($cfg1, $cfg2, $new_only) = @_;
my %config;
foreach my $config (keys %$cfg2) {
@@ -99,8 +90,7 @@ sub config_diff($$$) {
}
sub config_sub($$) {
- my $cfg1 = shift;
- my $cfg2 = shift;
+ my ($cfg1, $cfg2) = @_;
my %config = %{$cfg1};
my @keys = map {
my $expr = $_;
@@ -117,8 +107,7 @@ sub config_sub($$) {
}
sub print_cfgline($$) {
- my $name = shift;
- my $val = shift;
+ my ($name, $val) = @_;
if ($val eq '#undef' or $val eq 'n') {
print "# $PREFIX$name is not set\n";
} else {
@@ -128,7 +117,7 @@ sub print_cfgline($$) {
sub dump_config($) {
- my $cfg = shift;
+ my ($cfg) = @_;
die "argument error in dump_config" unless ($cfg);
my %config = %$cfg;
foreach my $config (sort keys %config) {
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Sat, Nov 25, 2023 at 07:08:20AM +0100, Felix Fietkau wrote: > On 25.11.23 03:28, Elliott Mitchell wrote: > > On Fri, Nov 24, 2023 at 01:53:01PM +0100, Jonas Gorski wrote: > >> > > I'm fine with the cp -l change, but I think adding all remaining > >> > > modules > >> > > to the rootfs is not something we should do by default (maybe opt-in?) > >> > > >> > Perhaps. This could also be handled by the approach the series as a > >> > whole is aiming for. If kernel module building used a separate object > >> > directory from the kernel build, then modules selected in the device > >> > configuration could be isolated. > >> > >> Maybe instead of putting them into the rootfs, we could wrap them in a > >> special package? Then you can select it if you want to include them in > >> your image or not. No idea what to name it, kmod-remaining? > >> kmod-unaccounted-for? kmod-not-appearing-in-the-definitions? > >> > >> We could also try to wrap any unexpected .kos into autogenerated kmod > >> packages based in their names (e.g. if we find a foo.ko, we > >> autogenerate a kmod-foo.ipk for it), but these wouldn't be selectable > >> then in menuconfig. Also not sure how well the build system would > >> handle dynamic package generation. > >> > >> Also going the other way around, maybe the build system should > >> warn/complain about any .ko found that isn't wrapped in a kmod-* > >> package. > > > > All of these are plausible. I think modules selected in device > > configurations should get built and installed into the root filesystem. > > Otherwise setting a device kernel configuration option to =m is broken. > > > > Whereas forcing the explicit creation of packages for each and every > > kernel module forces duplication of Kconfig functionality. > The duplication you wish to avoid is there for a reason. The way the > kernel build system is set up, it makes it easy to build a highly > customized build for one target, or make a distribution build with > pretty much everything built as module. What it offers no solution for > is to maintain and keep in sync kernel configurations for a wide array > of different (often storage constrained) targets, while keeping a lot of > extra features/drivers optionally installable. > That's exactly what our packaging around kernel modules + our kernel > config handling scripts were made for. > > Since there is no perfect solution, there are always some trade-offs > involved. One of these trade-offs was our choice to not support adding > kernel modules in the device kernel config by selecting them as =m > there. I didn't consider that feature useful enough to justify the cost > of dealing with all the corner cases. > > I still don't fully understand your motivation for adding this feature. > Is it just because you're bothered by having to write some extra > boilerplate code for adding kernel modules? Are there some cases where > the existing system cannot work for what you're trying to do? > Or is there some other reason why you need this? Mostly I strongly dislike setting =m wasting build time and having near- zero effect on the resultant output. In particular I see a build/configuration targetting VMs to likely want to build/include many modules, yet many of those not really deserving their own packages (since many would be unneeded in many cases). > Just to be clear, I'm not opposed to the feature you're proposing in any > way. What I want to avoid is adding something that works for your > special case but quickly breaks in weird ways when other people start > using it. That is quite reasonable. I've pushed this later in my queue since I concluded the aim of the later patches will make a more acceptable approach possible. Hopefully I'll be able to resend the series in a few days, just need some build testing to ensure I didn't break anything. The first two patches are going to remain unchanged as there simply isn't anything which can be done to them. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Fri, Nov 24, 2023 at 01:53:01PM +0100, Jonas Gorski wrote: > > On Mon, 20 Nov 2023 at 02:37, Elliott Mitchell wrote: > > > > On Sat, Nov 18, 2023 at 07:57:35AM +0100, Felix Fietkau wrote: > > > On 17.11.23 22:31, Elliott Mitchell wrote: > > > > On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote: > > > >> On 11.11.23 01:21, Elliott Mitchell wrote: > > > >> > This removes the requirement for to create a package for all modules. > > > >> > Now devices can simply specify in-tree drivers/other to be built as > > > >> > modules and they will be present in the resultant image. > > > >> > > > > >> > Signed-off-by: Elliott Mitchell > > > >> > > > >> It seems to me that this completely ignores the use case of having > > > >> release builds that ship a lot of kernel modules as installable > > > >> packages. Did I misread something? > > > >> If not, this gets a strong NACK from me. > > > > > > > > Should be completely orthogonal, though it could have bugs. > > > > > > > > Using `cp -l` has two valuable effects: First, it reduces storage space > > > > usage. Second, it serves to mark module files as belonging to a > > > > package. > > > > > > > > My goal is previously setting a kernel option to "m" in a configuration > > > > file, but not having a package causes it to be built, then ignored. I > > > > want this to do something sensible, not simply waste electricity > > > > building a module and then tossing it in the garbage. > > > > > > > > Hmm, come to think of it, that should be $(XARGS) (fix on commit?). > > > > > > Thanks for the explanation, it makes more sense to me now. > > > That said, I see a few pitfalls here: > > > > > > 1. If you select kernel modules that depend on other modules selected > > > via kmod packages, you end up with non-functional modules with missing > > > dependencies in the rootfs. > > > > Is this actually that much of a problem? From what I've seen most kmod > > packages handled during image build get preinstalled onto the root fs > > image. As such these would nominally function as long as the packages > > weren't removed. > > If you do a build with ALL_KMODS=y because you don't know which kmods > you may need later on, and want to avoid having to reflash in this > case, there will be plenty of kmod packages build but not installed > into the rootfs. > > > > > Wouldn't this also indicate breakage in the module package anyway? > > No, not necessarily. Let's say there is a kmod-foo that packages FOO > (foo.ko). This is selected as =m. > > Then you run kernel_*config and select BAR=m (bar.ko), since there is > no kmod defined for it. bar.ko has a dependency on foo.ko > > With your patch (AFAIU) the bar.ko would be then installed in the > rootfs, but since foo.ko is packaged separately as a m-package, it > won't be in the rootfs => bar.ko is missing its dependencies in the > rootfs. Yet isn't this breakage in the module package? It has stolen a module away from the kernel configuration. Certainly this is a problem and I've got a rough idea how to solve it. (simply take advantage of what the patch series is aiming for) > > > 2. If the kmod package selection accidentally ends up selecting extra > > > modules that aren't stored in the package, you end up with rootfs bloat. > > > > Eww, that would be gross. As with the above, wouldn't this be indicating > > breakage in the module packaging anyway? > > Maybe, but sometimes modules/drivers in the kernel default to =m for > silly reasons. And again as the above example, if the triggering kmod > package is selected as =m, then the additional modules land in the > rootfs without their dependencies. The inverse is also a problem. If the kernel selected CONFIG_USB=m, then kmod-chaoskey was built, it would be impossible to load the module since usbcore.ko would be unavailable. Both directions currently have breakage. > > > I'm fine with the cp -l change, but I think adding all remaining modules > > > to the rootfs is not something we should do by default (maybe opt-in?) > > > > Perhaps. This could also be handled by the approach the series as a > > whole is aiming for. If kernel module building used a separate object > > directory from the kernel build, then modules selected in the device > > configuration could be isolated. > > Maybe instead of putting them into the rootfs, w
Re: [PATCH 11/20] [WIP] package/target: update to get modules from $(LINUX_OBJ_DIR)
On Sat, Nov 11, 2023 at 10:51:08PM -0800, Elliott Mitchell wrote: > Modules built from kernel source will now be in $(LINUX_OBJ_DIR). > > Signed-off-by: Elliott Mitchell > --- > package/kernel/linux/modules/block.mk| 106 +++ > package/kernel/linux/modules/can.mk | 36 +-- > package/kernel/linux/modules/crypto.mk | 252 > package/kernel/linux/modules/firewire.mk | 8 +- > package/kernel/linux/modules/fs.mk | 100 +++ > package/kernel/linux/modules/gpio-cascade.mk | 2 +- > package/kernel/linux/modules/hwmon.mk| 98 +++ > package/kernel/linux/modules/i2c.mk | 2 +- > package/kernel/linux/modules/iio.mk | 80 +++--- > package/kernel/linux/modules/input.mk| 26 +- > package/kernel/linux/modules/leds.mk | 20 +- > package/kernel/linux/modules/lib.mk | 76 ++--- > package/kernel/linux/modules/multiplexer.mk | 4 +- > package/kernel/linux/modules/netdevices.mk | 214 +++--- > package/kernel/linux/modules/netfilter.mk| 168 +-- > package/kernel/linux/modules/netsupport.mk | 204 ++--- > package/kernel/linux/modules/nls.mk | 44 +-- > package/kernel/linux/modules/other.mk| 202 ++--- > package/kernel/linux/modules/pcmcia.mk | 14 +- > package/kernel/linux/modules/sound.mk| 98 +++ > package/kernel/linux/modules/spi.mk | 10 +- > package/kernel/linux/modules/usb.mk | 288 +-- > package/kernel/linux/modules/video.mk| 168 +-- > package/kernel/linux/modules/virt.mk | 24 +- > package/kernel/linux/modules/w1.mk | 2 +- > package/kernel/linux/modules/wpan.mk | 20 +- > target/linux/apm821xx/modules.mk | 4 +- > target/linux/armsr/modules.mk| 80 +++--- > target/linux/at91/modules.mk | 18 +- > target/linux/ath79/modules.mk| 2 +- > target/linux/bcm27xx/modules/hwmon.mk| 2 +- > target/linux/bcm27xx/modules/other.mk| 6 +- > target/linux/bcm27xx/modules/sound.mk| 206 ++--- > target/linux/bcm27xx/modules/spi.mk | 4 +- > target/linux/bcm27xx/modules/video.mk| 16 +- > target/linux/bcm47xx/modules.mk | 6 +- > target/linux/bcm53xx/modules.mk | 6 +- > target/linux/bcm63xx/modules.mk | 4 +- > target/linux/bmips/modules.mk| 6 +- > target/linux/gemini/modules.mk | 2 +- > target/linux/ipq806x/modules.mk | 14 +- > target/linux/kirkwood/modules.mk | 4 +- > target/linux/layerscape/modules.mk | 4 +- > target/linux/mediatek/modules.mk | 8 +- > target/linux/mvebu/modules.mk| 4 +- > target/linux/oxnas/modules.mk| 4 +- > target/linux/ramips/modules.mk | 20 +- > target/linux/sunxi/modules.mk| 16 +- > target/linux/x86/modules.mk | 22 +- > 49 files changed, 1362 insertions(+), 1362 deletions(-) The reason this patch ended up so huge was every kernel module package was setting $(FILES) to the absolute path of the module. If instead $(FILES) is set relative to the kernel object directory, and converted to an absolute path during KernelPackage/$(1)/config, this becomes MUCH smaller. Unfortunately in turn the patch to do that ends up jumbo. Can't win. The cleanup has been long needed, but never done. Now it ends up a gigantic patch. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Sat, Nov 18, 2023 at 07:57:35AM +0100, Felix Fietkau wrote: > On 17.11.23 22:31, Elliott Mitchell wrote: > > On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote: > >> On 11.11.23 01:21, Elliott Mitchell wrote: > >> > This removes the requirement for to create a package for all modules. > >> > Now devices can simply specify in-tree drivers/other to be built as > >> > modules and they will be present in the resultant image. > >> > > >> > Signed-off-by: Elliott Mitchell > >> > >> It seems to me that this completely ignores the use case of having > >> release builds that ship a lot of kernel modules as installable > >> packages. Did I misread something? > >> If not, this gets a strong NACK from me. > > > > Should be completely orthogonal, though it could have bugs. > > > > Using `cp -l` has two valuable effects: First, it reduces storage space > > usage. Second, it serves to mark module files as belonging to a package. > > > > My goal is previously setting a kernel option to "m" in a configuration > > file, but not having a package causes it to be built, then ignored. I > > want this to do something sensible, not simply waste electricity > > building a module and then tossing it in the garbage. > > > > Hmm, come to think of it, that should be $(XARGS) (fix on commit?). > > Thanks for the explanation, it makes more sense to me now. > That said, I see a few pitfalls here: > > 1. If you select kernel modules that depend on other modules selected > via kmod packages, you end up with non-functional modules with missing > dependencies in the rootfs. Is this actually that much of a problem? From what I've seen most kmod packages handled during image build get preinstalled onto the root fs image. As such these would nominally function as long as the packages weren't removed. Wouldn't this also indicate breakage in the module package anyway? > 2. If the kmod package selection accidentally ends up selecting extra > modules that aren't stored in the package, you end up with rootfs bloat. Eww, that would be gross. As with the above, wouldn't this be indicating breakage in the module packaging anyway? > I'm fine with the cp -l change, but I think adding all remaining modules > to the rootfs is not something we should do by default (maybe opt-in?) Perhaps. This could also be handled by the approach the series as a whole is aiming for. If kernel module building used a separate object directory from the kernel build, then modules selected in the device configuration could be isolated. > By the way, I still get bounces when replying to you, because your mail > server is refusing my mail. Ick. Welcome to the world of 2023 and what spam has done to e-mail. Alas, this is due to extreme measures being taken by the person who handles this system. We're at a point where small mailservers cannot exist due to the shear amount of spam being generated. I suppose OpenWRT might help by having a default rule to filter out port 25. There is also that yet to be written kernel patch which disables the interfering 2.45GHz channels. There is also the default egress filtering... All those things I could get done if I ruled the world. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote: > On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > > > > Each hypervisor will have a small set of drivers guaranteed to be > > present. These though will be completely different between hypervisors. > > Do you really think having just the (partially shared) drivers for 3 > hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too > much? Those drivers are very tiny... Hopefully I can revise my opinion here. Issue is some hypervisor drivers are small, some are not. I could see having two hypervisor kernel builds. One featuring only the smaller drivers, one featuring the jumbo drivers. I note Virtio-block is fairly small. It operates on top of the block layer and shouldn't require too much extra. The Fusion MPT driver, which VMware requires is a big driver. Not only is the driver itself large, but it then plugs into the SCSI layer which itself is quite substantial. This could be as much as 2-3MB total. This is enough not to want built-in for a kernel meant for other hypervisors. I'm totally unfamiliar with Hyper-V, aside from knowing which company is behind it. I do find the idea of using OpenWRT in a VM on Hyper-V as one's border firewall entertaining. :-) I suspect Hyper-V may require ACPI support, in particular I suspect its virtual network and block interfaces are provided by ACPI table. I'm unsure exactly how much overhead that is, but I suspect it is enough to want a separate kernel (or everything in modules). Additionally Hyper-V may insist upon a graphical console and USB. Both Virtio-SCSI and Xen-pvSCSI rely on the SCSI layer, which is relatively large. Yet those hypervisors have block layer drivers which are rather smaller. So, there might need to be a few distinct kernels for hypervisors, or perhaps an awful lot as initrd modules (enough to load the block drivers for all hypervisors). In case you haven't guessed, all patches I'm posting are headed in the general direction of trying for a slimmer VM kernel build. I'm trying to get CONFIG_HW_RANDOM_GEODE into the Geode build, since it presently leaks into the "64" build and the "64" build would be the obvious basis for a hypervisor kernel. Similar situation for CONFIG_SCx200. I've got some initial patches for a slim VM kernel configuration, but right now things are still at the pre-split cleanup phase. CONFIG_X86_INTEL_LPSS=n seems unlikely for the present "64" configuration, but will be appropriate for a VM kernel. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote: > On 11.11.23 01:21, Elliott Mitchell wrote: > > This removes the requirement for to create a package for all modules. > > Now devices can simply specify in-tree drivers/other to be built as > > modules and they will be present in the resultant image. > > > > Signed-off-by: Elliott Mitchell > > It seems to me that this completely ignores the use case of having > release builds that ship a lot of kernel modules as installable > packages. Did I misread something? > If not, this gets a strong NACK from me. Should be completely orthogonal, though it could have bugs. Using `cp -l` has two valuable effects: First, it reduces storage space usage. Second, it serves to mark module files as belonging to a package. My goal is previously setting a kernel option to "m" in a configuration file, but not having a package causes it to be built, then ignored. I want this to do something sensible, not simply waste electricity building a module and then tossing it in the garbage. Hmm, come to think of it, that should be $(XARGS) (fix on commit?). -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 20/20] [TEST] TESTING: try separating build from sources
In case anyone was wondering, the later patches are marked "WIP" since they hadn't been sufficiently tested. I had run into this a bit ago, but hadn't tracked down the issue. Now that I have, another patch is attached to this message. This is an outright bug in the patch and should be fixed. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 >From f646cfb21288df884534d60ed17a075d9661e9b9 Mon Sep 17 00:00:00 2001 Message-Id: From: Elliott Mitchell Date: Thu, 16 Nov 2023 14:16:01 -0800 Subject: [PATCH] kernel/generic: fix lzma addition patch When including directories, the full path must be used. Otherwise the compiler may fail to find headers. This fixes separated build and source directory functioning. Signed-off-by: Elliott Mitchell --- Similar situation to the bcm27xx patch. Small error in the patch, which requires the right situation to trigger. I figure most likely adjustments are pure style and could be fixed on commit. --- .../generic/pending-5.15/530-jffs2_make_lzma_available.patch| 2 +- .../generic/pending-6.1/530-jffs2_make_lzma_available.patch | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/generic/pending-5.15/530-jffs2_make_lzma_available.patch b/target/linux/generic/pending-5.15/530-jffs2_make_lzma_available.patch index f236657b71..0ca857d000 100644 --- a/target/linux/generic/pending-5.15/530-jffs2_make_lzma_available.patch +++ b/target/linux/generic/pending-5.15/530-jffs2_make_lzma_available.patch @@ -4578,4 +4578,4 @@ Signed-off-by: Alexandros C. Couloumbis +obj-$(CONFIG_LZMA_COMPRESS) += lzma_compress.o +obj-$(CONFIG_LZMA_DECOMPRESS) += lzma_decompress.o + -+EXTRA_CFLAGS += -Iinclude/linux -Iinclude/linux/lzma -include types.h ++EXTRA_CFLAGS += -I$(srctree)/include/linux -I$(srctree)/include/linux/lzma -include types.h diff --git a/target/linux/generic/pending-6.1/530-jffs2_make_lzma_available.patch b/target/linux/generic/pending-6.1/530-jffs2_make_lzma_available.patch index 27a673399a..d413cc91a2 100644 --- a/target/linux/generic/pending-6.1/530-jffs2_make_lzma_available.patch +++ b/target/linux/generic/pending-6.1/530-jffs2_make_lzma_available.patch @@ -5177,4 +5177,4 @@ Signed-off-by: Alexandros C. Couloumbis +obj-$(CONFIG_LZMA_COMPRESS) += lzma_compress.o +obj-$(CONFIG_LZMA_DECOMPRESS) += lzma_decompress.o + -+EXTRA_CFLAGS += -Iinclude/linux -Iinclude/linux/lzma -include types.h ++EXTRA_CFLAGS += -I$(srctree)/include/linux -I$(srctree)/include/linux/lzma -include types.h -- 2.39.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Xen VM Configuration example
I'm sending this to the list to provide another approach to this type of installation. I feel this is better adapted to the situation than the currently visible examples. Feel free to use this information in the OpenWRT wiki. Hopefully this is also a better example of a real world OpenWRT in VM usage will look like. I suggest the information on containers should be split into a separate section. This could be a sub-section of Virtualization, but containers are far more limited than VMs. Notably containers won't use OpenWRT's kernel or drivers. My recommended template configuration for OpenWRT in a Xen domain (VM): ``` type = "pv" name = "openwrt" memory = 128 vcpus = 2 # For use with rootfs/kernel.bin: kernel = "/location/of/openwrt/kernel.bin" extra = "root=/dev/xvda" disk = [ 'vdev=xvda,format=raw,access=ro,target=/location/of/openwrt/rootfs.img', 'vdev=xvdb,format=raw,access=rw,target=/location/of/openwrt/data.img', ] # For use with -combined image: #kernel = "/usr/libexec/grub/pvgrub-pv.bin" #extra = "(hd1,gpt1)/boot/grub/grub.cfg" # #disk = [ # 'vdev=xvda,format=raw,access=rw,target=/location/of/openwrt/combo.img', #] vif = [ 'bridge=br-lan', # 'bridge=br-wan', ] pci = [ # ':04:00.0', ] nographic = 1 serial = 'pty' ``` Installation is done by downloading the files openwrt--rootfs.img.gz (match with xvda/rootfs.img line) and openwrt--kernel.bin (match with "kernel =" line). The file "data.img" is created by `truncate -s 32M data.img`, on first boot run `xl console openwrt` and at the shell in the VM run `mke2fs -t ext4 /dev/xvdb`. After that reboot and "data.img" functions as the overlaid filesystem. A crucial advantage of this is the root filesystem and kernel are completely read-only inside the VM. No persistent modification of them is possible (though the in-memory image can be modified). This both enhances security, and allows sharing them between multiple VMs which handle different network functions (splitting NAT off allows rebooting the hardware without dropping connections). The combined image can also be used, but the installation and configuration are a bit different (see commented lines above). The "kernel =" line should be adjusted to match where PvGRUB is installed. For some distributions, PvGRUB may be available packaged, but the installation path may vary. Also PVH VMs may require a distinct build of PvGRUB from other VM types. Presently I'm trying to figure out which approach should be preferred. My suspicion is security updates will be easier with the combined image. This would outweigh the above advantage. During initial bring-up the user may want public interfaces disabled. As such both potential methods have been left commentted in this example. Once initial configuration (setting root's password!) is done, the publically visible interfaces can be enabled. This could be a bridge to hardware handled by another VM, or could be a PCI device being passed-in. Often one would pass-in an 802.11 interface to allow radio support. As of Xen 4.17 passing PCI devices into "PVH" VMs hadn't been enabled. Until this is addressed the configuration 'type = "pv"' will be needed if PCI passthrough is used. Things done here mostly apply to other hypervisors, though the configuration mechanism will be different. Qemu definitely allows passing in storage devices as read-only, passing in PCI cards, and removing all emulated graphics devices. Most (if not all) hypervisors will allow passing in storage devices as read-only and passing PCI devices in. As to why one would do this. At least one reason is pretty straightforward, just in the exact opposite direction from what most have been thinking. Many latest generation semi-embedded devices advertise being capable of functioning as NAS, and/or handling server functions. If one has a decent server computer which includes IOMMU and hypervisor, then instead of shedding server functions onto a router, the server can instead swallow the router. A second NIC is $10 (assuming no on-motherboard spare), a good 802.11 card is $50. This seems appropriate for a home or small office. Just an issue of whether there is a server with available processor, memory, and slot(s). This doesn't need a particularly powerful computer, but with everything virtual machine, memory is a severe limiter. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 06/20] kernel: remove drivers marked as modules
On Wed, Nov 15, 2023 at 11:29:23AM +0100, Bjørn Mork wrote: > Elliott Mitchell writes: > > > Previously these would get built, then simply omitted from the > > resultant image. > > A kernel image built with a config symbol set to 'm' is sometimes > deliberately differerent from an image built with the same symbol set > to 'n'. The kernel is sprinkled with IS_ENABLED() or similar open coded > tests. Some of the symbols you are removing are tested. > > Did you verify that all these changes still produce the same kernel > images as before? No, I haven't. I would tend to look at the git log to find out why those were added (no mention would suggest accident), but the git log is rather troublesome for the config files. I'll try to take a look, but right now I'm spending time testing the split of kernel source and kernel build. OpenWRT appears to have quite a number of issues there. If enabling those as modules helps then something is very wrong. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
On Wed, Nov 15, 2023 at 10:36:21AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: > > > I don't know the future, but enabling kernel support is the first step. > > If you wanted to add it to Debian (with working a multi-arch > implementation and organically grown repositories (which aren't > rebuild aside from sourceful uploads or targeted binNMUs), you would > be right - for OpenWrt, no, there really is no need to enable it, > before you have the rest of the x32 subtarget ready to be merged (and > I can't imagine any reason to enable it for the current OpenWrt x86_64 > subtarget at all). So you would be against enabling the kernel support before userspace is ready? Meanwhile everyone else would be against working on userspace without it being enabled in the kernel... That doesn't really work too well. > For OpenWrt, I could imagine only two approaches to this: > - make the x86_64 subtarget x32-only > - add a new x32-only subtarget and leave x86_64 as it is > Neither would really be 'sensible', but the only workable approach > would imho be the later, even if the intention was (I hope not to > witness that) to kill off the old x86_64 target. I agree with this. One comment though, I suspect OpenWRT VM installations will remain below 4GB of memory for quite some time. As such x32 would be a "free" performance boost/memory reduction if upstream sources support x32 (yeah, this is a big if). > So I really don't see any reason to enable x32 for the x86_64 subtarget, > there's nothing to be gained, just major disadvantages. > While I'm not a proponent for a pure-x32 subtarget either (at all), this > would be the only workable approach to introduce it. At a glance it looks like some useful gains for not too much cost. >From my perspective though this isn't a crucial part of my goal. So I'm likely to drop further discussion as this the cost:benefit isn't there. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: > > Date: Thu, 30 Mar 2023 16:30:49 -0700 > > > > Full amd64 support isn't really appropriate for most situations > > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > > these situations. As such enable x86-x32 support. > > > > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, > > otherwise the kernel build breaks. > > > > Signed-off-by: Elliott Mitchell > > --- > > > > I suggest OpenWRT should place some effort towards x86-x32. x86-x32 > > seems a rather superior generic target for OpenWRT. Only issue is > > it could be valuable to have at least minimal amd64 userland support > > alongside the x86-x32 version. > > > > Note, this simply enables kernel support. Until userspace building > > is added, this does almost nothing. > > What would be the reason for enabling x32? > There is very little upstream buy-in for x32, when this question came > up for Debian, it was rejected to be enabled for -among other reasons- > concerns about the the system call ABI and its security hardening, as > well as concerns about the long term ABI compatibility (the later of > which probably not that relevant for OpenWrt, the former however is). What I see seems like x32 is still making progress on Debian. I note musl has a x32 target. While it still isn't a release architecture for Debian, I could see it becoming one. > I do understand that this is a pet peeve among the high-density > virtualization crowd, but anywhere else, x32 as a concept is dead (and > never took off in the first place). In my view x32 has some substantial use cases. Have you ever seen `ls`, `rm`, `grep`, `find`, or `test` needing more than 4GB of memory? Any of these needing that much memory would suggest something was wrong (or perhaps someone was trying to abuse them in an impressive way). For quite a number of shell utilities being able to use more than 4GB of memory is pointless. This is speculation, but I suspect there would be substantial value in having mixed systems where some utilities were x32 and some were amd64. > *If* (and imho, again purely my own irrelevant opinion, that is a > big IF) x32 would really be deemed worthwhile for OpenWrt, it still > doesn't make sense to enable this whole userspace ABI for the x86_64 > kernel now, before your desired additional patches are available > (and even then, you'd probably want a dedicated x32 subtarget instead > of killing off the pure64 target for OpenWrt - something I'd > personally be even less in favour of). Enabling the kernel support is always the first step. How does one test userspace if the kernel won't even load the executables? > That aside, I may be confused by the config stacking order, but... > If I read it correctly, you enable CONFIG_X86_X32 in > target/linux/x86/config-*, while explicitly disabling it in the > only subtarget config (target/linux/x86/64/config-*) where it > would matter, is that really the intended way round and in line > with the commit description? Previously x32 was explicitly disabled in x86/64/config subtarget. This removes that, then enables it in x86/config target. On Wed, Nov 15, 2023 at 05:41:54AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-15, Stefan Lippers-Hollmann wrote: > > What would be the reason for enabling x32? > > There is very little upstream buy-in for x32, when this question came > > up for Debian, it was rejected to be enabled for -among other reasons- > > concerns about the the system call ABI and its security hardening, as > > well as concerns about the long term ABI compatibility (the later of > > which probably not that relevant for OpenWrt, the former however is). > > Just to add some references to this: > - Can we drop upstream Linux x32 support? > https://lkml.org/lkml/2018/12/10/1145 > the whole thread is interesting and doesn't display too much > sympathy for x32 Yes, and did it get dropped? No, it didn't. At least some of the issues brought up there have been fixed. > - information about the never merged/ defunct x32 port proposed for > Debian > https://wiki.debian.org/X32Port There are pointers to many bugs which were found and fixed. There don't appear to be that many unresolved ones. Unfortunately I don't know whether it is likely to be part of the next formal release. I also note even the most extreme of the OpenWRT virtual machine suggestions doesn't suggest more than 4GB of memory. I don't know the future, but enabling kernel support is the first step. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig.
Re: [PATCH 08/11] kernel/x86: move SCx200 support from generic to geode
On Wed, Nov 15, 2023 at 05:05:00AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: > > Date: Thu, 13 Apr 2023 17:07:20 -0700 > > > > The SCx200 is part of the Geode platform. As such generic x86 > > doesn't need the driver, but Geode does. > > Not objecting against this patch, just taking it as an opportunity to ask > an orthogonal question... > > Are three 32-bit x86 subtargets still needed/ warranted? > I mean all of these targets are basically obsolete and very low-end/ > low-speed (hard to compete against mt7621a), so do the subtarget > specific optimizations really make sense anymore (are there any rough > performance comparisons or other reasons to keep them separate)? I stated this in a previous message. In my view the current "generic" target is worthless. It is only useful to a small number of computers and not worthy of having a specific target. I would suggest it may be worthwhile splitting "64" besides having virtual machine targets. Early amd64 computers did feature AGP and PATA, but those rapidly disappeared shortly after the architecture came into existance. Perhaps "old64" and "current64"? Dunno. "geode" seems worthwhile since the processors were manufactured into 2019 and they are semi-embedded. Having 2 generalized/desktop x86 targets seems too few, but 3 generalized/desktop x86 targets seems too many. Another way to evaluate is to consider the number of years covered by a given target: geode: 1999-2019 generic: 2000-2004 legacy: 1996-2007 64: 2003-2023 Which clearly paints "generic" as the one to eliminate. Whereas "64" should be under consideration for splitting. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 20/20] [TEST] TESTING: try separating build from sources
Check whether all the spots have been handled. This hasn't been tried in a long while, I doubt I've got everything right. Signed-off-by: Elliott Mitchell --- include/kernel.mk | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index 7f236ece45..4afc9eaf4e 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -44,11 +44,10 @@ else FILES_DIR ?= $(foreach dir,$(wildcard $(CURDIR)/files $(CURDIR)/files-$(KERNEL_PATCHVER)),"$(dir)") endif KERNEL_BUILD_DIR ?= $(BUILD_DIR)/linux-$(BOARD)$(if $(SUBTARGET),_$(SUBTARGET)) - LINUX_DIR ?= $(KERNEL_BUILD_DIR)/linux-$(LINUX_VERSION) # Location of kernel source files - LINUX_SRC_DIR ?= $(LINUX_DIR) + LINUX_SRC_DIR ?= $(KERNEL_BUILD_DIR)/linux-$(LINUX_VERSION) # Location of kernel object files - LINUX_OBJ_DIR ?= $(LINUX_DIR) + LINUX_OBJ_DIR ?= $(KERNEL_BUILD_DIR)/linux-$(LINUX_VERSION)-$(PROFILE) LINUX_UAPI_DIR=uapi/ LINUX_VERMAGIC:=$(strip $(shell cat $(LINUX_OBJ_DIR)/.vermagic 2>/dev/null)) LINUX_VERMAGIC:=$(if $(LINUX_VERMAGIC),$(LINUX_VERMAGIC),unknown) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19/20] [WIP] build: point remainder at $(LINUX_SRC_DIR)
These appear to need the kernel source, but my confidence is less than certain on several spots. Signed-off-by: Elliott Mitchell --- include/kernel-defaults.mk | 6 +++--- package/kernel/cryptodev-linux/Makefile | 2 +- package/kernel/linux/modules/w1.mk | 4 ++-- package/kernel/qca-ssdk/Makefile | 2 +- package/network/utils/arptables/Makefile | 2 +- target/imagebuilder/Makefile | 2 +- target/imagebuilder/files/Makefile | 4 ++-- target/sdk/Makefile | 6 +++--- toolchain/kernel-headers/Makefile| 2 +- 9 files changed, 15 insertions(+), 15 deletions(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 178d4c0a5d..a170e86cef 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -31,10 +31,10 @@ ifeq ($(strip $(CONFIG_EXTERNAL_KERNEL_TREE)),"") else define Kernel/Prepare/Default mkdir -p $(KERNEL_BUILD_DIR) - if [ -d $(LINUX_DIR) ]; then \ - rmdir $(LINUX_DIR); \ + if [ -d $(LINUX_SRC_DIR) ]; then \ + rmdir $(LINUX_SRC_DIR); \ fi - ln -s $(CONFIG_EXTERNAL_KERNEL_TREE) $(LINUX_DIR) + ln -s $(CONFIG_EXTERNAL_KERNEL_TREE) $(LINUX_SRC_DIR) if [ -d $(LINUX_OBJ_DIR)/user_headers ]; then \ rm -rf $(LINUX_OBJ_DIR)/user_headers; \ fi diff --git a/package/kernel/cryptodev-linux/Makefile b/package/kernel/cryptodev-linux/Makefile index 0c1f63a605..40692eb060 100644 --- a/package/kernel/cryptodev-linux/Makefile +++ b/package/kernel/cryptodev-linux/Makefile @@ -47,7 +47,7 @@ endef define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) \ $(KERNEL_MAKE_FLAGS) \ - KERNEL_DIR="$(LINUX_DIR)" + KERNEL_DIR="$(LINUX_SRC_DIR)" endef define Build/InstallDev diff --git a/package/kernel/linux/modules/w1.mk b/package/kernel/linux/modules/w1.mk index e6b5263e2c..55d7e60cca 100644 --- a/package/kernel/linux/modules/w1.mk +++ b/package/kernel/linux/modules/w1.mk @@ -6,8 +6,8 @@ # W1_MENU:=W1 support -W1_MASTERS_DIR:=$(LINUX_DIR)/drivers/w1/masters -W1_SLAVES_DIR:=$(LINUX_DIR)/drivers/w1/slaves +W1_MASTERS_DIR:=$(LINUX_SRC_DIR)/drivers/w1/masters +W1_SLAVES_DIR:=$(LINUX_SRC_DIR)/drivers/w1/slaves define KernelPackage/w1 SUBMENU:=$(W1_MENU) diff --git a/package/kernel/qca-ssdk/Makefile b/package/kernel/qca-ssdk/Makefile index 3770d29e8c..69e1eff8b1 100644 --- a/package/kernel/qca-ssdk/Makefile +++ b/package/kernel/qca-ssdk/Makefile @@ -36,7 +36,7 @@ LNX_CONFIG_OPTS = LNX_MAKEOPTS='$(KERNEL_MAKEOPTS)' MODULE_TYPE=KSLIB modules MAKE_FLAGS+= \ TARGET_NAME=$(CONFIG_TARGET_NAME) \ TOOL_PATH=$(firstword $(TOOLCHAIN_BIN_DIRS)) \ - SYS_PATH=$(LINUX_DIR) \ + SYS_PATH=$(LINUX_SRC_DIR) \ TOOLPREFIX=$(TARGET_CROSS) \ KVER=$(LINUX_VERSION) \ ARCH=$(LINUX_KARCH) \ diff --git a/package/network/utils/arptables/Makefile b/package/network/utils/arptables/Makefile index 7f32ed1395..520c7dcf27 100644 --- a/package/network/utils/arptables/Makefile +++ b/package/network/utils/arptables/Makefile @@ -32,7 +32,7 @@ endef MAKE_FLAGS += \ COPT_FLAGS="$(TARGET_CFLAGS) -D__OPTIMIZE__=1" \ - KERNEL_DIR="$(LINUX_DIR)" + KERNEL_DIR="$(LINUX_SRC_DIR)" define Package/arptables-legacy/install $(INSTALL_DIR) $(1)/usr/sbin diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile index c4910b6c4b..1a68f6e374 100644 --- a/target/imagebuilder/Makefile +++ b/target/imagebuilder/Makefile @@ -15,7 +15,7 @@ override MAKEFLAGS= IB_NAME:=$(VERSION_DIST_SANITIZED)-imagebuilder-$(if $(CONFIG_VERSION_FILENAMES),$(VERSION_NUMBER)-)$(BOARD)$(if $(SUBTARGET),-$(SUBTARGET)).$(HOST_OS)-$(HOST_ARCH) PKG_BUILD_DIR:=$(BUILD_DIR)/$(IB_NAME) IB_KDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(KERNEL_BUILD_DIR)) -IB_LDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_DIR)) +IB_LDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_SRC_DIR)) IB_DTSDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_SRC_DIR))/arch/$(LINUX_KARCH)/boot/dts/ IB_IDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(STAGING_DIR_IMAGE)) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index 78ec7e2e94..1e4d91324b 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -184,8 +184,8 @@ package_list: FORCE package_install: FORCE @echo @echo Installing packages... - $(OPKG) install $(firstword $(wildcard $(LINUX_DIR)/libc_*.ipk $(PACKAGE_DIR)/libc_*.ipk)) - $(OPKG) install $(firstword $(wildcard $(LINUX_DIR)/kernel_*.ipk $(PACKAGE_DIR)/kernel_*.ipk)) + $(OPKG) install $(firstword $(wildcard $(LINUX_SRC_DIR)/libc_*.ipk $(PACKAGE_DIR)/libc_*.ipk)) + $(OPKG) install $(firstword $(wildcard $(LINUX_SRC_DIR)/kernel_*.ipk $(PACKAGE_
[PATCH 18/20] [WIP] build: point remaining obvious cases at $(LINUX_SRC_DIR)
make -C is most often needs the kernel source. The copyright files come from the kernel source. Signed-off-by: Elliott Mitchell --- I'm running out of steam on this. These seem fairly clear, but I'm less than 100% certain. --- package/devel/kselftests-bpf/Makefile | 2 +- package/kernel/broadcom-wl/Makefile | 2 +- package/kernel/lantiq/ltq-adsl-mei/Makefile | 2 +- package/kernel/lantiq/ltq-atm/Makefile | 2 +- package/kernel/lantiq/ltq-deu/Makefile | 2 +- package/kernel/lantiq/ltq-ptm/Makefile | 2 +- package/kernel/qca-nss-dp/Makefile | 2 +- target/linux/bcm27xx/image/Makefile | 2 +- target/linux/rockchip/image/Makefile| 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/package/devel/kselftests-bpf/Makefile b/package/devel/kselftests-bpf/Makefile index bb34f0ff5f..ccb5aee465 100644 --- a/package/devel/kselftests-bpf/Makefile +++ b/package/devel/kselftests-bpf/Makefile @@ -51,7 +51,7 @@ MAKE_FLAGS = \ define Build/Compile +$(MAKE_VARS) \ - $(MAKE) $(PKG_JOBS) -C $(LINUX_DIR)/$(MAKE_PATH) \ + $(MAKE) $(PKG_JOBS) -C $(LINUX_SRC_DIR)/$(MAKE_PATH) \ $(MAKE_FLAGS) $(TEST_TARGET) ; endef diff --git a/package/kernel/broadcom-wl/Makefile b/package/kernel/broadcom-wl/Makefile index a1feacbe29..51aa5496ec 100644 --- a/package/kernel/broadcom-wl/Makefile +++ b/package/kernel/broadcom-wl/Makefile @@ -120,7 +120,7 @@ endef define Build/Compile # Compile glue driver - $(MAKE_KMOD) -C "$(LINUX_DIR)" \ + $(MAKE_KMOD) -C "$(LINUX_SRC_DIR)" \ M="$(PKG_BUILD_DIR)/glue" \ modules diff --git a/package/kernel/lantiq/ltq-adsl-mei/Makefile b/package/kernel/lantiq/ltq-adsl-mei/Makefile index e9db785960..647e449e11 100644 --- a/package/kernel/lantiq/ltq-adsl-mei/Makefile +++ b/package/kernel/lantiq/ltq-adsl-mei/Makefile @@ -35,7 +35,7 @@ endef define Build/Compile ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) -C $(LINUX_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR)/ V=1 modules + $(MAKE) -C $(LINUX_SRC_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR)/ V=1 modules endef $(eval $(call KernelPackage,ltq-adsl-danube-mei)) diff --git a/package/kernel/lantiq/ltq-atm/Makefile b/package/kernel/lantiq/ltq-atm/Makefile index af852e9a01..d3a34493d0 100644 --- a/package/kernel/lantiq/ltq-atm/Makefile +++ b/package/kernel/lantiq/ltq-atm/Makefile @@ -40,7 +40,7 @@ endef define Build/Compile ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + $(MAKE) -C $(LINUX_SRC_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-atm-danube)) diff --git a/package/kernel/lantiq/ltq-deu/Makefile b/package/kernel/lantiq/ltq-deu/Makefile index 4b8fae2766..5c151245bd 100644 --- a/package/kernel/lantiq/ltq-deu/Makefile +++ b/package/kernel/lantiq/ltq-deu/Makefile @@ -35,7 +35,7 @@ endef define Build/Compile ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) -C $(LINUX_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + $(MAKE) -C $(LINUX_SRC_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-deu-danube)) diff --git a/package/kernel/lantiq/ltq-ptm/Makefile b/package/kernel/lantiq/ltq-ptm/Makefile index a1fb2250d2..6d7ba98086 100644 --- a/package/kernel/lantiq/ltq-ptm/Makefile +++ b/package/kernel/lantiq/ltq-ptm/Makefile @@ -44,7 +44,7 @@ endef define Build/Compile ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + $(MAKE) -C $(LINUX_SRC_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-ptm-danube)) diff --git a/package/kernel/qca-nss-dp/Makefile b/package/kernel/qca-nss-dp/Makefile index f9e992f246..e55cdc61e8 100644 --- a/package/kernel/qca-nss-dp/Makefile +++ b/package/kernel/qca-nss-dp/Makefile @@ -45,7 +45,7 @@ endef define Build/Compile +$(KERNEL_MAKE) $(PKG_JOBS) \ - -C "$(LINUX_DIR)" \ + -C "$(LINUX_SRC_DIR)" \ M="$(PKG_BUILD_DIR)" \ EXTRA_CFLAGS="$(EXTRA_CFLAGS)" SoC="$(CONFIG_TARGET_SUBTARGET)" \ modules diff --git a/target/linux/bcm27xx/image/Makefile b/target/linux/bcm27xx/image/Makefile index 7fcb78c8f7..fa0633095b 100644 --- a/target/linux/bcm27xx/image/Makefile +++ b/target/linux/bcm27xx/image/Makefile @@ -10,7 +10,7 @@ FAT32_BLOCK_SIZE=1024 FAT32_BLOCKS=$(shell echo $$(($(CONFIG_TARGET_KERNEL_PAR
[PATCH 17/20] [WIP] build: split kernel object directory from kernel source directory
Allows for reusing a kernel source directory for multiple builds.
Alternatively allows cleaning out an old kernel build without needing
to delete source files.
Signed-off-by: Elliott Mitchell
---
I'll confess I'm less than certain about several of these. From
looking I *think* they need the object directory, but this needs
someone to check.
---
package/kernel/bpf-headers/Makefile | 4 ++--
package/network/utils/iptables/Makefile | 2 +-
package/utils/spidev_test/Makefile | 4 ++--
target/imagebuilder/Makefile| 2 +-
target/linux/uml/image/Makefile | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/package/kernel/bpf-headers/Makefile
b/package/kernel/bpf-headers/Makefile
index e000a1d56c..a8a5258c64 100644
--- a/package/kernel/bpf-headers/Makefile
+++ b/package/kernel/bpf-headers/Makefile
@@ -31,8 +31,8 @@ GENERIC_FILES_DIR := $(foreach dir,$(wildcard
$(GENERIC_PLATFORM_DIR)/files $(GE
PATCH_DIR := $(CURDIR)/patches
FILES_DIR :=
-REAL_LINUX_DIR := $(LINUX_DIR)
-LINUX_DIR := $(PKG_BUILD_DIR)
+REAL_LINUX_DIR := $(LINUX_OBJ_DIR)
+LINUX_SRC_DIR := $(PKG_BUILD_DIR)
include $(INCLUDE_DIR)/bpf.mk
include $(INCLUDE_DIR)/package.mk
diff --git a/package/network/utils/iptables/Makefile
b/package/network/utils/iptables/Makefile
index f3477e8cac..0362559513 100644
--- a/package/network/utils/iptables/Makefile
+++ b/package/network/utils/iptables/Makefile
@@ -608,7 +608,7 @@ MAKE_FLAGS := \
$(TARGET_CONFIGURE_OPTS) \
COPT_FLAGS="$(TARGET_CFLAGS)" \
KERNEL_DIR="$(LINUX_OBJ_DIR)/user_headers/" PREFIX=/usr \
- KBUILD_OUTPUT="$(LINUX_DIR)" \
+ KBUILD_OUTPUT="$(LINUX_OBJ_DIR)" \
BUILTIN_MODULES="$(patsubst ip6t_%,%,$(patsubst ipt_%,%,$(patsubst
xt_%,%,$(IPT_BUILTIN) $(IPT_CONNTRACK-m) $(IPT_NAT-m"
ifneq ($(wildcard $(PKG_BUILD_DIR)/.config_*),$(subst
.configured_,.config_,$(STAMP_CONFIGURED)))
diff --git a/package/utils/spidev_test/Makefile
b/package/utils/spidev_test/Makefile
index fef5c8f646..c06c2f55a8 100644
--- a/package/utils/spidev_test/Makefile
+++ b/package/utils/spidev_test/Makefile
@@ -10,7 +10,7 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=spidev-test
PKG_RELEASE:=$(LINUX_VERSION)
-PKG_BUILD_DIR:=$(LINUX_DIR)/tools/spi-$(TARGET_DIR_NAME)
+PKG_BUILD_DIR:=$(LINUX_OBJ_DIR)/tools/spi-$(TARGET_DIR_NAME)
PKG_BUILD_PARALLEL:=1
include $(INCLUDE_DIR)/package.mk
@@ -31,7 +31,7 @@ endef
define Build/Prepare
# For SDK: Sources are copied by target/sdk/Makefile's
# USERSPACE_UTILS(_FILES)
- $(CP) $(LINUX_DIR)/tools/spi/* $(PKG_BUILD_DIR)/
+ $(CP) $(LINUX_OBJ_DIR)/tools/spi/* $(PKG_BUILD_DIR)/
endef
MAKE_FLAGS = \
diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile
index 59698d868c..c4910b6c4b 100644
--- a/target/imagebuilder/Makefile
+++ b/target/imagebuilder/Makefile
@@ -87,7 +87,7 @@ endif
$(PKG_BUILD_DIR)/target/linux/*/patches{,-*} \
$(PKG_BUILD_DIR)/target/linux/generic/{pending,backport,hack}{,-*}
-cp $(KERNEL_BUILD_DIR)/* $(IB_KDIR)/ # don't copy subdirectories here
- -cp $(LINUX_DIR)/.config $(IB_LDIR)/
+ -cp $(LINUX_OBJ_DIR)/.config $(IB_LDIR)/
rm -f $(IB_KDIR)/root.*
rm -f $(IB_KDIR)/vmlinux.debug
if [ -x $(LINUX_OBJ_DIR)/scripts/dtc/dtc ]; then \
diff --git a/target/linux/uml/image/Makefile b/target/linux/uml/image/Makefile
index 45ab0cfbcd..225e6efa85 100644
--- a/target/linux/uml/image/Makefile
+++ b/target/linux/uml/image/Makefile
@@ -6,7 +6,7 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/image.mk
define Image/Prepare
- cp $(LINUX_DIR)/linux $(KDIR)/vmlinux.elf
+ cp $(LINUX_OBJ_DIR)/linux $(KDIR)/vmlinux.elf
endef
define Image/Build/squashfs
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 16/20] [WIP] build: point kernel build tasks at $(LINUX_OBJ_DIR)
This points uses of .config, .modules, and vmlinux at the correct
place. This is one portion of the source/build split.
Signed-off-by: Elliott Mitchell
---
Note for reviewers. It is easy to miss the `mkdir` added to
Kernel/Configure/Default. That was needed since the directory might
not have been created (bugfix while testing).
---
include/kernel-build.mk | 36 -
include/kernel-defaults.mk | 101
include/kernel.mk | 8 +-
package/devel/kselftests-bpf/Makefile | 2 +-
package/kernel/linux/Makefile | 6 +-
package/network/utils/iptables/Makefile | 4 +-
6 files changed, 79 insertions(+), 78 deletions(-)
diff --git a/include/kernel-build.mk b/include/kernel-build.mk
index 19284caa94..eb770ad5f4 100644
--- a/include/kernel-build.mk
+++ b/include/kernel-build.mk
@@ -11,7 +11,7 @@ endif
KERNEL_FILE_DEPENDS=$(GENERIC_BACKPORT_DIR) $(GENERIC_PATCH_DIR)
$(GENERIC_HACK_DIR) $(PATCH_DIR) $(GENERIC_FILES_DIR) $(FILES_DIR)
STAMP_PREPARED=$(LINUX_SRC_DIR)/.prepared$(if $(QUILT)$(DUMP),,_$(shell $(call
$(if
$(CONFIG_AUTOREMOVE),find_md5_reproducible,find_md5),$(KERNEL_FILE_DEPENDS),)))
-STAMP_CONFIGURED:=$(LINUX_DIR)/.configured
+STAMP_CONFIGURED:=$(LINUX_OBJ_DIR)/.configured
include $(INCLUDE_DIR)/download.mk
include $(INCLUDE_DIR)/quilt.mk
include $(INCLUDE_DIR)/kernel-defaults.mk
@@ -61,7 +61,7 @@ ifdef CONFIG_COLLECT_KERNEL_DEBUG
define Kernel/CollectDebug
rm -rf $(KERNEL_BUILD_DIR)/debug
mkdir -p $(KERNEL_BUILD_DIR)/debug/modules
- $(CP) $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/debug/
+ $(CP) $(LINUX_OBJ_DIR)/vmlinux $(KERNEL_BUILD_DIR)/debug/
-$(CP) \
$(STAGING_DIR_ROOT)/lib/modules/$(LINUX_VERSION)/* \
$(KERNEL_BUILD_DIR)/debug/modules/
@@ -99,11 +99,11 @@ define BuildKernel
rm -f $(KERNEL_BUILD_DIR)/symtab.h
touch $(KERNEL_BUILD_DIR)/symtab.h
+$(KERNEL_MAKE) vmlinux
- find $(LINUX_DIR) $(STAGING_DIR_ROOT)/lib/modules -name \*.ko | \
+ find $(LINUX_OBJ_DIR) $(STAGING_DIR_ROOT)/lib/modules -name \*.ko | \
xargs $(TARGET_CROSS)nm | \
awk '1 == "U" { print 2 } ' | \
sort -u > $(KERNEL_BUILD_DIR)/mod_symtab.txt
- $(TARGET_CROSS)nm -n $(LINUX_DIR)/vmlinux.o | awk '/^[0-9a-f]+ [rR]
__ksymtab_/ {print substr(3,11)}' > $(KERNEL_BUILD_DIR)/kernel_symtab.txt
+ $(TARGET_CROSS)nm -n $(LINUX_OBJ_DIR)/vmlinux.o | awk '/^[0-9a-f]+ [rR]
__ksymtab_/ {print substr(3,11)}' > $(KERNEL_BUILD_DIR)/kernel_symtab.txt
grep -Ff $(KERNEL_BUILD_DIR)/mod_symtab.txt
$(KERNEL_BUILD_DIR)/kernel_symtab.txt > $(KERNEL_BUILD_DIR)/sym_include.txt
grep -Fvf $(KERNEL_BUILD_DIR)/mod_symtab.txt
$(KERNEL_BUILD_DIR)/kernel_symtab.txt > $(KERNEL_BUILD_DIR)/sym_exclude.txt
( \
@@ -129,18 +129,18 @@ define BuildKernel
$(Kernel/Configure)
touch $$@
- $(LINUX_DIR)/.modules: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
- $(LINUX_DIR)/.modules: export
PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig
- $(LINUX_DIR)/.modules: export
PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
- $(LINUX_DIR)/.modules: export FAIL_ON_UNCONFIGURED=1
- $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE
+ $(LINUX_OBJ_DIR)/.modules: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
+ $(LINUX_OBJ_DIR)/.modules: export
PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig
+ $(LINUX_OBJ_DIR)/.modules: export
PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
+ $(LINUX_OBJ_DIR)/.modules: export FAIL_ON_UNCONFIGURED=1
+ $(LINUX_OBJ_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_OBJ_DIR)/.config FORCE
$(Kernel/CompileModules)
touch $$@
- $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
- $(LINUX_DIR)/.image: export
PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig
- $(LINUX_DIR)/.image: export
PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
- $(LINUX_DIR)/.image: $(STAMP_CONFIGURED) $(if
$(CONFIG_STRIP_KERNEL_EXPORTS),$(KERNEL_BUILD_DIR)/symtab.h) FORCE
+ $(LINUX_OBJ_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
+ $(LINUX_OBJ_DIR)/.image: export
PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig
+ $(LINUX_OBJ_DIR)/.image: export
PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
+ $(LINUX_OBJ_DIR)/.image: $(STAMP_CONFIGURED) $(if
$(CONFIG_STRIP_KERNEL_EXPORTS),$(KERNEL_BUILD_DIR)/symtab.h) FORCE
$(Kernel/CompileImage)
$(Kernel/CollectDebug)
touch $$@
@@ -153,13 +153,13 @@ define BuildKernel
download: $(if $(LINUX_SITE),$(DL_DIR)/$(LINUX_SOURCE))
prepare: $(STAMP_PREPARED)
- compile: $(LINUX_DIR)/.modules
+ compile: $(LINUX_OBJ_DIR)/.modules
$(MAKE) -C image compile TARGET_BUILD=
oldconfig menuconfig nconfig xconfig: $(STAMP_PREPARED) $(STAMP_CHECKED)
FORCE
- rm -f $(LINUX_DIR
[PATCH 15/20] [WIP] package: update packages with explicit make flags
Identifying which variable to substitute in appropriate places is a bit interesting here. Since these set their own make flags, they need to reference both. Signed-off-by: Elliott Mitchell --- I'm less than certain about perf. I *hope* this matches the requirements, but I'm worried about the comment. --- package/devel/perf/Makefile | 4 ++-- package/kernel/mac80211/Makefile | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile index 31881c0136..f5290805fc 100644 --- a/package/devel/perf/Makefile +++ b/package/devel/perf/Makefile @@ -19,7 +19,7 @@ PKG_FLAGS:=nonshared # Perf's makefile and headers are not relocatable and must be built from the # Linux sources directory -PKG_BUILD_DIR:=$(LINUX_DIR)/tools/perf-$(TARGET_DIR_NAME) +PKG_BUILD_DIR:=$(LINUX_OBJ_DIR)/tools/perf-$(TARGET_DIR_NAME) include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/nls.mk @@ -70,7 +70,7 @@ MAKE_FLAGS = \ define Build/Compile +$(MAKE_FLAGS) $(MAKE) $(PKG_JOBS) \ --no-print-directory \ - -C $(LINUX_DIR)/tools/perf + -C $(LINUX_SRC_DIR)/tools/perf endef define Package/perf/install diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index d5e3171f94..e735040530 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -274,9 +274,9 @@ ifeq ($(BUILD_VARIANT),smallbuffers) endif MAKE_OPTS:= \ - $(subst -C $(LINUX_DIR),-C "$(PKG_BUILD_DIR)",$(KERNEL_MAKEOPTS)) \ + $(subst -C $(LINUX_SRC_DIR),-C "$(PKG_BUILD_DIR)",$(KERNEL_MAKEOPTS)) \ EXTRA_CFLAGS="-I$(PKG_BUILD_DIR)/include $(IREMAP_CFLAGS) $(C_DEFINES)" \ - KLIB_BUILD="$(LINUX_DIR)" \ + KLIB_BUILD="$(LINUX_OBJ_DIR)" \ MODPROBE=true \ KLIB=$(TARGET_MODULES_DIR) \ KERNEL_SUBLEVEL=$(lastword $(subst ., ,$(KERNEL_PATCHVER))) \ -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 14/20] [WIP] build: update quilt references to use $(LINUX_SRC_DIR)
Quilt is for handling patches, therefore needs to modify $(LINUX_SRC_DIR). Signed-off-by: Elliott Mitchell --- include/kernel-build.mk| 2 +- include/kernel-defaults.mk | 2 +- include/quilt.mk | 16 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index 5b332258f8..19284caa94 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -10,7 +10,7 @@ ifneq ($(DUMP),1) endif KERNEL_FILE_DEPENDS=$(GENERIC_BACKPORT_DIR) $(GENERIC_PATCH_DIR) $(GENERIC_HACK_DIR) $(PATCH_DIR) $(GENERIC_FILES_DIR) $(FILES_DIR) -STAMP_PREPARED=$(LINUX_DIR)/.prepared$(if $(QUILT)$(DUMP),,_$(shell $(call $(if $(CONFIG_AUTOREMOVE),find_md5_reproducible,find_md5),$(KERNEL_FILE_DEPENDS),))) +STAMP_PREPARED=$(LINUX_SRC_DIR)/.prepared$(if $(QUILT)$(DUMP),,_$(shell $(call $(if $(CONFIG_AUTOREMOVE),find_md5_reproducible,find_md5),$(KERNEL_FILE_DEPENDS),))) STAMP_CONFIGURED:=$(LINUX_DIR)/.configured include $(INCLUDE_DIR)/download.mk include $(INCLUDE_DIR)/quilt.mk diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 10cd83712a..b7a3f484e1 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -25,7 +25,7 @@ ifeq ($(strip $(CONFIG_EXTERNAL_KERNEL_TREE)),"") $(LINUX_CAT) $(DL_DIR)/$(LINUX_SOURCE) | $(TAR) -C $(KERNEL_BUILD_DIR) $(TAR_OPTIONS) ifeq ($(strip $(CONFIG_KERNEL_GIT_CLONE_URI)),"") $(Kernel/Patch) - $(if $(QUILT),touch $(LINUX_DIR)/.quilt_used) + $(if $(QUILT),touch $(LINUX_SRC_DIR)/.quilt_used) endif endef else diff --git a/include/quilt.mk b/include/quilt.mk index a58390f6c5..ac37672c95 100644 --- a/include/quilt.mk +++ b/include/quilt.mk @@ -3,7 +3,7 @@ # Copyright (C) 2007-2020 OpenWrt.org ifeq ($(TARGET_BUILD),1) - PKG_BUILD_DIR:=$(LINUX_DIR) + PKG_BUILD_DIR:=$(LINUX_SRC_DIR) endif ifneq ($(filter host-refresh refresh,$(MAKECMDGOALS)),) @@ -92,17 +92,17 @@ endef kernel_files=$(foreach fdir,$(GENERIC_FILES_DIR) $(FILES_DIR),$(fdir)/.) define Kernel/Patch/Default - $(if $(QUILT),rm -rf $(LINUX_DIR)/patches; mkdir -p $(LINUX_DIR)/patches) - $(if $(kernel_files),$(CP) $(kernel_files) $(LINUX_DIR)/) - find $(LINUX_DIR)/ -name \*.rej -or -name \*.orig | $(XARGS) rm -f + $(if $(QUILT),rm -rf $(LINUX_SRC_DIR)/patches; mkdir -p $(LINUX_SRC_DIR)/patches) + $(if $(kernel_files),$(CP) $(kernel_files) $(LINUX_SRC_DIR)/) + find $(LINUX_SRC_DIR)/ -name \*.rej -or -name \*.orig | $(XARGS) rm -f if [ -d $(GENERIC_PLATFORM_DIR)/patches$(if $(wildcard $(GENERIC_PLATFORM_DIR)/patches-$(KERNEL_PATCHVER)),-$(KERNEL_PATCHVER)) ]; then \ echo "generic patches directory is present. please move your patches to the pending directory" ; \ exit 1; \ fi - $(call PatchDir,$(LINUX_DIR),$(GENERIC_BACKPORT_DIR),generic-backport/) - $(call PatchDir,$(LINUX_DIR),$(GENERIC_PATCH_DIR),generic/) - $(call PatchDir,$(LINUX_DIR),$(GENERIC_HACK_DIR),generic-hack/) - $(call PatchDir,$(LINUX_DIR),$(PATCH_DIR),platform/) + $(call PatchDir,$(LINUX_SRC_DIR),$(GENERIC_BACKPORT_DIR),generic-backport/) + $(call PatchDir,$(LINUX_SRC_DIR),$(GENERIC_PATCH_DIR),generic/) + $(call PatchDir,$(LINUX_SRC_DIR),$(GENERIC_HACK_DIR),generic-hack/) + $(call PatchDir,$(LINUX_SRC_DIR),$(PATCH_DIR),platform/) endef define Quilt/RefreshDir -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 13/20] [WIP] build: point user_headers at $(LINUX_OBJ_DIR)
These may be regenerated with every build. As such they seem appropriate for the object directory, rather than source. Signed-off-by: Elliott Mitchell --- include/kernel-defaults.mk | 6 +++--- package/devel/strace/Makefile| 2 +- package/network/config/swconfig/Makefile | 2 +- package/network/utils/iptables/Makefile | 8 package/network/utils/linux-atm/Makefile | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 0b421d2cc3..10cd83712a 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -35,8 +35,8 @@ else rmdir $(LINUX_DIR); \ fi ln -s $(CONFIG_EXTERNAL_KERNEL_TREE) $(LINUX_DIR) - if [ -d $(LINUX_DIR)/user_headers ]; then \ - rm -rf $(LINUX_DIR)/user_headers; \ + if [ -d $(LINUX_OBJ_DIR)/user_headers ]; then \ + rm -rf $(LINUX_OBJ_DIR)/user_headers; \ fi endef endif @@ -111,7 +111,7 @@ define Kernel/Configure/Default cp $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config; \ cp $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.prev; \ } - $(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(KERNEL_MAKE) $(if $(findstring uml,$(BOARD)),ARCH=$(ARCH)) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install + $(_SINGLE) [ -d $(LINUX_OBJ_DIR)/user_headers ] || $(KERNEL_MAKE) $(if $(findstring uml,$(BOARD)),ARCH=$(ARCH)) INSTALL_HDR_PATH=$(LINUX_OBJ_DIR)/user_headers headers_install grep '=[ym]' $(LINUX_DIR)/.config.set | LC_ALL=C sort | $(MKHASH) md5 > $(LINUX_DIR)/.vermagic endef diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile index 3343177c3e..fa5e5c0492 100644 --- a/package/devel/strace/Makefile +++ b/package/devel/strace/Makefile @@ -31,7 +31,7 @@ PKG_CONFIG_DEPENDS := \ include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/nls.mk -HOST_CFLAGS += -I$(LINUX_DIR)/user_headers/include +HOST_CFLAGS += -I$(LINUX_OBJ_DIR)/user_headers/include CONFIGURE_VARS+= \ LDFLAGS_FOR_BUILD="$(HOST_LDFLAGS)" \ diff --git a/package/network/config/swconfig/Makefile b/package/network/config/swconfig/Makefile index 6549075e5c..69f795ce1e 100644 --- a/package/network/config/swconfig/Makefile +++ b/package/network/config/swconfig/Makefile @@ -30,7 +30,7 @@ TARGET_CPPFLAGS := \ -I$(STAGING_DIR)/usr/include/libnl-tiny \ -I$(PKG_BUILD_DIR) \ $(TARGET_CPPFLAGS) \ - -I$(LINUX_DIR)/user_headers/include + -I$(LINUX_OBJ_DIR)/user_headers/include define Build/Compile CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" \ diff --git a/package/network/utils/iptables/Makefile b/package/network/utils/iptables/Makefile index 45a2b49070..f9e8d619fa 100644 --- a/package/network/utils/iptables/Makefile +++ b/package/network/utils/iptables/Makefile @@ -586,19 +586,19 @@ endef TARGET_CPPFLAGS := \ -I$(PKG_BUILD_DIR)/include \ - -I$(LINUX_DIR)/user_headers/include \ + -I$(LINUX_OBJ_DIR)/user_headers/include \ $(TARGET_CPPFLAGS) TARGET_CFLAGS += \ -I$(PKG_BUILD_DIR)/include \ - -I$(LINUX_DIR)/user_headers/include \ + -I$(LINUX_OBJ_DIR)/user_headers/include \ -DNO_LEGACY CONFIGURE_ARGS += \ --enable-shared \ --enable-static \ --enable-devel \ - --with-kernel="$(LINUX_DIR)/user_headers" \ + --with-kernel="$(LINUX_OBJ_DIR)/user_headers" \ --with-xtlibdir=/usr/lib/iptables \ --with-xt-lock-name=/var/run/xtables.lock \ $(if $(CONFIG_IPTABLES_CONNLABEL),,--disable-connlabel) \ @@ -607,7 +607,7 @@ CONFIGURE_ARGS += \ MAKE_FLAGS := \ $(TARGET_CONFIGURE_OPTS) \ COPT_FLAGS="$(TARGET_CFLAGS)" \ - KERNEL_DIR="$(LINUX_DIR)/user_headers/" PREFIX=/usr \ + KERNEL_DIR="$(LINUX_OBJ_DIR)/user_headers/" PREFIX=/usr \ KBUILD_OUTPUT="$(LINUX_DIR)" \ BUILTIN_MODULES="$(patsubst ip6t_%,%,$(patsubst ipt_%,%,$(patsubst xt_%,%,$(IPT_BUILTIN) $(IPT_CONNTRACK-m) $(IPT_NAT-m" diff --git a/package/network/utils/linux-atm/Makefile b/package/network/utils/linux-atm/Makefile index 43f4b6556b..0bed1d6e6d 100644 --- a/package/network/utils/linux-atm/Makefile +++ b/package/network/utils/linux-atm/Makefile @@ -99,7 +99,7 @@ endef $(foreach t,$(ATM_DEBUG_TOOLS),$(eval $(call GenAtmPlugin,atm-$(t),$(t -TARGET_CFLAGS += -I$(LINUX_DIR)/user_headers/include +TARGET_CFLAGS += -I$(LINUX_OBJ_DIR)/user_headers/include define Build/Configure $(call Build/Configure/Default) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0
[PATCH 12/20] [WIP] build: adjust include paths to use LINUX_SRC_DIR/LINUX_OBJ_DIR
Most headers come out of the source. Some spots also reference the kernel build directory. Signed-off-by: Elliott Mitchell --- include/image.mk | 3 ++- include/kernel.mk| 2 +- package/devel/perf/Makefile | 2 +- package/kernel/bpf-headers/Makefile | 6 +++--- package/kernel/lantiq/ltq-adsl/Makefile | 4 ++-- package/kernel/lantiq/ltq-ifxos/Makefile | 4 ++-- package/kernel/lantiq/ltq-tapi/Makefile | 4 ++-- package/kernel/lantiq/ltq-vdsl-vr11-mei/Makefile | 4 ++-- package/kernel/lantiq/ltq-vdsl-vr11/Makefile | 4 ++-- package/kernel/lantiq/ltq-vdsl-vr9-mei/Makefile | 4 ++-- package/kernel/lantiq/ltq-vdsl-vr9/Makefile | 4 ++-- package/kernel/lantiq/ltq-vmmc/Makefile | 4 ++-- package/kernel/mac80211/Makefile | 6 +++--- package/network/config/ltq-adsl-app/Makefile | 2 +- package/network/services/ppp/Makefile| 6 +++--- package/network/utils/iproute2/Makefile | 2 +- package/network/utils/ipset/Makefile | 2 +- 17 files changed, 32 insertions(+), 31 deletions(-) diff --git a/include/image.mk b/include/image.mk index 794b32387d..a0a1d755d4 100644 --- a/include/image.mk +++ b/include/image.mk @@ -187,7 +187,8 @@ define Image/BuildDTB/sub $(DTS_CPPFLAGS) \ -I$(DTS_DIR) \ -I$(DTS_DIR)/include \ - -I$(LINUX_DIR)/include/ \ + -I$(LINUX_OBJ_DIR)/include/ \ + -I$(LINUX_SRC_DIR)/include/ \ -undef -D__DTS__ $(3) \ -o $(2).tmp $(1) $(LINUX_OBJ_DIR)/scripts/dtc/dtc -O dtb \ diff --git a/include/kernel.mk b/include/kernel.mk index ff34f74bed..8362fa768b 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -71,7 +71,7 @@ else else ifeq ($(call qstrip,$(CONFIG_EXTERNAL_KERNEL_TREE))$(call qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),) LINUX_SITE:=@KERNEL/linux/kernel/v$(word 1,$(subst ., ,$(KERNEL_BASE))).x else - LINUX_UNAME_VERSION:=$(strip $(shell cat $(LINUX_DIR)/include/config/kernel.release 2>/dev/null)) + LINUX_UNAME_VERSION:=$(strip $(shell cat $(LINUX_OBJ_DIR)/include/config/kernel.release 2>/dev/null)) endif MODULES_SUBDIR:=lib/modules/$(LINUX_UNAME_VERSION) diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile index f9573c4150..31881c0136 100644 --- a/package/devel/perf/Makefile +++ b/package/devel/perf/Makefile @@ -38,7 +38,7 @@ define Package/perf/description perf is the Linux performance monitoring tool endef -HOST_CFLAGS += -I$(LINUX_DIR)/tools/include +HOST_CFLAGS += -I$(LINUX_SRC_DIR)/tools/include TARGET_LDFLAGS += $(INTL_LDFLAGS) diff --git a/package/kernel/bpf-headers/Makefile b/package/kernel/bpf-headers/Makefile index 5efd2e1cf0..e000a1d56c 100644 --- a/package/kernel/bpf-headers/Makefile +++ b/package/kernel/bpf-headers/Makefile @@ -79,10 +79,10 @@ define Build/Configure yes '' | $(KERNEL_MAKE) oldconfig grep 'CONFIG_HZ=' $(REAL_LINUX_DIR)/.config | \ cut -d= -f2 | \ - bc -q $(LINUX_DIR)/kernel/time/timeconst.bc \ - > $(LINUX_DIR)/include/generated/timeconst.h + bc -q $(LINUX_SRC_DIR)/kernel/time/timeconst.bc \ + > $(LINUX_OBJ_DIR)/include/generated/timeconst.h $(BPF_DOC) --header \ - --file $(LINUX_DIR)/tools/include/uapi/linux/bpf.h \ + --file $(LINUX_SRC_DIR)/tools/include/uapi/linux/bpf.h \ > $(PKG_BUILD_DIR)/tools/lib/bpf/bpf_helper_defs.h endef diff --git a/package/kernel/lantiq/ltq-adsl/Makefile b/package/kernel/lantiq/ltq-adsl/Makefile index ac96674933..01cf8f8791 100644 --- a/package/kernel/lantiq/ltq-adsl/Makefile +++ b/package/kernel/lantiq/ltq-adsl/Makefile @@ -49,7 +49,7 @@ IFX_DSL_CHANNELS_PER_LINE=1 MAKE_FLAGS += \ $(KERNEL_MAKE_FLAGS) -CONFIGURE_ARGS += --enable-kernel-include="$(LINUX_DIR)/include" \ +CONFIGURE_ARGS += --enable-kernel-include="$(LINUX_SRC_DIR)/include" \ --with-max-device="$(IFX_DSL_MAX_DEVICE)" \ --with-lines-per-device="$(IFX_DSL_LINES_PER_DEVICE)" \ --with-channels-per-line="$(IFX_DSL_CHANNELS_PER_LINE)" \ @@ -68,7 +68,7 @@ CONFIGURE_ARGS += --enable-kernel-include="$(LINUX_DIR)/include" \ --enable-dsl-pm-line-thresholds \ --enable-dsl-pm-optional-parameters \ --enable-linux-26 \ - --enable-kernelbuild="$(LINUX_DIR)" \ + --enable-kernelbuild="$(LINUX_OBJ_DIR)" \ ARCH=$(LINUX_KARCH) CONFIG_TAG_danube:=DANUBE diff --git a/package/kernel/lantiq/ltq-ifxos/Makefile b/package/kernel/lantiq/ltq-ifxos/Makefile index 97f7ca78ce..f5cb1d233b 100644 --- a/package/kernel/lantiq/ltq-ifxos/Makefile +++ b/package/kernel/lantiq/ltq-ifxos/Makefile @@ -41,8 +41,8 @@ endef
[PATCH 10/20] [WIP] build: use dtc from $(LINUX_OBJ_DIR)
As an executable built from source, the Device-Tree Compiler lives in the object directory. Update references to point there. Signed-off-by: Elliott Mitchell --- include/image-commands.mk | 6 +++--- include/image.mk| 2 +- include/trusted-firmware-a.mk | 2 +- include/u-boot.mk | 2 +- package/firmware/layerscape/ls-dpl/Makefile | 2 +- target/imagebuilder/Makefile| 10 +- target/linux/bcm4908/image/Makefile | 6 +++--- target/linux/ipq40xx/image/generic.mk | 2 +- target/linux/layerscape/image/Makefile | 2 +- target/linux/mediatek/image/filogic.mk | 2 +- target/linux/ramips/image/mt7621.mk | 2 +- 11 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/image-commands.mk b/include/image-commands.mk index d07c882761..b90881d001 100644 --- a/include/image-commands.mk +++ b/include/image-commands.mk @@ -315,7 +315,7 @@ define Build/fit $(if $(DEVICE_DTS_OVERLAY),$(foreach dtso,$(DEVICE_DTS_OVERLAY), -O $(dtso):$(KERNEL_BUILD_DIR)/image-$(dtso).dtbo)) \ -c $(if $(DEVICE_DTS_CONFIG),$(DEVICE_DTS_CONFIG),"config-1") \ -A $(LINUX_KARCH) -v $(LINUX_VERSION) - PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage $(if $(findstring external,$(word 3,$(1))),\ + PATH=$(LINUX_OBJ_DIR)/scripts/dtc:$(PATH) mkimage $(if $(findstring external,$(word 3,$(1))),\ -E -B 0x1000 $(if $(findstring static,$(word 3,$(1))),-p 0x1000)) -f $@.its $@.new @mv $@.new $@ endef @@ -501,14 +501,14 @@ endef define Build/qsdk-ipq-factory-nand $(TOPDIR)/scripts/mkits-qsdk-ipq-image.sh \ $@.its ubi $@ - PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new + PATH=$(LINUX_OBJ_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new @mv $@.new $@ endef define Build/qsdk-ipq-factory-nor $(TOPDIR)/scripts/mkits-qsdk-ipq-image.sh \ $@.its hlos $(IMAGE_KERNEL) rootfs $(IMAGE_ROOTFS) - PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new + PATH=$(LINUX_OBJ_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.new @mv $@.new $@ endef diff --git a/include/image.mk b/include/image.mk index 635fad3584..794b32387d 100644 --- a/include/image.mk +++ b/include/image.mk @@ -190,7 +190,7 @@ define Image/BuildDTB/sub -I$(LINUX_DIR)/include/ \ -undef -D__DTS__ $(3) \ -o $(2).tmp $(1) - $(LINUX_DIR)/scripts/dtc/dtc -O dtb \ + $(LINUX_OBJ_DIR)/scripts/dtc/dtc -O dtb \ -i$(dir $(1)) $(4) \ $(if $(CONFIG_HAS_DT_OVERLAY_SUPPORT),-@) \ -o $(2) $(2).tmp diff --git a/include/trusted-firmware-a.mk b/include/trusted-firmware-a.mk index 0c0118e092..60acc5b255 100644 --- a/include/trusted-firmware-a.mk +++ b/include/trusted-firmware-a.mk @@ -72,7 +72,7 @@ define Build/Configure/Trusted-Firmware-A $(INSTALL_DIR) $(STAGING_DIR)/usr/include endef -DTC=$(wildcard $(LINUX_DIR)/scripts/dtc/dtc) +DTC=$(wildcard $(LINUX_OBJ_DIR)/scripts/dtc/dtc) define Build/Compile/Trusted-Firmware-A +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ diff --git a/include/u-boot.mk b/include/u-boot.mk index 2b8106410f..8269e6c0ff 100644 --- a/include/u-boot.mk +++ b/include/u-boot.mk @@ -88,7 +88,7 @@ define Build/Configure/U-Boot +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) $(UBOOT_CONFIGURE_VARS) oldconfig) endef -DTC=$(wildcard $(LINUX_DIR)/scripts/dtc/dtc) +DTC=$(wildcard $(LINUX_OBJ_DIR)/scripts/dtc/dtc) define Build/Compile/U-Boot +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ diff --git a/package/firmware/layerscape/ls-dpl/Makefile b/package/firmware/layerscape/ls-dpl/Makefile index 6c53b45417..5ef802e4f2 100644 --- a/package/firmware/layerscape/ls-dpl/Makefile +++ b/package/firmware/layerscape/ls-dpl/Makefile @@ -30,7 +30,7 @@ endef MAKE_PATH:=config MAKE_VARS+= \ - PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) + PATH=$(LINUX_OBJ_DIR)/scripts/dtc:$(PATH) define Build/InstallDev $(INSTALL_DIR) $(STAGING_DIR_IMAGE) diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile index 3bbadc7204..59698d868c 100644 --- a/target/imagebuilder/Makefile +++ b/target/imagebuilder/Makefile @@ -16,7 +16,7 @@ IB_NAME:=$(VERSION_DIST_SANITIZED)-imagebuilder-$(if $(CONFIG_VERSION_FILENAMES) PKG_BUILD_DIR:=$(BUILD_DIR)/$(IB_NAME) IB_KDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(KERNEL_BUILD_DIR)) IB_LDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_DIR)) -IB_DTSDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_DIR))/arch/$(LINUX_KARCH)/boot/dts/ +IB_DTSDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(LINUX_SRC_DIR))/arch/$(LINUX_KARCH)/boot/dts/ IB_IDIR:=$(patsubst $(TOPDIR)/%,$(PKG_BUILD_DIR)/%,$(STAGING_DIR_IMAGE)) BUNDLER_PATH := $(subst $(space),:,$(
[PATCH 09/20] [WIP] build: split $(DTB_DIR) off of $(DTS_DIR)
This has an issue similar to $(LINUX_DIR), $(DTS_DIR) was being used for both source and compiled. Create $(DTB_DIR) for the compiled binaries. Signed-off-by: Elliott Mitchell --- Issue with this commit is I'm unsure I've gotten everything and unsure I've gotten the ones I found correct. --- include/image.mk | 3 ++- target/linux/archs38/image/Makefile| 6 +++--- target/linux/bcm27xx/image/Makefile| 4 ++-- target/linux/bcm4908/image/Makefile| 2 +- target/linux/bcm53xx/image/Makefile| 6 +++--- target/linux/imx/image/common.mk | 2 +- target/linux/imx/image/cortexa9.mk | 4 ++-- target/linux/layerscape/image/Makefile | 8 target/linux/layerscape/image/armv7.mk | 4 ++-- target/linux/layerscape/image/armv8_64b.mk | 10 +- target/linux/mediatek/image/mt7622.mk | 4 ++-- target/linux/mediatek/image/mt7623.mk | 4 ++-- target/linux/mxs/image/Makefile| 2 +- target/linux/omap/image/Makefile | 2 +- target/linux/pistachio/image/Makefile | 2 +- target/linux/rockchip/image/Makefile | 2 +- target/linux/sifiveu/image/Makefile| 2 +- target/linux/sunxi/image/Makefile | 2 +- target/linux/tegra/image/Makefile | 4 ++-- target/linux/zynq/image/Makefile | 2 +- 20 files changed, 38 insertions(+), 37 deletions(-) diff --git a/include/image.mk b/include/image.mk index 4ebff2e9ae..635fad3584 100644 --- a/include/image.mk +++ b/include/image.mk @@ -31,7 +31,8 @@ mkfs_target_dir = $(if $(call param_get,pkg,$(1)),$(KDIR)/target-dir-$(call para KDIR=$(KERNEL_BUILD_DIR) KDIR_TMP=$(KDIR)/tmp -DTS_DIR:=$(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts +DTS_DIR:=$(LINUX_SRC_DIR)/arch/$(LINUX_KARCH)/boot/dts +DTB_DIR:=$(LINUX_OBJ_DIR)/arch/$(LINUX_KARCH)/boot/dts IMG_PREFIX_EXTRA:=$(if $(EXTRA_IMAGE_NAME),$(call sanitize,$(EXTRA_IMAGE_NAME))-) IMG_PREFIX_VERNUM:=$(if $(CONFIG_VERSION_FILENAMES),$(call sanitize,$(VERSION_NUMBER))-) diff --git a/target/linux/archs38/image/Makefile b/target/linux/archs38/image/Makefile index 55e16c37fc..42cff1c951 100644 --- a/target/linux/archs38/image/Makefile +++ b/target/linux/archs38/image/Makefile @@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/image.mk kernel_ep = `$(KERNEL_CROSS)readelf -h $(1) | grep "Entry point address" | grep -o 0x.*` define Build/patch-dtb - $(STAGING_DIR_HOST)/bin/patch-dtb $@ $(DTS_DIR)/$(DEVICE_DTS).dtb + $(STAGING_DIR_HOST)/bin/patch-dtb $@ $(DTB_DIR)/$(DEVICE_DTS).dtb endef ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) @@ -41,7 +41,7 @@ FAT32_BLOCKS=$(shell echo $$(($(CONFIG_AXS10X_SD_BOOT_PARTSIZE)*1024*1024/$(FAT3 define Image/Prepare # Build .dtb for all boards we may run on $(foreach dts,$(DEVICE_DTS_LIST), - $(call Image/BuildDTB,$(DTS_DIR)/$(dts).dts,$(DTS_DIR)/$(dts).dtb) + $(call Image/BuildDTB,$(DTS_DIR)/$(dts).dts,$(DTB_DIR)/$(dts).dtb) ) endef @@ -51,7 +51,7 @@ define Image/Build/SDCard mkimage -C none -A arc -T script -d uEnv.txt $(BIN_DIR)/uEnv.scr mkenvimage -s 0x4000 -o $(BIN_DIR)/uboot.env ./uboot.env.txt mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/uEnv.scr ::boot.scr - mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(DTS_DIR)/*.dtb :: + mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(DTB_DIR)/*.dtb :: mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/$(IMG_PREFIX)-uImage ::uImage mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/uboot.env ::uboot.env diff --git a/target/linux/bcm27xx/image/Makefile b/target/linux/bcm27xx/image/Makefile index ad79ac7d0c..7fcb78c8f7 100644 --- a/target/linux/bcm27xx/image/Makefile +++ b/target/linux/bcm27xx/image/Makefile @@ -23,9 +23,9 @@ define Build/boot-common mcopy -i $@.boot config.txt :: mcopy -i $@.boot distroconfig.txt :: mcopy -i $@.boot $(IMAGE_KERNEL) ::$(KERNEL_IMG) - $(foreach dts,$(shell echo $(DEVICE_DTS)),mcopy -i $@.boot $(DTS_DIR)/$(dts).dtb ::;) + $(foreach dts,$(shell echo $(DEVICE_DTS)),mcopy -i $@.boot $(DTB_DIR)/$(dts).dtb ::;) mmd -i $@.boot ::/overlays - mcopy -i $@.boot $(DTS_DIR)/overlays/*.dtbo ::/overlays/ + mcopy -i $@.boot $(DTB_DIR)/overlays/*.dtbo ::/overlays/ mcopy -i $@.boot $(DTS_DIR)/overlays/README ::/overlays/ endef diff --git a/target/linux/bcm4908/image/Makefile b/target/linux/bcm4908/image/Makefile index 658ec810d1..5d113919e8 100644 --- a/target/linux/bcm4908/image/Makefile +++ b/target/linux/bcm4908/image/Makefile @@ -32,7 +32,7 @@ define Build/bcm4908img mkdir -p $@-bootfs cp -r $(DEVICE_NAME)/* $@-bootfs/ touch $@-bootfs/1-openwrt - cp $(DTS_DIR)/$(firstword $(DEVICE_DTS)).dtb $@-bootfs/94908.dtb + cp $(DTB_DIR)/$(firstword $(DEVICE_DTS)).dtb $@-bootfs
[PATCH 08/20] build: add make variables for kernel source and object directories
Precursor to splitting the two apart. Linux kernel sources can be reused for multiple kernel builds with different configurations. The object directory cannot be reused. Signed-off-by: Elliott Mitchell --- include/kernel.mk | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index 82d87e8491..ff34f74bed 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -45,6 +45,10 @@ else endif KERNEL_BUILD_DIR ?= $(BUILD_DIR)/linux-$(BOARD)$(if $(SUBTARGET),_$(SUBTARGET)) LINUX_DIR ?= $(KERNEL_BUILD_DIR)/linux-$(LINUX_VERSION) + # Location of kernel source files + LINUX_SRC_DIR ?= $(LINUX_DIR) + # Location of kernel object files + LINUX_OBJ_DIR ?= $(LINUX_DIR) LINUX_UAPI_DIR=uapi/ LINUX_VERMAGIC:=$(strip $(shell cat $(LINUX_DIR)/.vermagic 2>/dev/null)) LINUX_VERMAGIC:=$(if $(LINUX_VERMAGIC),$(LINUX_VERMAGIC),unknown) @@ -107,6 +111,7 @@ KERNEL_MAKE_FLAGS = \ HOSTCFLAGS="$(HOST_CFLAGS) -Wall -Wmissing-prototypes -Wstrict-prototypes" \ CROSS_COMPILE="$(KERNEL_CROSS)" \ ARCH="$(LINUX_KARCH)" \ + O="$(LINUX_OBJ_DIR)" \ KBUILD_HAVE_NLS=no \ KBUILD_BUILD_USER="$(call qstrip,$(CONFIG_KERNEL_BUILD_USER))" \ KBUILD_BUILD_HOST="$(call qstrip,$(CONFIG_KERNEL_BUILD_DOMAIN))" \ @@ -136,7 +141,7 @@ ifneq ($(HOST_OS),Linux) export SKIP_STACK_VALIDATION:=1 endif -KERNEL_MAKEOPTS = -C $(LINUX_DIR) $(KERNEL_MAKE_FLAGS) +KERNEL_MAKEOPTS = -C $(LINUX_SRC_DIR) $(KERNEL_MAKE_FLAGS) ifdef CONFIG_USE_SPARSE KERNEL_MAKEOPTS += C=1 CHECK=$(STAGING_DIR_HOST)/bin/sparse -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
This removes the requirement for to create a package for all modules. Now devices can simply specify in-tree drivers/other to be built as modules and they will be present in the resultant image. Signed-off-by: Elliott Mitchell --- I'm pretty sure this is the right general approach. Why build modules and simply dump them in the garbage. I have an odd suspicion a particular sort of adjustment will be requested. Issue there is the OpenWRT use of Make is quite something, I'm unsure about which timestamp files to use. --- include/kernel-defaults.mk | 2 ++ include/kernel.mk | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 05ec9afe09..0b421d2cc3 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -151,6 +151,8 @@ define Kernel/CompileImage/Default rm -f $(TARGET_DIR)/init +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if $(KERNELNAME),$(KERNELNAME),all) $(call Kernel/CopyImage) + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) modules + find $(LINUX_DIR) -name \*.ko -a -links 1 -print0 | xargs -0 -r cp -lf -t $(TARGET_DIR)/lib/modules/$(LINUX_VERSION) endef ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) diff --git a/include/kernel.mk b/include/kernel.mk index 8236416132..82d87e8491 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -247,7 +247,7 @@ $(call KernelPackage/$(1)/config) echo "NOTICE: module 'mod' is built-in."; \ elif [ -e mod ]; then \ mkdir -p $$(1)/$(MODULES_SUBDIR) ; \ - $(CP) -L mod $$(1)/$(MODULES_SUBDIR)/ ; \ + $(CP) -L -l mod $$(1)/$(MODULES_SUBDIR)/ ; \ else \ echo "ERROR: module 'mod' is missing." >&2; \ exit 1; \ -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 06/20] kernel: remove drivers marked as modules
Previously these would get built, then simply omitted from the resultant image. This behavior is expected to change in the future, so remove these to avoid changing installed modules. Signed-off-by: Elliott Mitchell --- target/linux/armsr/armv8/config-6.1 | 2 +- target/linux/ixp4xx/config-6.1| 12 ++-- target/linux/mediatek/filogic/config-5.15 | 2 +- target/linux/mediatek/filogic/config-6.1 | 2 +- target/linux/mediatek/mt7622/config-5.15 | 2 +- target/linux/mediatek/mt7622/config-6.1 | 2 +- target/linux/ramips/rt288x/config-5.15| 14 +++--- target/linux/sifiveu/config-6.1 | 4 ++-- target/linux/uml/config-5.15 | 2 +- target/linux/uml/config-6.1 | 2 +- target/linux/x86/64/config-5.15 | 2 +- target/linux/x86/64/config-6.1| 2 +- target/linux/x86/generic/config-5.15 | 2 +- target/linux/x86/generic/config-6.1 | 2 +- 14 files changed, 26 insertions(+), 26 deletions(-) diff --git a/target/linux/armsr/armv8/config-6.1 b/target/linux/armsr/armv8/config-6.1 index a4c132df55..52f4283394 100644 --- a/target/linux/armsr/armv8/config-6.1 +++ b/target/linux/armsr/armv8/config-6.1 @@ -390,7 +390,7 @@ CONFIG_KCMP=y # CONFIG_KEYBOARD_SUN4I_LRADC is not set CONFIG_KSM=y CONFIG_KVM=y -CONFIG_LCD_CLASS_DEVICE=m +# CONFIG_LCD_CLASS_DEVICE is not set # CONFIG_LCD_PLATFORM is not set # CONFIG_MAILBOX_TEST is not set CONFIG_MARVELL_10G_PHY=y diff --git a/target/linux/ixp4xx/config-6.1 b/target/linux/ixp4xx/config-6.1 index a7b14bfb66..deef4982d9 100644 --- a/target/linux/ixp4xx/config-6.1 +++ b/target/linux/ixp4xx/config-6.1 @@ -51,15 +51,15 @@ CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_USE_DOMAINS=y CONFIG_CPU_XSCALE=y CONFIG_CRC16=y -CONFIG_CRYPTO_AUTHENC=m -CONFIG_CRYPTO_CBC=m +# CONFIG_CRYPTO_AUTHENC is not set +# CONFIG_CRYPTO_CBC is not set CONFIG_CRYPTO_CRC32C=y -CONFIG_CRYPTO_DES=m -CONFIG_CRYPTO_DEV_IXP4XX=m -CONFIG_CRYPTO_ECB=m +# CONFIG_CRYPTO_DES is not set +# CONFIG_CRYPTO_DEV_IXP4XX is not set +# CONFIG_CRYPTO_ECB is not set CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y -CONFIG_CRYPTO_LIB_DES=m +# CONFIG_CRYPTO_LIB_DES is not set CONFIG_CRYPTO_LIB_SHA1=y CONFIG_CRYPTO_LIB_UTILS=y CONFIG_CRYPTO_RNG2=y diff --git a/target/linux/mediatek/filogic/config-5.15 b/target/linux/mediatek/filogic/config-5.15 index a8f117f2c4..fe7ce6a5cb 100644 --- a/target/linux/mediatek/filogic/config-5.15 +++ b/target/linux/mediatek/filogic/config-5.15 @@ -426,7 +426,7 @@ CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y CONFIG_WATCHDOG_PRETIMEOUT_GOV=y # CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=y -CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m +# CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL is not set CONFIG_WATCHDOG_SYSFS=y CONFIG_XPS=y CONFIG_XXHASH=y diff --git a/target/linux/mediatek/filogic/config-6.1 b/target/linux/mediatek/filogic/config-6.1 index b41e87e10b..1099673929 100644 --- a/target/linux/mediatek/filogic/config-6.1 +++ b/target/linux/mediatek/filogic/config-6.1 @@ -459,7 +459,7 @@ CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y CONFIG_WATCHDOG_PRETIMEOUT_GOV=y # CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=y -CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m +# CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL is not set CONFIG_WATCHDOG_SYSFS=y CONFIG_XPS=y CONFIG_XXHASH=y diff --git a/target/linux/mediatek/mt7622/config-5.15 b/target/linux/mediatek/mt7622/config-5.15 index 99a170a2a8..eca08f1c54 100644 --- a/target/linux/mediatek/mt7622/config-5.15 +++ b/target/linux/mediatek/mt7622/config-5.15 @@ -444,7 +444,7 @@ CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y CONFIG_WATCHDOG_PRETIMEOUT_GOV=y # CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=y -CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m +# CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL is not set CONFIG_WATCHDOG_SYSFS=y CONFIG_XPS=y CONFIG_XXHASH=y diff --git a/target/linux/mediatek/mt7622/config-6.1 b/target/linux/mediatek/mt7622/config-6.1 index 26f6d8a1b1..a055617075 100644 --- a/target/linux/mediatek/mt7622/config-6.1 +++ b/target/linux/mediatek/mt7622/config-6.1 @@ -458,7 +458,7 @@ CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y CONFIG_WATCHDOG_PRETIMEOUT_GOV=y # CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=y -CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m +# CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL is not set CONFIG_WATCHDOG_SYSFS=y CONFIG_XPS=y CONFIG_XXHASH=y diff --git a/target/linux/ramips/rt288x/config-5.15 b/target/linux/ramips/rt288x/config-5.15 index 3f9014796a..af647ca129 100644 --- a/target/linux/ramips/rt288x/config-5.15 +++ b/target/linux/ramips/rt288x/config-5.15 @@ -118,7 +118,7 @@ CONFIG_NET_RALINK_RT2880=y CONFIG_NET_RALINK_SOC=y CONFIG_NET_SELFTESTS=y CONFIG_NET_VENDOR_RALINK=y -CONFIG_NLS=m +# CONFIG_NLS is not set CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y CONFIG_NVMEM=y CONFIG_OF=y @@ -177,12 +177,12
[PATCH 05/20] build: merge Kernel/Prepare steps together
Date: Mon, 30 Oct 2023 14:46:24 -0700 The two Kernel/Prepare/Default implementations had become identical. As such merge the identical sections together, and only have the extra piece be conditional. Signed-off-by: Elliott Mitchell --- include/kernel-defaults.mk | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index d9842fd82a..05ec9afe09 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -21,17 +21,13 @@ else endif ifeq ($(strip $(CONFIG_EXTERNAL_KERNEL_TREE)),"") - ifeq ($(strip $(CONFIG_KERNEL_GIT_CLONE_URI)),"") -define Kernel/Prepare/Default + define Kernel/Prepare/Default $(LINUX_CAT) $(DL_DIR)/$(LINUX_SOURCE) | $(TAR) -C $(KERNEL_BUILD_DIR) $(TAR_OPTIONS) +ifeq ($(strip $(CONFIG_KERNEL_GIT_CLONE_URI)),"") $(Kernel/Patch) $(if $(QUILT),touch $(LINUX_DIR)/.quilt_used) -endef - else -define Kernel/Prepare/Default - $(LINUX_CAT) $(DL_DIR)/$(LINUX_SOURCE) | $(TAR) -C $(KERNEL_BUILD_DIR) $(TAR_OPTIONS) -endef - endif +endif + endef else define Kernel/Prepare/Default mkdir -p $(KERNEL_BUILD_DIR) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 04/20] patch: always backup files
Date: Thu, 26 Oct 2023 18:44:33 -0700
Avoiding modification of the original files allows their reuse.
This is a first step towards being able to reuse unpacked kernel
(or other) source.
Signed-off-by: Elliott Mitchell
---
include/autotools.mk| 2 +-
scripts/patch-kernel.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/autotools.mk b/include/autotools.mk
index d0e4b3642f..53e8a0d6e6 100644
--- a/include/autotools.mk
+++ b/include/autotools.mk
@@ -61,7 +61,7 @@ define patch_libtool
lt_version="($$(STAGING_DIR_HOST)/bin/sed -ne
's,^[[:space:]]*VERSION="\?\([0-9]\.[0-9]\+\).*,\1,p' lt)"; \
case "lt_version" in \
1.5|2.2|2.4) echo "autotools.mk: Found libtool
vlt_version - applying patch to lt"; \
- (cd (dirname lt) && $$(PATCH)
-N -s -p1 < $$(TOPDIR)/tools/libtool/files/libtool-vlt_version.patch ||
true) ;; \
+ (cd (dirname lt) && $$(PATCH)
-b -N -s -p1 < $$(TOPDIR)/tools/libtool/files/libtool-vlt_version.patch ||
true) ;; \
*) echo "autotools.mk: error: Unsupported
libtool version vlt_version - cannot patch lt"; exit 1 ;; \
esac; \
done; \
diff --git a/scripts/patch-kernel.sh b/scripts/patch-kernel.sh
index c2b7e72049..d3f1042343 100755
--- a/scripts/patch-kernel.sh
+++ b/scripts/patch-kernel.sh
@@ -37,7 +37,7 @@ for i in ${patchdir}/${patchpattern} ; do
[ -d "${i}" ] && echo "Ignoring subdirectory ${i}" && continue
echo ""
echo "Applying ${i} using ${type}: "
-${uncomp} ${i} | ${PATCH:-patch} -f -p1 -d ${targetdir}
+${uncomp} ${i} | ${PATCH:-patch} -b -f -p1 -d ${targetdir}
if [ $? != 0 ] ; then
echo "Patch failed! Please fix $i!"
exit 1
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 03/20] bcm27xx: fix device-tree support patch for split source/build dirs
The kernel source directory needs to be in the include path for
compilation. This fixes separated build snd source directory
functioning.
Signed-off-by: Elliott Mitchell
---
This is really meant as a PoC fix. This works, but doesn't seem to
quite match the existing style. I'm also unsure of where in the
arguments this addition should be. Nonetheless, this is a bug.
---
.../950-0061-BCM2708-Add-core-Device-Tree-support.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/target/linux/bcm27xx/patches-6.1/950-0061-BCM2708-Add-core-Device-Tree-support.patch
b/target/linux/bcm27xx/patches-6.1/950-0061-BCM2708-Add-core-Device-Tree-support.patch
index 442abb456f..3856183a5b 100644
---
a/target/linux/bcm27xx/patches-6.1/950-0061-BCM2708-Add-core-Device-Tree-support.patch
+++
b/target/linux/bcm27xx/patches-6.1/950-0061-BCM2708-Add-core-Device-Tree-support.patch
@@ -37848,7 +37848,7 @@ index 3aa384cec76b..ed87353646bf 100644
+quiet_cmd_dtco = DTCO$@
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
-+ $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
++ $(CPP) $(dtc_cpp_flags) -I$(srctree)/include -x assembler-with-cpp -o
$(dtc-tmp) $< ; \
+ $(DTC) -@ -H epapr -O dtb -o $@ -b 0 \
+ -i $(dir $<) $(DTC_FLAGS) \
+ -Wno-interrupts_property \
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 02/20] package/lantiq: use make -C instead of `cd;`
The effect is the same, but this reduces work by the shell. This is generally preferred unless multiple commands need to be run in the target directory. Signed-off-by: Elliott Mitchell --- package/kernel/lantiq/ltq-adsl-mei/Makefile | 5 ++--- package/kernel/lantiq/ltq-atm/Makefile | 5 ++--- package/kernel/lantiq/ltq-deu/Makefile | 5 ++--- package/kernel/lantiq/ltq-ptm/Makefile | 5 ++--- 4 files changed, 8 insertions(+), 12 deletions(-) diff --git a/package/kernel/lantiq/ltq-adsl-mei/Makefile b/package/kernel/lantiq/ltq-adsl-mei/Makefile index 31e671e53f..e9db785960 100644 --- a/package/kernel/lantiq/ltq-adsl-mei/Makefile +++ b/package/kernel/lantiq/ltq-adsl-mei/Makefile @@ -34,9 +34,8 @@ define Build/Configure endef define Build/Compile - cd $(LINUX_DIR); \ - ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR)/ V=1 modules + ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ + $(MAKE) -C $(LINUX_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR)/ V=1 modules endef $(eval $(call KernelPackage,ltq-adsl-danube-mei)) diff --git a/package/kernel/lantiq/ltq-atm/Makefile b/package/kernel/lantiq/ltq-atm/Makefile index b81f3bb293..af852e9a01 100644 --- a/package/kernel/lantiq/ltq-atm/Makefile +++ b/package/kernel/lantiq/ltq-atm/Makefile @@ -39,9 +39,8 @@ define Build/Configure endef define Build/Compile - cd $(LINUX_DIR); \ - ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ + $(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-atm-danube)) diff --git a/package/kernel/lantiq/ltq-deu/Makefile b/package/kernel/lantiq/ltq-deu/Makefile index 4e8127afab..4b8fae2766 100644 --- a/package/kernel/lantiq/ltq-deu/Makefile +++ b/package/kernel/lantiq/ltq-deu/Makefile @@ -34,9 +34,8 @@ define Build/Configure endef define Build/Compile - cd $(LINUX_DIR); \ - ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ + $(MAKE) -C $(LINUX_DIR) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-deu-danube)) diff --git a/package/kernel/lantiq/ltq-ptm/Makefile b/package/kernel/lantiq/ltq-ptm/Makefile index b726cb1560..a1fb2250d2 100644 --- a/package/kernel/lantiq/ltq-ptm/Makefile +++ b/package/kernel/lantiq/ltq-ptm/Makefile @@ -43,9 +43,8 @@ define Build/Configure endef define Build/Compile - cd $(LINUX_DIR); \ - ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ - $(MAKE) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules + ARCH=mips CROSS_COMPILE="$(KERNEL_CROSS)" \ + $(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKE_FLAGS) BUILD_VARIANT=$(BUILD_VARIANT) M=$(PKG_BUILD_DIR) V=1 modules endef $(eval $(call KernelPackage,ltq-ptm-danube)) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 00/20] Kernel build fixups, split object directory off (partial WIP)
The first 3 are fixes for issues I uncovered during part of this work. Two are simple cleanup. The third is an outright bugfix, though I'm uncertain of exactly how the commit should look. The handling of kernel modules with OpenWRT means areas marked as modules get built, but then lost. In light of this, things marked as modules in kernel configuration files should be removed. Once they're removed, it then seems reasonable to start copying unrecorded lost modules to the image to make the feature useful in the future. A long tradition with kernels is keeping source separate from object and other compiled/interpretted files. This is useful for doing multiple distinct kernel builds from a single source tree. This has gained value as the size of the Linux kernel source has grown. Most of the series is attempting to head in the direction of separating these. Patch #8 is the first step towards getting this operational. Simply introduce two variables which get propogated to the kernel build. Patch #9 I found $(DTS_DIR) had a similar issue. This gets a similar solution, luckily this effects fewer spots. Alas, this too may not be fully covered. Patches 10-19 cover the instances of where $(LINUX_DIR) used to be used. The earlier ones are more likely to be right, the later ones I'm rather unsure of. These need a lot of checking. Patch #20 is simply a test case for people to check things with. Elliott Mitchell (20): ppp: make copy of compiler_types.h unconditional package/lantiq: use make -C instead of `cd;` bcm27xx: fix device-tree support patch for split source/build dirs patch: always backup files build: merge Kernel/Prepare steps together kernel: remove drivers marked as modules kernel: copy all built kernel modules to root filesystem image build: add make variables for kernel source and object directories [WIP] build: split $(DTB_DIR) off of $(DTS_DIR) [WIP] build: use dtc from $(LINUX_OBJ_DIR) [WIP] package/target: update to get modules from $(LINUX_OBJ_DIR) [WIP] build: adjust include paths to use LINUX_SRC_DIR/LINUX_OBJ_DIR [WIP] build: point user_headers at $(LINUX_OBJ_DIR) [WIP] build: update quilt references to use $(LINUX_SRC_DIR) [WIP] package: update packages with explicit make flags [WIP] build: point kernel build tasks at $(LINUX_OBJ_DIR) [WIP] build: split kernel object directory from kernel source directory [WIP] build: point remaining obvious cases at $(LINUX_SRC_DIR) [WIP] build: point remainder at $(LINUX_SRC_DIR) [TEST] TESTING: try separating build from sources include/autotools.mk | 2 +- include/image-commands.mk | 6 +- include/image.mk | 8 +- include/kernel-build.mk | 38 +-- include/kernel-defaults.mk| 127 include/kernel.mk | 20 +- include/quilt.mk | 16 +- include/trusted-firmware-a.mk | 2 +- include/u-boot.mk | 2 +- package/devel/kselftests-bpf/Makefile | 4 +- package/devel/perf/Makefile | 6 +- package/devel/strace/Makefile | 2 +- package/firmware/layerscape/ls-dpl/Makefile | 2 +- package/kernel/bpf-headers/Makefile | 10 +- package/kernel/broadcom-wl/Makefile | 2 +- package/kernel/cryptodev-linux/Makefile | 2 +- package/kernel/lantiq/ltq-adsl-mei/Makefile | 5 +- package/kernel/lantiq/ltq-adsl/Makefile | 4 +- package/kernel/lantiq/ltq-atm/Makefile| 5 +- package/kernel/lantiq/ltq-deu/Makefile| 5 +- package/kernel/lantiq/ltq-ifxos/Makefile | 4 +- package/kernel/lantiq/ltq-ptm/Makefile| 5 +- package/kernel/lantiq/ltq-tapi/Makefile | 4 +- .../kernel/lantiq/ltq-vdsl-vr11-mei/Makefile | 4 +- package/kernel/lantiq/ltq-vdsl-vr11/Makefile | 4 +- .../kernel/lantiq/ltq-vdsl-vr9-mei/Makefile | 4 +- package/kernel/lantiq/ltq-vdsl-vr9/Makefile | 4 +- package/kernel/lantiq/ltq-vmmc/Makefile | 4 +- package/kernel/linux/Makefile | 6 +- package/kernel/linux/modules/block.mk | 106 +++ package/kernel/linux/modules/can.mk | 36 +-- package/kernel/linux/modules/crypto.mk| 252 +++ package/kernel/linux/modules/firewire.mk | 8 +- package/kernel/linux/modules/fs.mk| 100 +++--- package/kernel/linux/modules/gpio-cascade.mk | 2 +- package/kernel/linux/modules/hwmon.mk | 98 +++--- package/kernel/linux/modules/i2c.mk | 2 +- package/kernel/linux/modules/iio.mk | 80 ++--- package/kernel/linux/modules/input.mk | 26 +- package/kernel/linux/modules/leds.mk | 20 +- package/kernel/linux/modules/lib.mk | 76 ++--- package/kernel/linux/modules/multiplexer.mk | 4 +- package/kernel/linux
[PATCH 01/20] ppp: make copy of compiler_types.h unconditional
04cb1e0fd2 was implemented to avoid failures with kernels before
4.14.9. At this point OpenWRT no longer supports earlier kernels,
so make the copy fail if compiler_types.h doesn't exist.
Updates: 04cb1e0fd2 ("ppp: fix build with kernel 4.14.9+")
Signed-off-by: Elliott Mitchell
---
package/network/services/ppp/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/package/network/services/ppp/Makefile
b/package/network/services/ppp/Makefile
index 40ec5c5cf1..5f4b8ac02f 100644
--- a/package/network/services/ppp/Makefile
+++ b/package/network/services/ppp/Makefile
@@ -184,13 +184,9 @@ $(call Build/Configure/Default,, \
mkdir -p $(PKG_BUILD_DIR)/pppd/plugins/pppoatm/linux
$(CP) \
$(LINUX_DIR)/include/linux/compiler.h \
+ $(LINUX_DIR)/include/linux/compiler_types.h \
$(LINUX_DIR)/include/$(LINUX_UAPI_DIR)linux/atm*.h \
$(PKG_BUILD_DIR)/pppd/plugins/pppoatm/linux/
-
- # Kernel 4.14.9+ only, ignore the exit status of cp in case the file
- # doesn't exits
- -$(CP) $(LINUX_DIR)/include/linux/compiler_types.h \
- $(PKG_BUILD_DIR)/pppd/plugins/pppoatm/linux/
endef
MAKE_FLAGS += COPTS="$(TARGET_CFLAGS)" \
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+open...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 10/11] packages/x86: detect architecture, not x86/64 target
Date: Mon, 27 Feb 2023 17:24:27 -0800 These spots should be detecting the amd64 architecture, not the specific target name. If additional amd64 targets were added, or the target was renamed, these would fail to build. Signed-off-by: Elliott Mitchell --- package/firmware/intel-microcode/Makefile | 2 +- package/kernel/linux/modules/crypto.mk| 2 +- package/kernel/linux/modules/virt.mk | 4 ++-- package/libs/wolfssl/Makefile | 2 +- target/linux/x86/modules.mk | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/package/firmware/intel-microcode/Makefile b/package/firmware/intel-microcode/Makefile index 9e87dccc12..f6e9c2def7 100644 --- a/package/firmware/intel-microcode/Makefile +++ b/package/firmware/intel-microcode/Makefile @@ -19,7 +19,7 @@ PKG_CPE_ID:=cpe:/a:intel:microcode PKG_BUILD_DEPENDS:=iucode-tool/host -ifdef CONFIG_TARGET_x86_64 +ifdef CONFIG_x86_64 MICROCODE:="intel-microcode-64" else MICROCODE:="intel-microcode" diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index dd17d868fa..5e6fed631a 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -777,7 +777,7 @@ define KernelPackage/crypto-misc $(call AddDepends/crypto) endef -ifndef CONFIG_TARGET_x86_64 +ifndef CONFIG_x86_64 define KernelPackage/crypto-misc/x86 FILES+= \ $(LINUX_DIR)/arch/x86/crypto/twofish-i586.ko \ diff --git a/package/kernel/linux/modules/virt.mk b/package/kernel/linux/modules/virt.mk index f45cb17614..82fb1af2de 100644 --- a/package/kernel/linux/modules/virt.mk +++ b/package/kernel/linux/modules/virt.mk @@ -77,7 +77,7 @@ $(eval $(call KernelPackage,kvm-amd)) define KernelPackage/vfio SUBMENU:=Virtualization TITLE:=VFIO Non-Privileged userspace driver framework - DEPENDS:=@TARGET_x86_64||TARGET_armsr_armv8 + DEPENDS:=@x86_64||TARGET_armsr_armv8 KCONFIG:= \ CONFIG_VFIO \ CONFIG_VFIO_NOIOMMU=n \ @@ -99,7 +99,7 @@ $(eval $(call KernelPackage,vfio)) define KernelPackage/vfio-pci SUBMENU:=Virtualization TITLE:=Generic VFIO support for any PCI device - DEPENDS:=@TARGET_x86_64||TARGET_armsr_armv8 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass + DEPENDS:=@x86_64||TARGET_armsr_armv8 @PCI_SUPPORT +kmod-vfio +kmod-irqbypass KCONFIG:= \ CONFIG_VFIO_PCI \ CONFIG_VFIO_PCI_IGD=n diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 6451dca68d..4326d1483e 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -185,7 +185,7 @@ else ifdef CONFIG_aarch64 CONFIGURE_ARGS += --enable-armasm TARGET_CFLAGS:=$(TARGET_CFLAGS:-mcpu%=-mcpu%+crypto) Package/libwolfsslcpu-crypto/preinst=$(Package/libwolfsslcpu-crypto/preinst-aarch64) -else ifdef CONFIG_TARGET_x86_64 +else ifdef CONFIG_x86_64 CONFIGURE_ARGS += --enable-intelasm endif diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk index 511410d614..f5f225d06f 100644 --- a/target/linux/x86/modules.mk +++ b/target/linux/x86/modules.mk @@ -5,7 +5,7 @@ define KernelPackage/amd-xgbe SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=AMD Ethernet on SoC support - DEPENDS:=@PCI_SUPPORT @TARGET_x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy +kmod-mdio-devres + DEPENDS:=@PCI_SUPPORT @x86_64 +kmod-lib-crc32c +kmod-ptp +kmod-libphy +kmod-mdio-devres KCONFIG:=CONFIG_AMD_XGBE FILES:=$(LINUX_DIR)/drivers/net/ethernet/amd/xgbe/amd-xgbe.ko AUTOLOAD:=$(call AutoLoad,35,amd-xgbe) -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 11/11] kernel/x86: enable x32 support for amd64
Date: Thu, 30 Mar 2023 16:30:49 -0700 Full amd64 support isn't really appropriate for most situations OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for these situations. As such enable x86-x32 support. CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, otherwise the kernel build breaks. Signed-off-by: Elliott Mitchell --- I suggest OpenWRT should place some effort towards x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. Only issue is it could be valuable to have at least minimal amd64 userland support alongside the x86-x32 version. Note, this simply enables kernel support. Until userspace building is added, this does almost nothing. --- target/linux/x86/64/config-5.15 | 1 - target/linux/x86/64/config-6.1 | 2 -- target/linux/x86/config-5.15| 2 ++ target/linux/x86/config-6.1 | 3 +++ 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 index 1db3180c84..ea0a51f251 100644 --- a/target/linux/x86/64/config-5.15 +++ b/target/linux/x86/64/config-5.15 @@ -502,7 +502,6 @@ CONFIG_X86_PM_TIMER=y # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_VSYSCALL_EMULATION is not set CONFIG_X86_X2APIC=y -# CONFIG_X86_X32 is not set CONFIG_XEN=y CONFIG_XENFS=y CONFIG_XEN_512GB=y diff --git a/target/linux/x86/64/config-6.1 b/target/linux/x86/64/config-6.1 index 6609f555ba..56ec0c56fd 100644 --- a/target/linux/x86/64/config-6.1 +++ b/target/linux/x86/64/config-6.1 @@ -557,8 +557,6 @@ CONFIG_X86_PM_TIMER=y # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_VSYSCALL_EMULATION is not set CONFIG_X86_X2APIC=y -# CONFIG_X86_X32 is not set -# CONFIG_X86_X32_ABI is not set CONFIG_XEN=y CONFIG_XENFS=y CONFIG_XEN_512GB=y diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index 71f06ad470..e93e46414a 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -13,6 +13,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 CONFIG_ARCH_NR_GPIO=512 CONFIG_ARCH_RANDOM=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y @@ -429,6 +430,7 @@ CONFIG_X86_UP_IOAPIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_X86_VMX_FEATURE_NAMES=y +CONFIG_X86_X32=y CONFIG_XZ_DEC_BCJ=y CONFIG_XZ_DEC_X86=y CONFIG_ZLIB_INFLATE=y diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index d6f8f6180b..a7affa9e56 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -14,6 +14,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 CONFIG_ARCH_NR_GPIO=512 CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y @@ -451,6 +452,8 @@ CONFIG_X86_UP_IOAPIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_X86_VMX_FEATURE_NAMES=y +CONFIG_X86_X32=y +CONFIG_X86_X32_ABI=y CONFIG_XZ_DEC_BCJ=y CONFIG_XZ_DEC_X86=y CONFIG_ZLIB_INFLATE=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 09/11] kernel/x86: remove CONFIG_M686 from common configuration
Date: Mon, 17 Apr 2023 08:21:26 -0700 All of the sublevels choose their own values, so there is no point in the common file having anything. This also removes a warning from the kernel build process. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/x86/config-5.15 | 2 +- target/linux/x86/config-6.1 | 2 +- target/linux/x86/generic/config-5.15 | 1 - target/linux/x86/generic/config-6.1 | 1 - target/linux/x86/geode/config-5.15 | 1 - target/linux/x86/geode/config-6.1| 1 - target/linux/x86/legacy/config-5.15 | 1 - target/linux/x86/legacy/config-6.1 | 1 - 8 files changed, 2 insertions(+), 8 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index e4ec6520e5..71f06ad470 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -204,7 +204,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_M586 is not set # CONFIG_M586MMX is not set # CONFIG_M586TSC is not set -CONFIG_M686=y +# CONFIG_M686 is not set # CONFIG_MACHZ_WDT is not set # CONFIG_MATOM is not set # CONFIG_MCORE2 is not set diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index 95e88f210b..d6f8f6180b 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -215,7 +215,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_M586 is not set # CONFIG_M586MMX is not set # CONFIG_M586TSC is not set -CONFIG_M686=y +# CONFIG_M686 is not set # CONFIG_MACHZ_WDT is not set # CONFIG_MATOM is not set # CONFIG_MCORE2 is not set diff --git a/target/linux/x86/generic/config-5.15 b/target/linux/x86/generic/config-5.15 index a06175f33a..940a0b1da6 100644 --- a/target/linux/x86/generic/config-5.15 +++ b/target/linux/x86/generic/config-5.15 @@ -240,7 +240,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y # CONFIG_LANCE is not set CONFIG_LIBNVDIMM=y CONFIG_LOCK_SPIN_ON_OWNER=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MEMORY_BALLOON=y CONFIG_MEMREGION=y diff --git a/target/linux/x86/generic/config-6.1 b/target/linux/x86/generic/config-6.1 index e62dc6575e..746ae3f47d 100644 --- a/target/linux/x86/generic/config-6.1 +++ b/target/linux/x86/generic/config-6.1 @@ -254,7 +254,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y # CONFIG_LG_LAPTOP is not set CONFIG_LIBNVDIMM=y CONFIG_LOCK_SPIN_ON_OWNER=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MEMORY_BALLOON=y CONFIG_MEMREGION=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index b5a1a641bb..977cfbd4aa 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -75,7 +75,6 @@ CONFIG_ISA_BUS_API=y # CONFIG_ISCSI_IBFT is not set # CONFIG_LANCE is not set CONFIG_LEDS_GPIO=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_CS5535=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index f459583c02..08972ed5d0 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -81,7 +81,6 @@ CONFIG_ISA_BUS_API=y # CONFIG_ISCSI_IBFT is not set # CONFIG_LANCE is not set CONFIG_LEDS_GPIO=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_CS5535=y diff --git a/target/linux/x86/legacy/config-5.15 b/target/linux/x86/legacy/config-5.15 index b6a29d57c9..64af1fbf5a 100644 --- a/target/linux/x86/legacy/config-5.15 +++ b/target/linux/x86/legacy/config-5.15 @@ -146,7 +146,6 @@ CONFIG_ISO9660_FS=y CONFIG_KCMP=y # CONFIG_LANCE is not set CONFIG_M586MMX=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_INTEL_LPSS=y diff --git a/target/linux/x86/legacy/config-6.1 b/target/linux/x86/legacy/config-6.1 index c1b132d834..fbadad9d15 100644 --- a/target/linux/x86/legacy/config-6.1 +++ b/target/linux/x86/legacy/config-6.1 @@ -156,7 +156,6 @@ CONFIG_KCMP=y # CONFIG_LANCE is not set # CONFIG_LG_LAPTOP is not set CONFIG_M586MMX=y -# CONFIG_M686 is not set # CONFIG_MDA_CONSOLE is not set CONFIG_MFD_CORE=y CONFIG_MFD_INTEL_LPSS=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 08/11] kernel/x86: move SCx200 support from generic to geode
Date: Thu, 13 Apr 2023 17:07:20 -0700 The SCx200 is part of the Geode platform. As such generic x86 doesn't need the driver, but Geode does. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/x86/config-5.15 | 5 + target/linux/x86/config-6.1| 5 + target/linux/x86/geode/config-5.15 | 3 +++ target/linux/x86/geode/config-6.1 | 3 +++ 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index e1efc44fbe..e4ec6520e5 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -309,10 +309,7 @@ CONFIG_SATA_HOST=y CONFIG_SCSI=y CONFIG_SCSI_COMMON=y CONFIG_SCSI_SPI_ATTRS=y -CONFIG_SCx200=y -CONFIG_SCx200HR_TIMER=y -# CONFIG_SCx200_GPIO is not set -# CONFIG_SCx200_WDT is not set +# CONFIG_SCx200 is not set CONFIG_SERIAL_8250_PCI=y # CONFIG_SERIAL_LANTIQ is not set CONFIG_SERIO=y diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index 17dbb5310b..95e88f210b 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -329,10 +329,7 @@ CONFIG_SATA_HOST=y CONFIG_SCSI=y CONFIG_SCSI_COMMON=y CONFIG_SCSI_SPI_ATTRS=y -CONFIG_SCx200=y -CONFIG_SCx200HR_TIMER=y -# CONFIG_SCx200_GPIO is not set -# CONFIG_SCx200_WDT is not set +# CONFIG_SCx200 is not set CONFIG_SERIAL_8250_PCI=y # CONFIG_SERIAL_LANTIQ is not set CONFIG_SERIAL_MCTRL_GPIO=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 22c9c031e8..b5a1a641bb 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -104,7 +104,10 @@ CONFIG_RTC_I2C_AND_SPI=y # CONFIG_SAMSUNG_Q10 is not set CONFIG_SC1200_WDT=y # CONFIG_SCSI_FDOMAIN_ISA is not set +CONFIG_SCx200=y +CONFIG_SCx200HR_TIMER=y CONFIG_SCx200_ACB=y +# CONFIG_SCx200_GPIO is not set CONFIG_SCx200_WDT=y CONFIG_SENSORS_LM90=y CONFIG_SERIAL_8250_PNP=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index d45a2aa170..f459583c02 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -113,7 +113,10 @@ CONFIG_RTC_I2C_AND_SPI=y # CONFIG_SAMSUNG_Q10 is not set CONFIG_SC1200_WDT=y # CONFIG_SCSI_FDOMAIN_ISA is not set +CONFIG_SCx200=y +CONFIG_SCx200HR_TIMER=y CONFIG_SCx200_ACB=y +# CONFIG_SCx200_GPIO is not set CONFIG_SCx200_WDT=y # CONFIG_SENSORS_ASUS_EC is not set # CONFIG_SENSORS_ASUS_WMI is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 07/11] kernel/x86: move Geode HW random from generic to geode
Date: Wed, 19 Apr 2023 14:07:47 -0700 Quite reasonable to have support for the Geode HW random number generator. On the Geode kernel. Signed-off-by: Elliott Mitchell --- target/linux/x86/config-5.15 | 1 - target/linux/x86/config-6.1| 1 - target/linux/x86/geode/config-5.15 | 1 + target/linux/x86/geode/config-6.1 | 1 + 4 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 index 57941a53bf..e1efc44fbe 100644 --- a/target/linux/x86/config-5.15 +++ b/target/linux/x86/config-5.15 @@ -158,7 +158,6 @@ CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET_TIMER=y # CONFIG_HP_WATCHDOG is not set CONFIG_HW_CONSOLE=y -CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y # CONFIG_HYPERVISOR_GUEST is not set CONFIG_HZ_PERIODIC=y diff --git a/target/linux/x86/config-6.1 b/target/linux/x86/config-6.1 index 979bb400c1..17dbb5310b 100644 --- a/target/linux/x86/config-6.1 +++ b/target/linux/x86/config-6.1 @@ -167,7 +167,6 @@ CONFIG_HIGHPTE=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET_TIMER=y CONFIG_HW_CONSOLE=y -CONFIG_HW_RANDOM_GEODE=y CONFIG_HW_RANDOM_VIA=y # CONFIG_HYPERVISOR_GUEST is not set CONFIG_HZ_PERIODIC=y diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 6463934b77..22c9c031e8 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -52,6 +52,7 @@ CONFIG_GPIO_CS5535=y # CONFIG_HPET is not set # CONFIG_HP_ACCEL is not set CONFIG_HWMON=y +CONFIG_HW_RANDOM_GEODE=y CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCA=y diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index e19cf7ea10..d45a2aa170 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -56,6 +56,7 @@ CONFIG_GPIO_CS5535=y # CONFIG_HPET is not set # CONFIG_HP_ACCEL is not set CONFIG_HWMON=y +CONFIG_HW_RANDOM_GEODE=y CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCA=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 06/11] Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL"
Enabling an Intel chipset feature on a platform originally made by National Semiconductor and later bought by AMD. Could we cut the Intel enthusiasm? This reverts commit 4eda2fddf2995c8ade2b1e0faddc8ce1f1e0ec5f. Signed-off-by: Elliott Mitchell --- target/linux/x86/geode/config-5.15 | 18 +- target/linux/x86/geode/config-6.1 | 20 +--- 2 files changed, 2 insertions(+), 36 deletions(-) diff --git a/target/linux/x86/geode/config-5.15 b/target/linux/x86/geode/config-5.15 index 0104b1e7b3..6463934b77 100644 --- a/target/linux/x86/geode/config-5.15 +++ b/target/linux/x86/geode/config-5.15 @@ -94,22 +94,6 @@ CONFIG_PC8736x_GPIO=y # CONFIG_PCENGINES_APU2 is not set CONFIG_PCI_MMCONFIG=y # CONFIG_PCWATCHDOG is not set -CONFIG_PINCTRL=y -# CONFIG_PINCTRL_ALDERLAKE is not set -# CONFIG_PINCTRL_BAYTRAIL is not set -# CONFIG_PINCTRL_BROXTON is not set -# CONFIG_PINCTRL_CANNONLAKE is not set -# CONFIG_PINCTRL_CHERRYVIEW is not set -# CONFIG_PINCTRL_DENVERTON is not set -# CONFIG_PINCTRL_ELKHARTLAKE is not set -# CONFIG_PINCTRL_EMMITSBURG is not set -# CONFIG_PINCTRL_GEMINILAKE is not set -# CONFIG_PINCTRL_JASPERLAKE is not set -# CONFIG_PINCTRL_LAKEFIELD is not set -# CONFIG_PINCTRL_LEWISBURG is not set -# CONFIG_PINCTRL_LYNXPOINT is not set -# CONFIG_PINCTRL_SUNRISEPOINT is not set -# CONFIG_PINCTRL_TIGERLAKE is not set # CONFIG_PMIC_OPREGION is not set CONFIG_PNP=y CONFIG_PNPACPI=y @@ -138,7 +122,7 @@ CONFIG_X86_ALIGNMENT_16=y # CONFIG_X86_AMD_PLATFORM_DEVICE is not set CONFIG_X86_CPUID=y # CONFIG_X86_E_POWERSAVER is not set -CONFIG_X86_INTEL_LPSS=y +# CONFIG_X86_INTEL_LPSS is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_MCE is not set CONFIG_X86_MINIMUM_CPU_FAMILY=5 diff --git a/target/linux/x86/geode/config-6.1 b/target/linux/x86/geode/config-6.1 index cf02d2b9b0..e19cf7ea10 100644 --- a/target/linux/x86/geode/config-6.1 +++ b/target/linux/x86/geode/config-6.1 @@ -104,24 +104,6 @@ CONFIG_PC8736x_GPIO=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCWATCHDOG is not set # CONFIG_PEAQ_WMI is not set -CONFIG_PINCTRL=y -# CONFIG_PINCTRL_ALDERLAKE is not set -# CONFIG_PINCTRL_BAYTRAIL is not set -# CONFIG_PINCTRL_BROXTON is not set -# CONFIG_PINCTRL_CANNONLAKE is not set -# CONFIG_PINCTRL_CHERRYVIEW is not set -# CONFIG_PINCTRL_DENVERTON is not set -# CONFIG_PINCTRL_ELKHARTLAKE is not set -# CONFIG_PINCTRL_EMMITSBURG is not set -# CONFIG_PINCTRL_GEMINILAKE is not set -# CONFIG_PINCTRL_JASPERLAKE is not set -# CONFIG_PINCTRL_LAKEFIELD is not set -# CONFIG_PINCTRL_LEWISBURG is not set -# CONFIG_PINCTRL_LYNXPOINT is not set -# CONFIG_PINCTRL_METEORLAKE is not set -# CONFIG_PINCTRL_SUNRISEPOINT is not set -# CONFIG_PINCTRL_TIGERLAKE is not set -# CONFIG_PMIC_OPREGION is not set CONFIG_PNP=y CONFIG_PNPACPI=y # CONFIG_PNPBIOS is not set @@ -165,7 +147,7 @@ CONFIG_X86_ALIGNMENT_16=y # CONFIG_X86_AMD_PSTATE_UT is not set CONFIG_X86_CPUID=y # CONFIG_X86_E_POWERSAVER is not set -CONFIG_X86_INTEL_LPSS=y +# CONFIG_X86_INTEL_LPSS is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_MCE is not set CONFIG_X86_MINIMUM_CPU_FAMILY=5 -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 05/11] kernel/x86: remove CONFIG_HDMI
Date: Tue, 31 Oct 2023 11:06:58 -0700 This is an internal boolean value. The value routinely gets overriden and should never be overtly set. Signed-off-by: Elliott Mitchell --- target/linux/x86/64/config-5.15 | 1 - target/linux/x86/64/config-6.1 | 1 - target/linux/x86/generic/config-5.15 | 1 - target/linux/x86/generic/config-6.1 | 1 - target/linux/x86/legacy/config-5.15 | 1 - target/linux/x86/legacy/config-6.1 | 1 - 6 files changed, 6 deletions(-) diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 index 28a4758e57..1db3180c84 100644 --- a/target/linux/x86/64/config-5.15 +++ b/target/linux/x86/64/config-5.15 @@ -207,7 +207,6 @@ CONFIG_GPIO_ICH=y CONFIG_GPIO_SCH=y CONFIG_HALTPOLL_CPUIDLE=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/64/config-6.1 b/target/linux/x86/64/config-6.1 index 66ae3e35f0..6609f555ba 100644 --- a/target/linux/x86/64/config-6.1 +++ b/target/linux/x86/64/config-6.1 @@ -227,7 +227,6 @@ CONFIG_GPIO_ICH=y CONFIG_GPIO_SCH=y CONFIG_HALTPOLL_CPUIDLE=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/generic/config-5.15 b/target/linux/x86/generic/config-5.15 index c10e1b610b..a06175f33a 100644 --- a/target/linux/x86/generic/config-5.15 +++ b/target/linux/x86/generic/config-5.15 @@ -157,7 +157,6 @@ CONFIG_GPIO_ACPI=y CONFIG_GPIO_CDEV=y CONFIG_GUP_GET_PTE_LOW_HIGH=y CONFIG_HALTPOLL_CPUIDLE=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/generic/config-6.1 b/target/linux/x86/generic/config-6.1 index b7c79de273..e62dc6575e 100644 --- a/target/linux/x86/generic/config-6.1 +++ b/target/linux/x86/generic/config-6.1 @@ -166,7 +166,6 @@ CONFIG_GPIO_ACPI=y CONFIG_GPIO_CDEV=y CONFIG_GUP_GET_PTE_LOW_HIGH=y CONFIG_HALTPOLL_CPUIDLE=y -CONFIG_HDMI=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HID_GENERIC=y diff --git a/target/linux/x86/legacy/config-5.15 b/target/linux/x86/legacy/config-5.15 index 8e17703cbc..b6a29d57c9 100644 --- a/target/linux/x86/legacy/config-5.15 +++ b/target/linux/x86/legacy/config-5.15 @@ -108,7 +108,6 @@ CONFIG_FONT_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set -CONFIG_HDMI=y CONFIG_HID_BATTERY_STRENGTH=y # CONFIG_HIGHMEM4G is not set CONFIG_HPET=y diff --git a/target/linux/x86/legacy/config-6.1 b/target/linux/x86/legacy/config-6.1 index efa1eabe82..c1b132d834 100644 --- a/target/linux/x86/legacy/config-6.1 +++ b/target/linux/x86/legacy/config-6.1 @@ -113,7 +113,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_GIGABYTE_WMI is not set -CONFIG_HDMI=y CONFIG_HID_BATTERY_STRENGTH=y # CONFIG_HIGHMEM4G is not set CONFIG_HPET=y -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 04/11] kernel: remove ext2 support from kernel
Date: Tue, 9 May 2023 13:57:31 -0700 While functional and small during its time, ext2 support should no longer be enabled by default. For most purposes aside from memory footprint, ext4 is rather superior. Time to play Taps. Signed-off-by: Elliott Mitchell --- I haven't done builds to confirm the size delta. I suspect it won't be very large. Mostly this is to finish killing off ext2 and make sure no one tries to install a new system with ext2. --- target/linux/generic/config-5.15 | 3 +-- target/linux/generic/config-6.1 | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 index 09bd33c3d6..c005d0c3f9 100644 --- a/target/linux/generic/config-5.15 +++ b/target/linux/generic/config-5.15 @@ -1891,14 +1891,13 @@ CONFIG_EXPERT=y CONFIG_EXPORTFS=y # CONFIG_EXPORTFS_BLOCK_OPS is not set # CONFIG_EXT2_FS is not set -CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT3_FS is not set # CONFIG_EXT4_DEBUG is not set # CONFIG_EXT4_ENCRYPTION is not set # CONFIG_EXT4_FS is not set # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set -CONFIG_EXT4_USE_FOR_EXT2=y +# CONFIG_EXT4_USE_FOR_EXT2 is not set # CONFIG_EXTCON is not set # CONFIG_EXTCON_ADC_JACK is not set # CONFIG_EXTCON_ARIZONA is not set diff --git a/target/linux/generic/config-6.1 b/target/linux/generic/config-6.1 index f352a869fd..eed5337d92 100644 --- a/target/linux/generic/config-6.1 +++ b/target/linux/generic/config-6.1 @@ -1977,14 +1977,13 @@ CONFIG_EXPERT=y CONFIG_EXPORTFS=y # CONFIG_EXPORTFS_BLOCK_OPS is not set # CONFIG_EXT2_FS is not set -CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT3_FS is not set # CONFIG_EXT4_DEBUG is not set # CONFIG_EXT4_ENCRYPTION is not set # CONFIG_EXT4_FS is not set # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set -CONFIG_EXT4_USE_FOR_EXT2=y +# CONFIG_EXT4_USE_FOR_EXT2 is not set # CONFIG_EXTCON is not set # CONFIG_EXTCON_ADC_JACK is not set # CONFIG_EXTCON_ARIZONA is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 03/11] kernel: purge CONFIG_FS_MBCACHE
Date: Tue, 9 May 2023 14:36:00 -0700 There is no point in attempting to set CONFIG_FS_MBCACHE. The way the Kconfig files are setup, your choice will be overridden. As such there isn't any point in documenting a default. Signed-off-by: Elliott Mitchell --- target/linux/archs38/config-5.15 | 1 - target/linux/armsr/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 1 - target/linux/at91/sama5/config-5.15 | 1 - target/linux/at91/sama7/config-5.15 | 1 - target/linux/bcm27xx/bcm2708/config-6.1 | 1 - target/linux/bcm27xx/bcm2709/config-6.1 | 1 - target/linux/bcm27xx/bcm2710/config-6.1 | 1 - target/linux/bcm27xx/bcm2711/config-6.1 | 1 - target/linux/gemini/config-6.1| 1 - target/linux/imx/config-5.15 | 1 - target/linux/ixp4xx/config-6.1| 1 - target/linux/layerscape/armv7/config-5.15 | 1 - target/linux/layerscape/armv7/config-6.1 | 1 - target/linux/layerscape/armv8_64b/config-5.15 | 1 - target/linux/layerscape/armv8_64b/config-6.1 | 1 - target/linux/malta/config-5.15| 1 - target/linux/malta/config-6.1 | 1 - target/linux/mediatek/filogic/config-5.15 | 1 - target/linux/mediatek/filogic/config-6.1 | 1 - target/linux/mediatek/mt7622/config-5.15 | 1 - target/linux/mediatek/mt7622/config-6.1 | 1 - target/linux/mediatek/mt7623/config-5.15 | 1 - target/linux/mediatek/mt7623/config-6.1 | 1 - target/linux/mvebu/config-5.15| 1 - target/linux/mvebu/config-6.1 | 1 - target/linux/mxs/config-5.15 | 1 - target/linux/mxs/config-6.1 | 1 - target/linux/octeon/config-5.15 | 1 - target/linux/omap/config-5.15 | 1 - target/linux/oxnas/ox810se/config-default | 1 - target/linux/pistachio/config-5.15| 1 - target/linux/qoriq/config-5.15| 1 - target/linux/rockchip/armv8/config-5.15 | 1 - target/linux/rockchip/armv8/config-6.1| 1 - target/linux/sifiveu/config-6.1 | 1 - target/linux/sunxi/config-5.15| 1 - target/linux/sunxi/config-6.1 | 1 - target/linux/tegra/config-5.15| 1 - target/linux/uml/config-5.15 | 1 - target/linux/uml/config-6.1 | 1 - target/linux/x86/config-5.15 | 1 - target/linux/x86/config-6.1 | 1 - target/linux/zynq/config-5.15 | 1 - 44 files changed, 44 deletions(-) diff --git a/target/linux/archs38/config-5.15 b/target/linux/archs38/config-5.15 index b526c0efe0..9e537951df 100644 --- a/target/linux/archs38/config-5.15 +++ b/target/linux/archs38/config-5.15 @@ -87,7 +87,6 @@ CONFIG_FB=y CONFIG_FB_CMDLINE=y CONFIG_FIXED_PHY=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_FWNODE_MDIO=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/armsr/config-6.1 b/target/linux/armsr/config-6.1 index d1dac69da4..745a5caf9d 100644 --- a/target/linux/armsr/config-6.1 +++ b/target/linux/armsr/config-6.1 @@ -138,7 +138,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FRAME_POINTER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ARCH_TOPOLOGY=y diff --git a/target/linux/at91/sam9x/config-5.15 b/target/linux/at91/sam9x/config-5.15 index 2c29ca2369..5a902d5cd1 100644 --- a/target/linux/at91/sam9x/config-5.15 +++ b/target/linux/at91/sam9x/config-5.15 @@ -95,7 +95,6 @@ CONFIG_FIXED_PHY=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_FREEZER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_CACHE=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/at91/sama5/config-5.15 b/target/linux/at91/sama5/config-5.15 index 6130e288dd..4cf28c5f33 100644 --- a/target/linux/at91/sama5/config-5.15 +++ b/target/linux/at91/sama5/config-5.15 @@ -163,7 +163,6 @@ CONFIG_FIX_EARLYCON_MEM=y CONFIG_FORCE_MAX_ZONEORDER=15 CONFIG_FREEZER=y CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_CACHE=y CONFIG_FW_LOADER_PAGED_BUF=y diff --git a/target/linux/at91/sama7/config-5.15 b/target/linux/at91/sama7/config-5.15 index 23b74890ea..86187089bf 100644 --- a/target/linux/at91/sama7/config-5.15 +++ b/target/linux/at91/sama7/config-5.15 @@ -150,7 +150,6 @@ CONFIG_FIXED_PHY=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_FORCE_MAX_ZONEORDER=15 CONFIG_FS_IOMAP=y -CONFIG_FS_MBCACHE=y CONFIG_FWNODE_MDIO=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ALLOCATOR=y diff --git a/target/linux/bcm27xx/bcm2708/config-6.1 b/target/linux/bcm27xx/bcm2708/config-6.1 index 244fa67656..913063ef1a 100644 --- a/target/linux/bcm27xx/bcm2708/config-6.1 +++ b/target/linux/bcm27xx/bcm2708/config-6.1 @@ -164,7 +164,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
[PATCH 01/11] kernel: change CONFIG_HW_RANDOM default to y
Date: Sat, 22 Apr 2023 10:46:30 -0700 Many devices do not have hardware random number generators. Yet more do than don't, and they are becoming more common. Signed-off-by: Elliott Mitchell --- v2: As requested, since there is a dislike of =n even though it works fine with all tools. --- target/linux/airoha/config-5.15 | 1 - target/linux/apm821xx/config-5.15 | 1 + target/linux/apm821xx/config-6.1 | 1 + target/linux/archs38/config-5.15 | 1 + target/linux/armsr/armv7/config-6.1 | 1 + target/linux/armsr/armv8/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 1 - target/linux/at91/sama5/config-5.15 | 1 - target/linux/at91/sama7/config-5.15 | 1 - target/linux/ath25/config-5.15| 1 - target/linux/ath79/config-5.15| 1 + target/linux/ath79/config-6.1 | 1 + target/linux/bcm27xx/bcm2708/config-6.1 | 1 - target/linux/bcm27xx/bcm2709/config-6.1 | 1 - target/linux/bcm27xx/bcm2710/config-6.1 | 1 - target/linux/bcm27xx/bcm2711/config-6.1 | 1 - target/linux/bcm47xx/config-5.15 | 1 - target/linux/bcm4908/config-5.15 | 1 + target/linux/bcm4908/config-6.1 | 1 + target/linux/bcm53xx/config-5.15 | 1 - target/linux/bcm53xx/config-6.1 | 1 - target/linux/bcm63xx/config-5.15 | 1 - target/linux/bmips/bcm6318/config-5.15| 1 + target/linux/bmips/bcm6318/config-6.1 | 1 + target/linux/bmips/bcm63268/config-5.15 | 1 - target/linux/bmips/bcm63268/config-6.1| 1 - target/linux/bmips/bcm6328/config-5.15| 1 + target/linux/bmips/bcm6328/config-6.1 | 1 + target/linux/bmips/bcm6358/config-5.15| 1 + target/linux/bmips/bcm6358/config-6.1 | 1 + target/linux/bmips/bcm6362/config-5.15| 1 - target/linux/bmips/bcm6362/config-6.1 | 1 - target/linux/bmips/bcm6368/config-5.15| 1 - target/linux/bmips/bcm6368/config-6.1 | 1 - target/linux/gemini/config-6.1| 1 - target/linux/generic/config-5.15 | 2 +- target/linux/generic/config-6.1 | 2 +- target/linux/imx/config-5.15 | 1 - target/linux/ipq40xx/config-6.1 | 1 - target/linux/ipq806x/config-6.1 | 1 - target/linux/ixp4xx/config-6.1| 1 - target/linux/kirkwood/config-5.15 | 1 - target/linux/lantiq/ase/config-5.15 | 1 - target/linux/lantiq/falcon/config-5.15| 1 + target/linux/lantiq/xrx200/config-5.15| 1 - target/linux/lantiq/xway/config-5.15 | 1 - target/linux/lantiq/xway_legacy/config-5.15 | 1 + target/linux/layerscape/armv7/config-5.15 | 1 - target/linux/layerscape/armv7/config-6.1 | 1 - target/linux/layerscape/armv8_64b/config-5.15 | 1 - target/linux/layerscape/armv8_64b/config-6.1 | 1 - target/linux/malta/config-5.15| 1 + target/linux/malta/config-6.1 | 1 + target/linux/mediatek/filogic/config-5.15 | 1 - target/linux/mediatek/filogic/config-6.1 | 1 - target/linux/mediatek/mt7622/config-5.15 | 1 - target/linux/mediatek/mt7622/config-6.1 | 1 - target/linux/mediatek/mt7623/config-5.15 | 1 - target/linux/mediatek/mt7623/config-6.1 | 1 - target/linux/mediatek/mt7629/config-5.15 | 1 - target/linux/mediatek/mt7629/config-6.1 | 1 - target/linux/mpc85xx/config-5.15 | 1 - target/linux/mvebu/config-5.15| 1 - target/linux/mvebu/config-6.1 | 1 - target/linux/mxs/config-5.15 | 1 + target/linux/mxs/config-6.1 | 1 + target/linux/octeon/config-5.15 | 1 - target/linux/octeontx/config-5.15 | 1 - target/linux/omap/config-5.15 | 1 - target/linux/oxnas/config-5.15| 1 + target/linux/pistachio/config-5.15| 1 + target/linux/qoriq/config-5.15| 1 - target/linux/qualcommax/config-6.1| 1 + target/linux/ramips/mt7620/config-5.15| 1 + target/linux/ramips/mt7621/config-5.15| 1 + target/linux/ramips/mt76x8/config-5.15| 1 + target/linux/ramips/rt288x/config-5.15| 1 + target/linux/ramips/rt305x/config-5.15| 1 + target/linux/ramips/rt3883/config-5.15| 1 + target/linux/realtek/rtl838x/config-5.15 | 1 + target/linux/realtek/rtl839x/config-5.15 | 1 + target/linux/realtek/rtl930x/config-5.15 | 1 + target/linux/realtek/rtl931x/config-5.15 | 1 + target/linux/rockchip/armv8/config-5.15 | 1 + target/linux/rockchip/armv8/config-6.1| 1 + target/linux/sifiveu/config-6.1 | 1 + target/linux/sunxi/config-5.15| 1 - target/linux/sunxi/config-6.1 | 1 - target/linux/tegra/config-5.15
[PATCH 02/11] kernel/generic: remove CONFIG_FB_NOTIFY
Date: Tue, 25 Apr 2023 16:23:20 -0700 This option is automatically enabled by CONFIG_FB=y. There is no reason to specifically enable it. Signed-off-by: Elliott Mitchell Reviewed-by: Philip Prindeville 04/2023 --- target/linux/generic/config-5.15 | 1 - target/linux/generic/config-6.1 | 1 - 2 files changed, 2 deletions(-) diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 index 09628ef0da..09bd33c3d6 100644 --- a/target/linux/generic/config-5.15 +++ b/target/linux/generic/config-5.15 @@ -1984,7 +1984,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set diff --git a/target/linux/generic/config-6.1 b/target/linux/generic/config-6.1 index 2073c40cc5..f352a869fd 100644 --- a/target/linux/generic/config-6.1 +++ b/target/linux/generic/config-6.1 @@ -2071,7 +2071,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+open...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 00/11] Misc kernel config cleanup and small adjustments
This isn't really a very strong theme for this batch. There is more work for x86 targets than other platforms, but some pieces effect all platforms. Some of these are pure cleanup. Kernel options which may have required being set in the past, but no longer need to be set. A few are adjusting defaults. More platforms feature HW RNGs than don't and these have been becoming more common. As such it makes more sense for CONFIG_HW_RANDOM=y in the generic configuration, then have platforms which lack override and remove the functionality. Then there is 4eda2fddf2 which is simply wrong. In exchange I found two pieces of Geode hardware whose drivers were being included in every x86 kernel. There is x32 which could have value. I would like to setup an experimental build. This may be too buggy for general consumption, but having a test build for experimentation would be good. Elliott Mitchell (11): kernel: change CONFIG_HW_RANDOM default to y kernel/generic: remove CONFIG_FB_NOTIFY kernel: purge CONFIG_FS_MBCACHE kernel: remove ext2 support from kernel kernel/x86: remove CONFIG_HDMI Revert "x86/geode: enable X86_INTEL_LPSS to select PINCTRL" kernel/x86: move Geode HW random from generic to geode kernel/x86: move SCx200 support from generic to geode kernel/x86: remove CONFIG_M686 from common configuration packages/x86: detect architecture, not x86/64 target kernel/x86: enable x32 support for amd64 package/firmware/intel-microcode/Makefile | 2 +- package/kernel/linux/modules/crypto.mk| 2 +- package/kernel/linux/modules/virt.mk | 4 +-- package/libs/wolfssl/Makefile | 2 +- target/linux/airoha/config-5.15 | 1 - target/linux/apm821xx/config-5.15 | 1 + target/linux/apm821xx/config-6.1 | 1 + target/linux/archs38/config-5.15 | 2 +- target/linux/armsr/armv7/config-6.1 | 1 + target/linux/armsr/armv8/config-6.1 | 1 - target/linux/armsr/config-6.1 | 1 - target/linux/at91/sam9x/config-5.15 | 2 -- target/linux/at91/sama5/config-5.15 | 2 -- target/linux/at91/sama7/config-5.15 | 2 -- target/linux/ath25/config-5.15| 1 - target/linux/ath79/config-5.15| 1 + target/linux/ath79/config-6.1 | 1 + target/linux/bcm27xx/bcm2708/config-6.1 | 2 -- target/linux/bcm27xx/bcm2709/config-6.1 | 2 -- target/linux/bcm27xx/bcm2710/config-6.1 | 2 -- target/linux/bcm27xx/bcm2711/config-6.1 | 2 -- target/linux/bcm47xx/config-5.15 | 1 - target/linux/bcm4908/config-5.15 | 1 + target/linux/bcm4908/config-6.1 | 1 + target/linux/bcm53xx/config-5.15 | 1 - target/linux/bcm53xx/config-6.1 | 1 - target/linux/bcm63xx/config-5.15 | 1 - target/linux/bmips/bcm6318/config-5.15| 1 + target/linux/bmips/bcm6318/config-6.1 | 1 + target/linux/bmips/bcm63268/config-5.15 | 1 - target/linux/bmips/bcm63268/config-6.1| 1 - target/linux/bmips/bcm6328/config-5.15| 1 + target/linux/bmips/bcm6328/config-6.1 | 1 + target/linux/bmips/bcm6358/config-5.15| 1 + target/linux/bmips/bcm6358/config-6.1 | 1 + target/linux/bmips/bcm6362/config-5.15| 1 - target/linux/bmips/bcm6362/config-6.1 | 1 - target/linux/bmips/bcm6368/config-5.15| 1 - target/linux/bmips/bcm6368/config-6.1 | 1 - target/linux/gemini/config-6.1| 2 -- target/linux/generic/config-5.15 | 6 ++--- target/linux/generic/config-6.1 | 6 ++--- target/linux/imx/config-5.15 | 2 -- target/linux/ipq40xx/config-6.1 | 1 - target/linux/ipq806x/config-6.1 | 1 - target/linux/ixp4xx/config-6.1| 2 -- target/linux/kirkwood/config-5.15 | 1 - target/linux/lantiq/ase/config-5.15 | 1 - target/linux/lantiq/falcon/config-5.15| 1 + target/linux/lantiq/xrx200/config-5.15| 1 - target/linux/lantiq/xway/config-5.15 | 1 - target/linux/lantiq/xway_legacy/config-5.15 | 1 + target/linux/layerscape/armv7/config-5.15 | 2 -- target/linux/layerscape/armv7/config-6.1 | 2 -- target/linux/layerscape/armv8_64b/config-5.15 | 2 -- target/linux/layerscape/armv8_64b/config-6.1 | 2 -- target/linux/malta/config-5.15| 2 +- target/linux/malta/config-6.1 | 2 +- target/linux/mediatek/filogic/config-5.15 | 2 -- target/linux/mediatek/filogic/config-6.1 | 2 -- target/linux/mediatek/mt7622/config-5.15 | 2 -- target/linux/mediatek/mt7622/config-6.1 | 2 -- target/linux/mediatek/mt7623/config-5.15 | 2 -- target/linux/mediatek/mt7623/config-6.1 | 2 -- target/linux/mediatek/mt7629/config-5.15 | 1
