Sender | Message | Time |
---|---|---|
26 Mar 2024 | ||
4lDO2 | In reply to @draft_isa:matrix.org^^ | 21:14:47 |
4lDO2 | In reply to @draft_isa:matrix.org* Relibc is considered part of the toolchain, because its headers actually are, so IMO it's pretty natural that make rebuild wouldn't automatically relink everything. However, it would be possible to store the relibc commit hash when cookbook did the last build, and at least inform the user if relibc has been updated since then, or is out of date. This feature is not implemented yet. | 21:15:05 |
Ribbon | In reply to @4ldo2:matrix.org rw_van: Can you implement this? Trigger a full recipe relinking when the relibc submodule hash changes. | 21:16:04 |
Ribbon | It's possible to only the relibc object? | 21:16:35 |
Ribbon | * It's possible to only link the relibc object? | 21:16:42 |
4lDO2 | This is easy for Rust code, but not in general for C code. We could either have cookbook re-link (fast) all Rust recipes automatically, and clean+rebuild all C recipes either automatically, interactively, or manually. | 21:19:19 |
4lDO2 | Consider opening an issue | 21:19:45 |
Ribbon | In reply to @4ldo2:matrix.orgThis one is much better, but the C/C++ detection must be accurate. | 21:22:13 |
4lDO2 | Cookbook already knows if a recipe is Cargo template (guaranteed Rust) or not. Most crates are sane enough not to try to compile their own binaries in build.rs, at least since we're cross compiling, so checking if a recipe is cargo template or custom/autoconf template, should be perfectly fine. | 21:25:07 |
4lDO2 | * Cookbook already knows if a recipe is Cargo template (guaranteed Rust) or not. Most crates are sane enough not to try to compile their own binaries in build.rs , at least since we're cross compiling, so checking if a recipe is cargo template or custom/autoconf template, should be perfectly fine. | 21:25:24 |
Ribbon | rw_van: bjorn3 https://gitlab.redox-os.org/redox-os/cookbook/-/issues/197 | 21:29:45 |
link sword set a profile picture. | 22:38:11 | |
27 Mar 2024 | ||
rw_van | nginx is a good suggestion. Also, you could start looking at PostGres. I don't think we are ready to support it, but I would like to know what is blocking it. The first cut at the recipe is in cookbook/wip/db/postgresql16 | 06:49:29 |
Ribbon changed their profile picture. | 18:37:11 | |
28 Mar 2024 | ||
rw_van | Ribbon: What's the status of RustPython? Can we run basic Python programs? Can we run anything fancy? | 10:36:01 |
Ribbon | In reply to @rw_van:matrix.org I didn't tested complex programs yet, but a Hello World. Technically, RustPython support 70% of the CPython 3.11 API. | 13:40:06 |
Ribbon | I can do this today. | 13:40:53 |
Ribbon | * I will do this today. | 13:42:08 |
Ribbon | rw_van: The Python program testing is limited because GCC and g++ frontends don't work with complex programs, some Python programs need to build some C/C++ libraries from source. | 15:31:14 |
Ribbon | * rw_van: The Python program testing is limited because gcc and g++ frontends don't work with complex programs, some Python programs need to build some C/C++ libraries from source. | 15:31:31 |
29 Mar 2024 | ||
ivan_tan | In reply to @jeremy_soller:matrix.orgDo we have general usb interfaces for all USB specifications and different host controller drivers? I'm porting a usb host controller driver(dwc2) for raspi3b but I find usbctl and usbhidd driver only support xhci. | 09:29:57 |
4lDO2 | In reply to @ivan_tan:matrix.orgAt the moment the only usb driver interface is xhcid/src/driver_interface.rs , but IIRC, it tries to abstract the USB spec, rather than the XHCI spec itself, so it should be sufficiently general. It should hopefully be possible to simply reimplement the scheme API for that host controller driver, and move out and rename the driver interface to a separate crate. | 09:51:57 |
ivan_tan | Does it rely on PCI? | 10:00:48 |
4lDO2 | No, you just need to specify the scheme name with which it can communicate with the hc driver. PCI is abstracted away, instead it provides abstract commands like "configure endpoints" (e.g. selection from available interfaces) and "device request" (such as transfer, etc., as defined in the USB spec). | 10:28:53 |
4lDO2 | * No, you just need to specify the scheme name with which it can communicate with the hc driver. PCI is abstracted away, instead it provides abstract commands like "configure endpoints" (e.g. selection from available interfaces) and "device request" (such as transfer, etc., as defined in the USB spec, e.g. section 9.x of the usb 3.2 spec). | 10:31:46 |
4lDO2 | * No, you just need to specify the scheme name with which it can communicate with the hc driver. PCI is abstracted away, instead it provides abstract commands like "configure endpoints" (e.g. selection from available interfaces) and "device request" (such as transfer, etc., as defined in the USB spec, i.e. section 9.x of the usb 3.2 spec). | 11:11:01 |
ivan_tan | Okay and how the USB system works on redox os, Is there any document for it? | 11:19:35 |
4lDO2 | Unfortunately no, you'll have to read the source code of xhcid/src/driver_interface.rs and reimplement that for the dwc2 hc driver (and ideally move the driver interface to a hc-agnostic crate, and if necessary maybe change some things to the interface. It's bincode serialized IIRC so changes are allowed as long as xhcid continues to use that crate). | 11:26:50 |
ivan_tan | okay, thanks. | 11:42:38 |
4lDO2 | * Unfortunately no, you'll have to read the source code of xhcid/src/driver_interface.rs and reimplement that for the dwc2 hc driver (and ideally move the driver interface to a hc-agnostic crate, and if necessary maybe change some things of the interface. It's bincode serialized IIRC so changes are allowed as long as xhcid continues to use that crate). | 12:13:10 |