IRC channel logs


back to list of 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
<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
<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>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]
<damo22>i dont think so
<damo22>its here or there
<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;
<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
<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>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
<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
<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
<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> 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:
<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>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?
<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>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>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>you need to add some entry types
<almuhs>do you need type 2 entry?
<damo22>its vital
<damo22>to know which PCI interrupts map to which GSI
<almuhs>then I'll try to add this
<almuhs>do you need type 4 too?
<damo22>maybe not now
<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> uint8_t bus_src;
<almuhs> uint8_t irq_src;
<almuhs> uint32_t global_sys_intr;
<almuhs> uint16_t flags;
<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>and the #define is correct?
<almuhs>the name
<damo22>struct acpi_irq_override
<almuhs>acpi_apic, is not?
<damo22>not quite
<almuhs>but entry 8 has the same table?
<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;
<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?
<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];
<damo22>one per ioapic probably
<damo22>and populate them with the overrides
<damo22>from entry2
<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
<damo22>when you see entry32
<almuhs>It makes sense
<damo22>you can pull out the correct info
<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
***Emulatorman___ is now known as Emulatorman
***justan0theruser is now known as justanotheruser
<Posterdati>is thre a debian-hurd installer?
<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> <--- 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