IRC channel logs

***Server sets mode: +nt

<damo22>gnu_srs1: i think rump is independent of smp work

<damo22>but i got stuck with a few services crashing on boot otherwise everything is working

<damo22>typed: part:2 :device:/dev/wd0 on / type ext2fs (rw)

<damo22>/hurd/console crashes

<damo22>and netdde fails because the arbiter cannot run while rump is bootstrapped off custom libpciaccess

<damo22>youpi: how do we solve the problem of not being able to choose the pciaccess method at runtime?

<damo22>currently i hacked it for rump to always use x86

<youpi>IIRC we had some discussion about it already?

<youpi>an easy way would be like the pci-arbiter: make libpciaccess look at the translator name

<damo22>it currently does do that

<damo22>so i can just fake the translator name?

<youpi>you don't need to fake it

<youpi>you can just choose it and make libpciaccess recognize it

<damo22>libpciaccess already recognizes "pci-arbiter"

<damo22>so its just a matter of choosing the right name in rump thne

<damo22>it just seems like a bit of a hack

<youpi>as I mentioned in the past, ideally libpciaccess would provide a function to choose the used backend

<youpi>that's to be discussed with upstream

<damo22>eg how would it work if we wanted an arbiter as well as rumpdisk

<almuhs>ext2fs seems to be a very problematic server ;) In SMP it failed too

<damo22>almuhs: i dont think you should set NCPUS > 1 just to detect the lapics

<damo22>youre not ready to set that parameter yet

<almuhs>It's not necessary yet

<almuhs>but It's necessary to the next steps

<damo22>yeah i know, but you did

<damo22>switch it on in a later commit by itself

<almuhs>because most special case for SMP is controlled by #if NCPUS > 1 directives

<almuhs>**are controlled

<damo22>yeah but you cant commit a working tree if your smp is only half working and you switch on NCPUS

<damo22>you should test with it on

<damo22>but commit it later

<almuhs>I don't understand

<damo22>ie, if you need NCPUS > 1 just keep those changes locally

<almuhs>there are so many files

<damo22>and when youre ready to turn smp on, then you commit those changes

<almuhs>this NCPUS macro is used in hundreds of files

<damo22>for example you cant submit a patch to gnumach with NCPUS set to > 1 if the rest of the smp code does not work

<almuhs>yes, I agree

<damo22>so you commit that bit last

<almuhs>by this reason, in this patch I will keep mach_ncpus = 1

<almuhs>but, in the next steps, when we will start to enable the cpus, we need to set mach_ncpus > 1 (NCPUS > 1)

<almuhs>but yes, It's possible to set mach_ncpus = 2 only for internal test, without add It to a commit

<damo22>yes exactly

<almuhs>I continues working in improve my APIC parser

<almuhs>I need help to review the code and find possible improves. I have many questions about my code

<damo22>almuhs: the coding style in gnumach looks different to hurd

<damo22>i think it has tabs

<almuhs>gnumach follows a mixed style

<damo22>im not sure what the correct style is for gnumach

<almuhs>there are files which was original from Mach 4, and follows the old Mach 4 style

<almuhs>the new files, added in gnumach, follows GNU code style

<damo22>okay

<almuhs>youpi know more about this

<almuhs>but my question are related with code structure

<damo22>im not sure you should use imps/apic.h path

<damo22>what is imps?

<almuhs>I don't know. Is the original path of the file

<damo22>i would suggest moving it to an include path

<almuhs>this file was removed in 2007 and, in the commit which was removed, the file was in this path

<damo22>we dont create subdirectories for no purpose

<almuhs>yes, can be a good idea

<almuhs>another question is about cpu_to_lapic and ioapics array, and the variables ncpus and nioapics

<almuhs>do you prefer group this in structures?

<almuhs>*these

<almuhs>I don't know if could be better store this data in a structure, instead using globals

<damo22>well less globals is probably better

<almuhs>instead using global single arrays and variables

<damo22>you could put it all into one struct

