IRC channel logs


back to list of 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
<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>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
<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>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?
<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
<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
<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?
<almuhs>I've moved apic.h to i386/i386
<youpi>damo22: yes, sure!
<almuhs>hi. A question: what can be the best way to store this information?
<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
<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