Hello Genodians
I'm currently adding a RTC-driver (see earlier question by Stefan Thöni https://lists.genode.org/pipermail/users/2023-May/008704.html).
To achieve this I need some additional source files from the Kernel tree. This leads to some more unresolved symbols that can probably be covered by tool/dde_linux/create_dummies. To do this, I need a kernel successfully built kernel.
My question is now, how can I get the kernel configuration that was used to build the wireguard port? I will have to tweak this to also build the RTC stub for Genode.
Regards, Pirmin
Hi Pirmin,
On Mon, Jul 03, 2023 at 08:52:59AM +0200, Duss Pirmin wrote:
Hello Genodians
I'm currently adding a RTC-driver (see earlier question by Stefan Thöni https://lists.genode.org/pipermail/users/2023-May/008704.html).
To achieve this I need some additional source files from the Kernel tree. This leads to some more unresolved symbols that can probably be covered by tool/dde_linux/create_dummies. To do this, I need a kernel successfully built kernel.
My question is now, how can I get the kernel configuration that was used to build the wireguard port? I will have to tweak this to also build the RTC stub for Genode.
The kernel configuration used for the wireguard port can be found in `repos/dde_linux/src/virt_linux`. However, it is _not_ recommended to be used as base to port a device driver! In contrast to "real device drivers" the virt_linux configuration is used for protocol stacks and drivers that do not use direct I/O resources, DMA memory etc..
If you plan to enable a further driver for the x86 PC platform, I would recommend to extend and use the configuration under: `repos/pc/src/pc_linux` that is used a base for USB, framebuffer, and WiFi drivers ports for PC.
Regards Stefan
Regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Pirmin.
On Mon, Jul 03, 2023 at 08:52:59 CEST, Duss Pirmin wrote:
My question is now, how can I get the kernel configuration that was used to build the wireguard port? I will have to tweak this to also build the RTC stub for Genode.
First, I had the same impulse as Stefan and was up to warn you about the unintended mix of virt_linux and device drivers. Also, I was about to add that I'm certain porting an RTC driver with DDE Linux is not worth the hassle. RTC drivers are quite small (about 300 SLOC per device in Linux) and RTC devices come with pretty thorough documentation.
Then, I noted that you wrote "RTC stub" and realized you may refer to connecting wireguard/virt_linux to the Genode RTC service. In this case, I'd like to ask if it may be less invasive to implement the Linux API used by the wireguard code instead of enabling the RTC subsystem. This subsystem is much more complex than just mapping some function to Rtc::Session::current_time().
Regards
On Mon, Jul 03, 2023 at 11:26:47 CEST, Christian Helmuth wrote:
Then, I noted that you wrote "RTC stub" and realized you may refer to connecting wireguard/virt_linux to the Genode RTC service. In this case, I'd like to ask if it may be less invasive to implement the Linux API used by the wireguard code instead of enabling the RTC subsystem. This subsystem is much more complex than just mapping some function to Rtc::Session::current_time().
In other words, call do_settimeofday64() on wireguard startup should spare you the entire RTC subsystem as Martin already hinted in his email.
Hello Christian
On 03.07.23 12:20, Christian Helmuth wrote:
On Mon, Jul 03, 2023 at 11:26:47 CEST, Christian Helmuth wrote:
Then, I noted that you wrote "RTC stub" and realized you may refer to connecting wireguard/virt_linux to the Genode RTC service. In this case, I'd like to ask if it may be less invasive to implement the Linux API used by the wireguard code instead of enabling the RTC subsystem. This subsystem is much more complex than just mapping some function to Rtc::Session::current_time().
In other words, call do_settimeofday64() on wireguard startup should spare you the entire RTC subsystem as Martin already hinted in his email.
This is what we actually want. Martins hint about creating a pseudo RTC driver did let me run in that direction.
The new code is much less invasive. I'm currently debugging, why do_settimeofday64() accesses address 0x0. Maybe I'm calling it too early but I think, that I will figure this out.
Regards, Pirmin
Hey,
On Mon, Jul 03, 2023 at 13:50:44 CEST, Duss Pirmin wrote:
The new code is much less invasive. I'm currently debugging, why do_settimeofday64() accesses address 0x0. Maybe I'm calling it too early but I think, that I will figure this out.
Hm, that's unfortunate... Did you have a look into read_persistent_clock64() (timekeeping.c in Linux)? Maybe this is even less invasive than calling do_settimeofday64() as you may just implement the function that is defined "weak" in timekeeping.c. The related call chain is
timekeeping_init() -> read_persistent_wall_and_boot_offset() -- weak -> read_persistent_clock64 -- weak
Greets
On 03.07.23 14:55, Christian Helmuth wrote:
Hey,
On Mon, Jul 03, 2023 at 13:50:44 CEST, Duss Pirmin wrote:
The new code is much less invasive. I'm currently debugging, why do_settimeofday64() accesses address 0x0. Maybe I'm calling it too early but I think, that I will figure this out.
Hm, that's unfortunate...
I already have figured out the problem. I had the call of do_settimeofday64() in the constructor of the Main object of wireguard.
At this point the kernel isn't initialized. The Linux parts can only be started after Main is constructed successfully.
Did you have a look into read_persistent_clock64() (timekeeping.c in Linux)? Maybe this is even less invasive than calling do_settimeofday64() as you may just implement the function that is defined "weak" in timekeeping.c. The related call chain is
timekeeping_init() -> read_persistent_wall_and_boot_offset() -- weak -> read_persistent_clock64 -- weak
I like this even better. The coupling between the two "worlds" is reduced even more.
I'm currently testing and cleaning up the changes. Expect a patch incoming shortly.
Regards, Pirmin
-
Christian Helmuth -
Duss Pirmin -
Stefan Kalkowski