<almuhs>and, what can be the best place to store these structs?

<damo22>there could be a global pointer to the struct and you allocate it

<damo22>im not sure

<damo22>how many cpus can there be max

<damo22>and ioapics?

<almuhs>xAPIC supports a max of 256 cpus

<almuhs>and 16 ioapics

<damo22>im not sure if we should keep an array that big in global

<damo22>probably not

<almuhs>x2APIC, in 64 bits, supports a bigger value. But at moment, we're using xAPIC

<damo22>linked list would probably make more sense

<almuhs>but a linked list can be useless for our purpuse

<almuhs>*purpose

<damo22>i agree array is easier

<almuhs>because the array is used as a dictionary to find the APIC ID from a kernel ID

<damo22>huh?

<damo22>kernel id?

<almuhs>the APIC ID is not correlative: It can takes any random value from 0-255

<damo22>what is a kernel id

<almuhs>so, the kernel, internally, assign another id to the cpu, to ease the control

<almuhs>the kernel id is the id which the kernel assigns to a cpu

<damo22>but when you send IPI you reference the apic id right?

<almuhs>yes

<damo22>so kernel does not need a mapping

<almuhs>but APIC ID is not correlative

<almuhs>so, by example, if you need to execute a loop to enable cpus, the APIC ID can be complex to do thos

<almuhs>*this

<damo22>oh i see you are numbering the lapics in sequence

<almuhs><almuhs> the APIC ID is not correlative: It can takes any random value from 0-255

<damo22>so you can easily loop over them

<almuhs>this numbering if to assign the Kernel ID

<damo22>they probably already are numbered that way, but not guaranteed

<almuhs>the cpu_to_lapic array related a kernel ID (a correlative ID) with the real APIC ID

<almuhs>exactly. Theorically, the APIC ID can be any number in the 0-255 (or more) range

<damo22>ok

<almuhs>and this do many complex the management and identify of the cpus

<damo22>im not sure what my next steps are for rump

<damo22>i know i need to clean up the argument parsing

<almuhs>It's a good practice

<almuhs>I'm moving apic.h to include/ directory. But include/ has many subdirectories. what can be the most appropiated for this?

***Server sets mode: +nt

<damo22>youpi: i refactored my libpciaccess changes and tested it, should i submit these last 4x commits upstream? http://git.zammit.org/libpciaccess.git/log/?h=rumpdisk-upstream

<almuhs>I've moved apic.h to i386/i386

<youpi>damo22: yes, sure!

<Posterdati>hi

<almuhs>hi. A question: what can be the best way to store this information? https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L36-L46

<almuhs>**which

<almuhs>the cpu_to_lapic is an array with a maximum of 255 positions. How can I to store It in a better way?

<janneke>hmm, looking at ioctl -- what could "ioctl@plt" mean

<janneke>hmm, same on linux

<almuhs>janneke: what?

<janneke>almuhs: i'm debugging an ioctl call made directly from guile, so set the loopback device

<almuhs>ok

<janneke>rpctrace shows that the second parameter, SIOCSIFADDR is off

<janneke>but i just wrote a minimal c program and it works -- exactly the same as in linux

<janneke>i was expecting to see either a syscall or a glibc call, but there's this ioctl@plt snippet/function in the .o file which looked weird

<almuhs>maybe youpi or jlledom[m] can help you

<bmelo>hi, is it possible to run netbsd on top of gnumach?

<youpi>janneke: the @plt functions are just stubs to redirect dynamic symbols

<youpi>they contains just a few instructions to fetch the proper function addresse from the PLT

<youpi>bmelo: possible, yes, implemented, no

<bmelo>what's the difference of gnumach and xnu's mach?

<youpi>various developments

<youpi>there's no simple answer to such question

<janneke>youpi: OK

<janneke>playing with pointer->procedure and dynamic-func now...

<janneke>let's see if calling printf with somwhat similar arguments yields what i want

IRC channel logs

2020-05-08.log