IRC channel logs

<hakanrw_>but in theory it can be implemented for other ISAs through platform-specific code, right?

<AlmuHS>yes, but you have to change the sequence to startup and the assembly routine

<AlmuHS>by example, in RISC V the IPI are different

<AlmuHS> https://github.com/TianhuaTao/uCore-SMP/blob/main/os/main.c

<hakanrw_>many thanks!

<damo22>hakanrw_: i dont see why you couldnt try smp on x86_64

<damo22>i havent tested it myself yet

<hakanrw_>i was unsure if there's the low level smp implementation in x86-64 port

<damo22>should be

<damo22>if its not complete, that would be a bug

<hakanrw_>on another note - full smp boot is still not ready, right? only some hurd servers can run on child processors (at least thats what i read on the wiki)

<damo22>yeah the netdde driver does not work correctly with smp

<damo22>if you can live without networking, everything else should work

<hakanrw_>that sounds great! so people got it to boot full smp although without those troubled driver(s)?

<damo22>yes on i386 for sure

<hakanrw_>great, that means at least gnu mach's platform-agnostic parts are thread safe and ready to multiprocess, i think?

<hakanrw_>i'm seeing lock mechanisms beşng used in the code

<damo22>yeah

<hakanrw_>thanks, damo22. it's good to know

<damo22>as youpi said, hurd used to run originally with multiple processors

<youpi>no

<youpi>mach did :)

<damo22>sorry

<damo22>mach

<hakanrw_>what's going on in the aarch64 port? from what ive read they get gnu mach and some hurd stuff running on it?

<hakanrw_>is it on a different branch/repo, btw? the aarch64 folder upstream seems to lack implementations

<damo22>i havent tried it

<hakanrw_>i'll probably get in contact with them, i'm wondering how they handle DTBs

<damo22>ask Sergey

<hakanrw_>is he in irc also?

<damo22>yes, not here currently

<hakanrw_>kk

<damo22>new ports are welcome

<damo22>but the thing is going to be drivers

<hakanrw_>i'm working on a riscv64 gnu mach port for fun/learning, i got it to compile and link - although it's full of stub implementations

<hakanrw_>it doesnt do anything yet

<almuhs1>damo22: you cannot use the i386's SMP in x86_64, because the x86_64 processors has to jump to extended mode after protected mode, and change some memory configurations too. So we would need to add other assembly routines to the x86_64 architecture

<damo22>ok, perhaps you can try adding that?

<damo22>the rest should work no?

<almuhs1>the xAPIC keeps, but the percpu area must be changed, and it's necessary to create other assembly routine

<almuhs1>the x86_64 configuration is more complex and difficult to implement. I don't understand it at all

<damo22>you seem to know more about it than i do

<almuhs1>i asked to some OSDevs some months ago

<almuhs1>they explain me some things about changes in pagetables, percpu area must be implemented in a different way... added to jump to extended mode

<almuhs1> https://wiki.osdev.org/X86-64

<almuhs1> https://stackoverflow.com/questions/22962251/how-to-enter-64-bit-mode-on-a-x86-64

<damo22>why dont you give it a go?

<almuhs1>i need many more information that i have at now

<damo22>nobody is going to hand you specs that are complete, you need to try things

<almuhs1>i lost the conversation where an osdev explained me the steps

<almuhs1>i remember that the pagetable configuration, and the percpu area changes

<almuhs1>i'm searching about how to create the percpu in x86_64, but i don't find info about it

<damo22>i think the only thing that changes is the swapgs instruction swaps gs and fs

<almuhs1>btw, are you sure that the only race condition is in netdde? If netdde is the only problem, maybe we can keep netdde in the default processor_set (only cpu0) and move the rest of process to the SMP processor_set

<damo22>we did discuss that possibility, the plan was to complete rumpnet, but i got stuck

<almuhs1>i'm working as professor and making my PhD at same time. But the PhD requires some "innovation", so SMP is not enough and we are exploring about write translators in Rust

<damo22>that would be cool!

<almuhs1>it need to port some libraries, but it's cool

<damo22>i need to learn rust

<almuhs1>same XD

<almuhs1>but i have some friends who are explaining me some things about Rust, and I tested some basic program examples which compiles in rustc

<almuhs1> https://doc.rust-lang.org/stable/rust-by-example/

<damo22>be aware RustOS exists

<damo22>so you wouldnt be the first developing operating systems in rust

<damo22>redox*

<almuhs1>yes, RedoxOS

<Gooberpatrol66>almuhs1: do you have a link to that osdev thread where you asked

<almuhs1>it was in this Telegram group @osdev

<almuhs1> https://t.me/osdev

<Gooberpatrol66>ok

<Gooberpatrol66>they have a forum as well

<azert39>almuhs1: how does it work in your university? Can you fully support your PhD by teaching? Don’t you need it one or two mentors?

<azert39>Where I live I can only do a PhD by working for someone else, apparently.

<azert39>There are independent fellowships, but the level is very high and you still need to find strong support from a professor.

<AlmuHS>azert: yes, i have a teacher for my PhD

<AlmuHS>azert39

<AlmuHS>but i don't need to work in a laboratory to make my PhD

<AlmuHS>and i can agree the topic with my teacher

<hakanrw_>what is the current priority on development of GNU Mach? are there any areas that need definite work before an ambitious addition like a new driver framework for userspace device drivers can be implemented?

<AlmuHS>currently damo22 and Pellescours are trying to port rumpnet to replace netdde

<hakanrw_>does rumpnet run in kernel or userspace? is it like netbsd's rumpkernel?

<almuhs1>in userspace

<hakanrw_>i see

<hakanrw_>i should read more about the architecture of gnu mach and hurd

<almuhs1>check the wiki https://darnassus.sceen.net/~hurd-web/

<hakanrw_>thanks, i've been reading it on my free time

<youpi>hakanrw_: afawk there's all that is needed for userland drivers: physical memory allocation/access, irqs

<hakanrw_>i see

IRC channel logs

2025-04-06.log