IRC channel logs

<almuhs>(I don't remember the name exactly, but in concurrency techniques, It's possible that in some situations, all threads are block, waiting to another

<almuhs>deadlock

<terminatrix>yeah, it sounds like you have some sort of intelligent algorythm overseeing the whole sceneario

<almuhs>there are many pseudocodes to implement a software semaphore, avoiding deadlocks

<terminatrix>have to have*

<damo22>youpi: did you see my ACPICA stuff?

<almuhs>youpi possibly are sleeping now. He is french

<almuhs>and now is 2:55 AM

<damo22>oh

<almuhs>by this reason, I told you yesterday that ask your question via maillist

<damo22>yes i did send in a mail

<almuhs>then you have to wait, or reply your own mail being more explicit

<almuhs>oh, I've just saw that youpi replied you 2 hours ago

<damo22>/dev/klog

<almuhs>yes

<damo22>i solved that problem by adding infinite for loop when it fails

<damo22>so i can see errors

<damo22>i will try to allocate a simple lock

<almuhs>gnumach has Its own implementations of simple lock

<damo22>yeah but it needs to have a name

<almuhs>in sched_prim.c there are some examples, If I remembers well

<damo22>acpi_os_create_semaphore(u32 max_units, u32 initial_units, acpi_semaphore * handle)

<almuhs>what says the docs about this function?

<damo22>whats the difference between a spinlock and a semaphore

<damo22>#define acpi_spinlock simple_lock_t

<almuhs> https://stackoverflow.com/questions/195853/spinlock-versus-semaphore

<almuhs>this phrase is very descriptive: "A semaphore has a counter and will allow itself being acquired by one or several threads, depending on what value you post to it, and (in some implementations) depending on what its maximum allowable value is."

<almuhs>this is the counter in your function

<almuhs>a more practical explaination: https://unix.stackexchange.com/questions/5214/what-is-the-difference-between-spin-locks-and-semaphores

<damo22>ok a spinlock is a semaphore with max value=1

<almuhs>yes

<youpi>also, a spinlock spins

<youpi>a mutex is a semaphore with max value

<youpi>a spinlock is a mutex that spins instead of sleeping

<youpi>(when having to wait for it to be ready)

<almuhs>a spinlock is a waiting loop, is not?

<damo22>do i need to implement semaphores in gnumach?

<damo22>because simple_lock doesnt seem to be enough

<youpi>does acpi really use semaphores as semaphores, and not just as locks ?

<youpi>almuhs: it's a busy-waiting loop yes

<youpi>i.E. keep retrying, instead of going to sleep

<almuhs>the function prototype use a semaphore

<almuhs><damo22> acpi_os_create_semaphore(u32 max_units, u32 initial_units, acpi_semaphore * handle)

<youpi>yes but that doesn't mean it is actually used with max_units > 1

<almuhs>we can find the calls to this function

<damo22>status = acpi_os_create_semaphore(ACPI_NO_UNIT_LIMIT, 0,

<damo22>theres a couple of those

<almuhs>status = acpi_os_create_semaphore(1, 0, &main_thread_gate);

<almuhs>status = acpi_os_create_semaphore(1, 1, &thread_complete_gate)

<damo22>most of them are 1

<damo22>but some arent

<almuhs>or combinations with 0 and 1

<damo22>if you create a semaphore with 1, 1 doesnt that mean you can use a simple lock, and just lock it

<youpi>to get inspiration for a semaphore implementation, you can see linux/dev/kernel/sched.c 's __down and __up

<youpi>(1): not exactly indeed, but most often that's meant to be a lock, and thus simplelock is fine

<youpi>but yeah, if there are real uses of real semaphores, then see sched.c

<damo22>do we have spinlocks?

<almuhs>I have academical notes about semaphores, but I don't know if this can be useful to this purpose

<damo22>i could just do a simple lock and do a while loop?

<damo22>i'll try to hack it and assume max_units == 1

<youpi>simple_lock *is* a spinlock

<youpi>don't assume, assert

<damo22>ok

<almuhs>but if max_units == 1, then this could crash with NCPUS > 2, is not?

<youpi>max_units is completely unrelated to ncpus

<almuhs>if NCPUS > 2, and more than two tries to access to same resource, this could crash

<almuhs>is not?

<youpi>??

<youpi>simple_lock does protect against any number of accessors

<youpi>and max_unit in the semaphore definition is *not* the number of accessors

<almuhs>ok, It's true

<youpi>it's the number of tokens in the semaphore

<almuhs>the wait queue size?

<youpi>no

<damo22>linux/src/include/asm-i386/semaphore.h

<youpi>the number of tokens, really

<damo22>we have this already

<youpi>yes but that's awfully linux-glue-specific

<damo22>ok

<youpi>and what you need is not only the fast-path of the inline

<youpi>but the slow path that I mentioned above

<youpi>the __down / __up versions

<damo22>this is getting over my head

<youpi>(token = resource count)

<youpi>what? slow/fast path?

<damo22>yeah

<almuhs>oh, now I understand

<youpi>fast path is to handle the common case when it's available

<youpi>no need to wait

<youpi>just increment count

<youpi>you can do that in assembly

<youpi>but thats hairy

<youpi>and if it's actually not available, you have to go the slow path

<youpi>which actually sleeps

<damo22>ok

*youpi powerdown

<damo22>i will try to code this as a simple lock for now and assert if max_units > 1

<damo22>gnite

<almuhs>if you needs, It's not difficult to find academical notes about semaphores, mutex... etc

<almuhs>with this you can learn a theorical concept

<almuhs>this comment in wikipedia page seems important:

<almuhs>"If the implementation does not ensure atomicity of the increment, decrement and comparison operations, then there is a risk of increments or decrements being forgotten, or of the semaphore value becoming negative. Atomicity may be achieved by using a machine instruction that is able to read, modify and write the semaphore in a single operation"

<almuhs> https://en.wikipedia.org/wiki/Semaphore_(programming)#Semantics_and_implementation

<almuhs> https://see.stanford.edu/materials/icsppcs107/23-Concurrency-Examples.pdf

<damo22>i coded it as simple locks but it crashes on kmem_cache_alloc

<damo22>maybe you should go to sleep

<almuhs>yes, It's so late

<almuhs>read the docs that I sent here

<almuhs>if you can find academical notes, or books about concurrency, you can understand better these concepts

<damo22>its parsing the AML but getting stuck

<damo22>does anyone know how kalloc / kfree is supposed to work

<damo22>how are you supposed to free memory if you dont know the size

<damo22>the linux/ memory allocator stores the kmallocs in a list

<damo22>how does gnumach do it

<damo22>youpi: when i vfree an address mapped with vremap it crashes

<damo22>i have no idea how to map physical addresses to virtual addresses and then free them

<damo22> http://paste.debian.net/plain/1143067/

<damo22>this is gnumach log with verbose acpi

<damo22>looks like the size=0 of the AML i wonder if that caused it to cras

<damo22>h

<damo22>i think the DSDT on qemu is empty

<damo22>ha!

<damo22> http://paste.debian.net/plain/1143073 \o/

<damo22>youpi: braunr thinks we should not put acpica into the kernel, just put a minimal APIC table parser in there instead, but i think there is stuff in DSDT that needs to be parsed from AML and executed to complete the init of the board before the first timer interrupt

<youpi>it'd be better not to put all interpreter stuff in there yes

IRC channel logs

2020-04-26.log