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
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
Hi
On 2023-11-15, 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
Hi
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.
>
>
Hi
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
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
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 ++--
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 +-
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
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
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
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
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 +-
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
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 +-
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.
---
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
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
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 +-
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
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
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
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
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
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
---
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
---
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
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
---
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
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
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
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 -
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
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
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.
---
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 -
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
> Le 14 nov. 2023 à 18:06, Petr Štetiar a écrit :
>
> Thibaut [2023-11-14 14:25:50]:
>
>> I’m sorry, I must have missed the part where we advertised that master
>> snapshots are a maintained 'release' suitable for use in a
>> security-conscious context :)
>
> There is no difference
Thibaut [2023-11-14 14:25:50]:
> I’m sorry, I must have missed the part where we advertised that master
> snapshots are a maintained 'release' suitable for use in a
> security-conscious context :)
There is no difference actually, it applies to all branches/releases, so it
really
doesn't matter
On 11/13/23 21:49, Daniel Golle wrote:
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote:
Paul Spooren [2023-11-13 13:30:10]:
Hi,
How about we follow the approach of Alpine Linux[1] and offer a standard, an
extended and a virtual firmware for the x86/64 target?
FYI that pull
Hi,
> Le 14 nov. 2023 à 13:25, Petr Štetiar a écrit :
>
> Thibaut [2023-11-14 10:24:28]:
>
> Hi,
>
>> I don’t follow, what do security fixes have to do with snapshot builds?
>
> OpenWrt builds and deliver package fixes continuosly from the snapshot builds.
>
>> I don’t expect users (that
David Bauer [2023-11-14 10:02:36]:
Hi,
> Is there already a patch series / PR in the works?
AFAIK there is just PR #13924 attempting to workaround #13886
> Otherwise, I'd look into that.
Great, thanks!
Cheers,
Petr
___
openwrt-devel mailing list
Thibaut [2023-11-14 10:24:28]:
Hi,
> I don’t follow, what do security fixes have to do with snapshot builds?
OpenWrt builds and deliver package fixes continuosly from the snapshot builds.
> I don’t expect users (that includes myself) to keep constantly looking at
> the git history to find
> Le 14 nov. 2023 à 09:59, Petr Štetiar a écrit :
>
> Thibaut [2023-11-13 22:20:28]:
>
> Hi,
>
>> GitPoller accepts a single poll interval. What you’re suggesting would
>> require separating each branch, i.e. returning to the previous situation.
>
> IIUC then you can have multiple
Hi Daniel,
Hi Petr,
On 11/13/23 21:49, Daniel Golle wrote:
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote:
Paul Spooren [2023-11-13 13:30:10]:
Hi,
How about we follow the approach of Alpine Linux[1] and offer a standard, an
extended and a virtual firmware for the x86/64
Thibaut [2023-11-13 22:20:28]:
Hi,
> GitPoller accepts a single poll interval. What you’re suggesting would
> require separating each branch, i.e. returning to the previous situation.
IIUC then you can have multiple GitPoller instances, so wouldn't something
along this lines work?
46 matches
Mail list logo
