IRC channel logs

<almuhs>what can be the most appropiated way to store de information about the number of cpus and ioapics, and the APIC ID of each

<almuhs>??

<damo22> https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/12

<damo22>almuhs: it seems like an array could be easier than walking a list

***Server sets mode: +nt

<damo22>that would be the easiest way to store it imho

<damo22>then you can make it one global

<almuhs>damo22: excuse me, I was afk

<damo22>no need to apologise for having life outside of irc

<damo22>lol

<almuhs>I'm also thinking in reserve only the memory needed for the exact number of lapic and ioapic. Set a temporary store in a linked list and, once I know how many elements are, then reserve a dinamic array

<almuhs>as this way we can avoid to create an array of 256 elements

<damo22>if you do it that way you may as well use a struct with a pointer to an array

<almuhs>yes

<almuhs>the struct is a good idea

<almuhs>but maybe can be better to isolate the lapic info from the ioapic info, using two different structs

<almuhs>struct apic_ioapic{

<almuhs> uint16_t nioapics

<almuhs> uint16_t ioapics[MAX_IOAPICS]

<almuhs>}

<damo22>i dont think so

<damo22>its here or there

<almuhs>what?

<damo22>i dont think it matters much

<damo22>having all the smp info in one struct would work

<almuhs>yeah, but maybe can be useful to split in two structs, to be more clear

<almuhs>btw, do you know if Mach has any library to create linked list?

<damo22>struct thing {

<damo22> struct thing *next;

<damo22>}

<almuhs>yes, but If Mach has any prepared library, I avoid this manual work

<almuhs>**any prepared library for list

<almuhs>filtering with grep, the only library for linked lists is in linux glue-code

<damo22>then you have the answer

<almuhs>i'm filtering "grep -rn list("

<damo22>the point of putting it in a struct is to group it so theres less globals

<almuhs>yes, this is my idea too

<damo22>if you make 2 structs you defeat the purpose

<damo22>then you may as well use 4 globals

<damo22>i would just put it all in one struct

<almuhs>global is bad practice. Richard told me that Mach follows a OOP architecture, and I want to respect this

<damo22>yeah but we need to store the object globally

<almuhs>yes

<damo22>so just use one global struct

<almuhs>I don't understand the real Mach OOP architecture

<damo22>its cleaner

<almuhs>how it works

<damo22>OOP in C is like this:

