On Sat, May 3, 2025 at 7:54 AM Kees Cook wrote:
>
> While the randstruct GCC plugin was being rebuilt if the randstruct
> seed changed, Clangs build did not notice the change. Include the hash
> header directly so that it becomes a universal build dependency and full
> rebuilds will happen if it c
On Sat, May 3, 2025 at 7:54 AM Kees Cook wrote:
>
> There was no dependency between the plugins changing and the rest of the
> kernel being built. Enforce this by including a synthetic header file
> when using plugins, that is regenerated any time the plugins are built.
>
> This cannot be included
These legacy network transports were marked as obsolete in commit
40814b98a570 ("um: Mark non-vector net transports as obsolete").
More than five years have passed since then. Remove these network
transports to reduce the maintenance burden.
Suggested-by: Anton Ivanov
Signed-off-by: Tiwei Bie
--
Tiwei Bie (3):
um: Remove obsolete legacy network transports
um: vector: Eliminate the dependency on uml_net
um: Remove legacy network transport infrastructure
.../virt/uml/user_mode_linux_howto_v2.rst | 47 +-
arch/um/configs/i386_defconfig| 7 -
arch/um/configs/x86_
The only dependency on uml_net (i.e., the legacy network transport
infrastructure) is the call to uml_net_setup_etheraddr(). Implement
it inside vector to eliminate the uml_net dependency completely. It
will allow us to remove uml_net in the next step.
Signed-off-by: Tiwei Bie
---
arch/um/driver
All legacy network transports have been removed. Vector transports
provide the same capabilities with significantly higher network
throughput. There is no reason to keep the legacy network transport
infrastructure anymore. Remove it to reduce the maintenance burden.
Signed-off-by: Tiwei Bie
---
On 2025/5/3 00:09, Johannes Berg wrote:
> On Fri, 2025-05-02 at 10:08 +0100, Anton Ivanov wrote:
>>
>> On 02/05/2025 09:35, Thomas Meyer wrote:
>>> Hi,
>>>
>>> Aren't those drivers under exactly this folder because those drivers will
>>> work only with when the host OS is Linux? I mean this is all
There was no dependency between the plugins changing and the rest of the
kernel being built. Enforce this by including a synthetic header file
when using plugins, that is regenerated any time the plugins are built.
This cannot be included via '-include ...' because Makefiles use the
"filter-out" s
While the randstruct GCC plugin was being rebuilt if the randstruct
seed changed, Clangs build did not notice the change. Include the hash
header directly so that it becomes a universal build dependency and full
rebuilds will happen if it changes.
Since we cannot use "-include ..." as the randstru
v2:
- switch from -include to -I with a -D gated include compiler-version.h
v1: https://lore.kernel.org/lkml/20250501193839.work.525-k...@kernel.org/
Hi,
This is my attempt to introduce dependencies that track the various
compiler behaviors that may globally change the build that aren't
repre
Since the integer wrapping sanitizer's behavior depends on its
associated .scl file, we must force a full rebuild if the file changes.
Universally include a synthetic header file that is rebuilt when the
.scl file changes, via compiler-version.h, since using "-include ..." is
not possible in the ca
On Fri, 2025-05-02 at 10:08 +0100, Anton Ivanov wrote:
>
> On 02/05/2025 09:35, Thomas Meyer wrote:
> > Hi,
> >
> > Aren't those drivers under exactly this folder because those drivers will
> > work only with when the host OS is Linux? I mean this is all hypothetical
> > but when somebody is go
On 02/05/2025 09:31, Tiwei Bie wrote:
Most of the drivers are stored in drivers/, with only two drivers
kept in os-Linux/drivers/. Merge os-Linux/drivers/ into drivers/
to simplify and unify the code organization.
Signed-off-by: Tiwei Bie
---
arch/um/drivers/Makefile
On 2025/5/2 16:58, Anton Ivanov wrote:
> On 02/05/2025 09:31, Tiwei Bie wrote:
>> Most of the drivers are stored in drivers/, with only two drivers
>> kept in os-Linux/drivers/. Merge os-Linux/drivers/ into drivers/
>> to simplify and unify the code organization.
>>
>> Signed-off-by: Tiwei Bie
>>
On 02/05/2025 09:35, Thomas Meyer wrote:
Hi,
Aren't those drivers under exactly this folder because those drivers will work
only with when the host OS is Linux? I mean this is all hypothetical but when
somebody is going to implement UML under Mac OS, this layout won't work
anymore, or do I
Most of the drivers are stored in drivers/, with only two drivers
kept in os-Linux/drivers/. Merge os-Linux/drivers/ into drivers/
to simplify and unify the code organization.
Signed-off-by: Tiwei Bie
---
arch/um/drivers/Makefile | 4
arch/um/{os-Linux => }/drivers/et
16 matches
Mail list logo