<damo22>method_on_foo (struct foo *object, ...) {

<almuhs>I saw examples using structs to emulates classes

<almuhs>but Mach doesn't seems to emulate classed

<almuhs>*classes

<almuhs>do you understand me?

<damo22>not really

<damo22>if you have global struct, you dont need to pass a reference to the object

<damo22>because you can just use the global variable object

<damo22>so method_on_foo becomes:

<damo22>method_on_foo (...) {

<almuhs>C doesn't have classes, so is impossible to avoid all globals

<damo22>global_foo.member = 1;

<almuhs>the OOP in C simply add some structures, I think

<damo22>but that only works if you only use the global foo not any other instance of foo

<damo22>which is what we are doing

<damo22>we dont need it to generalise to other instances

<damo22>we only have one smp_info struct

<almuhs>yes

<damo22>so it doesnt really matter

<almuhs>and, where do we declare the object?

<damo22>in the C file

<almuhs>in acpi_parse_apic.c ?

<damo22>so it becomes baked into the same module where the code to handle it is

<almuhs>It makes sense

<almuhs>and where do I put the struct declaration?

<damo22>in the header file possibly

<damo22>yes

<almuhs>the problem that I see is that, in acpi_parse_apic.h there are the parser intermediary structures. I don't want to mix the temporary structured used by the parser, with the definitive structures needed for smp

<almuhs>maybe we can declare the struct in apic.h

<almuhs>apic.h stores the lapic and ioapic table

<almuhs>here: https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386/apic.h

<damo22>the parser should populate the global struct

<damo22>there is no need for intermediary structures

<almuhs>the intermediary structures are used during the ACPI tables exploration

<almuhs>a structure for RSDP, other for RSDT, other for MADT...

<almuhs>each structure has the fields of its table

<damo22>we need the MADT table exposed

<almuhs>the MADT structure is in acpi_parse_apic.h

<almuhs>struct acpi_apic

<almuhs>{

<almuhs> struct acpi_dhdr header; //Header, which stores the descriptor for RDST's Entry field

<almuhs> uint32_t lapic_addr; //Local Interrupt Controller Address

<almuhs> uint32_t flags;

<almuhs> struct acpi_apic_dhdr entry[0]; //Interrupt Controller Structure

<almuhs>} __attribute__((__packed__));

<damo22>is there one of those per lapic?

<almuhs>lapic has its own structure

<almuhs>MADT stores the APIC ID and the common address for lapic, but not lapic as self

<almuhs>the lapic table is in apic.h

<damo22>we need to know the irq overrides for ioapic

<damo22>it needs to be in a struct that we can access

<almuhs>I have a struct for MADT, other for lapic, and another for ioapic

<almuhs>the APIC structs are here: https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386/apic.h

<almuhs>ApicLocalUnit is Local APIC

<almuhs>ApicIoUnit is IOAPIC

<damo22>they are the registers

<damo22>im not talking about the registers

<almuhs>the MADT is in acpi_apic_parse.h, as I told

<damo22>part of parsing the MADT is to obtain the irq assignments

<almuhs> https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.h#L89-L95

<almuhs> https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.h#L102-L123

<almuhs>currently, I only read the Local APIC and IOAPIC's APIC ID

<almuhs>and, in IOAPIC, the address

<almuhs>addr and base

<almuhs>in Local APIC, the common address

<damo22>struct acpi_apic_dhdr entry[0]; that zero means you can extend the table right?

<damo22>with variable length entries

<almuhs>I think yes

<almuhs>where is this line?

<damo22>94

<almuhs>in the struct declaration

<almuhs>then I'm not sure if Its possible to extend

<almuhs>maybe is only sugar code

<damo22>struct foo entry[0];

<damo22>that means foo.entry is a pointer but has no memory assigned

<damo22>you need to allocate it

<almuhs>yes

<almuhs>reading the code is this

<damo22>or maybe it maps to existing entries in memory

<almuhs>this struct stores an entry in MADT table

<damo22>with unknown length

<almuhs>in MADT parser, we use this struct as pointer, to access to each field in the table

<almuhs>check apic_parse_table() in acpi_parse_apic.c

<damo22>it looks like a memory trick

<almuhs> https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L495-L550

<almuhs>yes, It is

<almuhs>/Get next APIC entry

<almuhs> apic_entry = (struct acpi_apic_dhdr*)((uint32_t) apic_entry

<almuhs> + apic_entry->length);

<almuhs>this entry can stores the information about a lapic or ioapic

<damo22> https://wiki.osdev.org/MADT

<damo22>you need to add some entry types

<almuhs>do you need type 2 entry?

<damo22>yes

<damo22>its vital

<damo22>to know which PCI interrupts map to which GSI

<almuhs>ok

<almuhs>then I'll try to add this

<almuhs>do you need type 4 too?

<damo22>maybe not now

<almuhs>ok

<damo22>we need 8 pci interrupt mappings

<damo22>PIRQ-A to PIRQ-H

<damo22>so an array of 8 would be enough

<almuhs>ok, I'll takes notes

<almuhs>struct acpi_add_intr_src

<almuhs>{

<almuhs> uint8_t bus_src;

<almuhs> uint8_t irq_src;

<almuhs> uint32_t global_sys_intr;

<almuhs> uint16_t flags;

<almuhs>};

<almuhs>#define ACPI_APIC_ENTRY_INTR_SRC 2

<damo22>use gsi not global_sys_intr

<almuhs>ok, I need the correct abbreviation for each

<damo22>bus, irq, gsi, flags

<almuhs>thanks

<almuhs>and the #define is correct?

<almuhs>the name

<damo22>struct acpi_irq_override

<almuhs>ok

<almuhs>acpi_apic, is not?

<damo22>ok

<almuhs>#define ACPI_APIC_ENTRY_IRQ_OVERRIDE 2

<damo22>not quite

<damo22>#define ACPI_APIC_IRQ_OVERRIDE_ACTIVE_LOW 2

<damo22>#define ACPI_APIC_IRQ_OVERRIDE_LEVEL_TRIGGERED 8

<almuhs>but entry 8 has the same table?

<damo22>?

<almuhs>the MADT article doesn't talk about entry 8

<damo22>these defines are for the flags

<almuhs>does this has the same table than entry 2?

<almuhs>explain me more

<damo22>(12:15:00) almuhs: uint16_t flags;

<almuhs>yes

<damo22>the defines i provided above are for that field only

<almuhs>oh, ok

<damo22>if (flags & 2) then its active low

<almuhs>then I have to create an array for ACTIVE LOW and other for LEVEL TRIGGERED?

<damo22>no

<almuhs>have I to do anything with these defines?

<almuhs>or these are only for your use?

<damo22>you need struct acpi_irq_override ioapic_irq_overrides[24];

<almuhs>ok

<damo22>one per ioapic probably

<damo22>and populate them with the overrides

<damo22>from entry2

<almuhs>ok

<damo22>or just have a way for me to read the madt and i can parse it myself

<damo22>because i need to set the irqs in ioapic setup

<damo22>if youre already parsing the madt, it makes sense to store it

<almuhs>yes

<damo22>when you see entry32

<damo22>entry2

<almuhs>It makes sense

<damo22>you can pull out the correct info

<almuhs>yes

<almuhs>at first, It's only to add a new case in the switch, and fill the array in it

<almuhs>in a preview, this seems easy

<almuhs>I go to sleep. I'll try to start with this tomorrow

<almuhs>bye

***Emulatorman___ is now known as Emulatorman

***justan0theruser is now known as justanotheruser

<Posterdati>hi

<Posterdati>is thre a debian-hurd installer?

<Posterdati>hi

<Posterdati>please help

<Posterdati>is it normally /dev/cons empty?

<youpi>Posterdati: there's an installer, see the topic of the chan

<youpi>and the faq

<youpi> /dev/cons is usually empty, yes

<youpi>it's /dev/vcs which contains some files to control the actually started console client

<damo22> https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00001.html <--- with this new release of glibc, i heard that binaries previously compiled with -ffast-math -fno-finite-math-only won't run on new systems. Why did that have to change?

<youpi>I don't know, was it really intentional? it would probably have been prominent in the NEWS section if it was

<damo22>ok i raised it on the ml

IRC channel logs

2020-05-09.log