IRC channel logs


back to list of logs

***Server sets mode: +nt
<almuhs>hi damo22
<almuhs>finally you decided to implement ACPICA in userspace, is not?
<damo22>hi almuhs
<damo22>i think that is best option yes
<damo22>it wasnt a total waste of time, i think i found a bug in ACPICA
<almuhs>I'm thinking about to refactor my current acpi_setup() code, to call It after paging configuration
<damo22>lets do it properly
<almuhs>I'm thinking if remove the search from RSDP, and simply hardcode the APIC table address
<almuhs>this can do easier the mapping
<damo22>well, i think the APIC address is always the same on i386/x86
<damo22>so that should work
<almuhs>with a bit of luck, I can remove the "extra_setup()" code, and do this mapping in the same acpi_apic_setup(), instead in kern/startup.c
<almuhs>Richard also told me that IOAPIC must be stored in a list, not in a array. This can be a improve too
<almuhs>are there any linked list in gnumach?
<damo22>err why
<almuhs>most OS implement the list of IOAPIC in a linked list
<almuhs>Richard was angry when he saw that I had implemented this list with an array
<damo22>hehe, i think he just thought you were trying to make it work quickly instead of doing it properly
<almuhs>I used an array to avoid the memory reserve, simply
<damo22>i think the important part is to put the table stuff into one C file
<youpi>don't try to spare bytes
<youpi>that's really useless :)
<almuhs>but maybe there are any reason for use a linked list
<youpi>what's important nowadays is code maintainability
<damo22>and store a static global pointer in that C file
<damo22>so everything relating to ACPI in the kernel hangs off the same module
<almuhs>It's necessary to read another ACPI table, furthermore to APIC ?
<almuhs>in gnumach
<damo22>i think for SMP init and IOAPIC init it should be enough with one table, as far as i know
<almuhs>my current idea is to write an ad-hoc parser to APIC table
<almuhs>what do you refers with "one table"?
<almuhs>oh, ok
<almuhs>then I keep my idea about an APIC ad-hoc parser
<damo22>there might be some DSDT stuff that needs to be initialised but i am hoping this can be done after bootup in userspace
<almuhs>do you know how to configure Local APIC and IOAPIC? This task is very difficult for my knowledge
<damo22>yeah i wrote most of that stuff in my fork of your repo
<almuhs>in my current code, I simply access to Local APIC to send IPI
<damo22>i configured the lapic timers
<almuhs>then I will try to refactor the acpi_setup() code, to try to move It after paging. This shift-based addressing is very ugly for me
<almuhs>I will also try to move apic_id to a new structure
<damo22>we need to separate out ioapic from lapic timers
<damo22>we can leave the ioapic unconfigured and use PIC for now
<almuhs>my current code use PIC
<damo22>adding IOAPIC support is a separate thing
<almuhs>yes, can be better do this task in a new file
<damo22>interrupts are going to be ugly if we try to do too much at once
<almuhs>the acpi_setup() might be only the parser and a basic mapping to lapic
<damo22>i already tried this
<damo22>we need to stage the changes
<almuhs>what do you refers?
<damo22>ie, make small incremental changes
<damo22>so they can be merged
<damo22>we cant have huge patchset
<damo22>no one will review
<almuhs>I also thank about send little patches to upstreams, once each step has been finished and tested
<almuhs>when we finish a step, we test It and, if works, send a patch
<almuhs>I think we will have to rewrite my project, to get a better design
<damo22>we can have a bunch of commits thats okay, but they need to be small commits
<almuhs>I will start with APIC's refactor
<damo22>yeah, start by writing a nice parser for the APIC table that works in isolation
<damo22>like a small module you can add to gnumch
<almuhs>we can rewrite this tasklist
<almuhs>oh, I remember. The very first patch is the file
<damo22>not really, youre not going to turn on NCPUS >1 at the first step, thats later
<almuhs>ok, It's well
<almuhs>This is my mod:
<damo22>you can parse the table without changing anything
<damo22>make it print out a debugn log
<almuhs>It's true
<damo22>with the table info
<almuhs>parse the table and print the data, but without reserve lapic at first
<almuhs>ACPI: APIC 0x 07ffe2013 000078 (v1 BOCHS BXPCAPIC 00000001 BXPC 00000001)
<almuhs>the APIC address is the first number?
<damo22>thats the virtual mapped address
<almuhs>what is the physical address=
<damo22>check the RDSP
<almuhs>ACPI: RSDP 0x 0 f58c0 000014 (v0 BOCHS )
<damo22>i cant remember, its something like 0xfee00000
<almuhs>maybe in my prints I could find It
<almuhs>0xfee00000 is the lapic address in my prints
<almuhs>the apic address is not in my prints, but maybe I can add It
<damo22>you can boot qemu and find it
<damo22>xp/10c 0xf58c0
<damo22>xp/60c 0xf58c0
<damo22>in the qemu console
<damo22>well your RSDP is not there
<almuhs>I have a function called acpi_print_info(), which prints all these address. I can add a call to this function
<damo22>i think its 0xfec00000
<damo22>for the IOAPIC address
<almuhs>I want the MADT address
<damo22>im not sure if that is a pointer to the table or a pointer to the hardware registers
<almuhs>IOAPIC or MADT?
<damo22>maybe you need to probe the tables anyway
<almuhs>what tables?
<almuhs>my idea is to find the physical address of MADT table, and hardcode It
<damo22>i think you need to start with RSDP, find the root table pointer and then loop through all the tables until you hit MADT
<damo22>its different on each board
<almuhs>this is my current code
<almuhs>then I can't hardcode MADT address
<almuhs>this will be a heavy task then, I will have to map many address. But It's possible
<damo22>you dont need to map all the tables
<damo22>only madt
<almuhs>But I need to find the virtual address of each physical address
<damo22>all you need is the root table pointer and start looping through it sequentially?
<almuhs>the problem is that the pointer stores the physical address of each table
<almuhs>by this reason I had to call phystokv with each address
<damo22>but you can skip the tables that are not needed
<damo22>the length is provided in the header
<damo22>sorry, thats irrelevant
<damo22>they are a fixed length
<almuhs>by example:
<damo22>yeah you only need that once for the root pointer
<damo22>the rest of the tables are laid out sequentially
<almuhs>in RSDP and RSDT
<damo22>i wrote a parser in hurd/acpi/acpi.c
<almuhs>to find RSDP and RSDT
<damo22>well i assumed it would be near 0xe0000
<damo22>you just need to find "RSD PTR "
<almuhs>my code check all memory blocks refered in the docs
<damo22>but its tricky because there are two versions of the table
<almuhs>(really, It's not my code. Most of this code was written by a friend, based in X15 code)
<almuhs>the ACPI parser
<almuhs>the code to find RSDP is here:
<almuhs>or, exactly:
<damo22>sorry i need to go
<almuhs>ok, thanks
<damo22>take care, we'll talk soon
<almuhs>I go to sleep
***Shentino_ is now known as Shentino
<peanutbutterandc>Hey there!
<peanutbutterandc>I managed to get guix-hurd and debian-hurd running (qemu) for the first time yesterday. And it got me thinking a little bit about hurd...
<peanutbutterandc>I am a n00b. But I read somewhere that drivers in linux are in the kernel-space. I'm not entirely sure what that means, but ever since then I have been scared to install not-entirely-free printer drivers from the printer manufacturers on my personal machine (Linux Mint, Ubuntu and friends allow that, of course)
<peanutbutterandc>And I was wondering if hurd has some other way of managing drivers...
<peanutbutterandc>Like... one gets to load up a driver and then remove it during runtime, and the driver does not run in kernel-space but is just another module or something? so that even if the only option I had was to use a propritary one, I could just use it without being scared?
<peanutbutterandc>I know this might be a stupid question. If there are any documentations etc that I should RTFM, please do guide me to it
<plasma41>peanutbutterandc: Most (all?) device drivers in Hurd run in userspace
<peanutbutterandc>plasma41, Oh wow. That is cool. But could you please tell me what implications it has for an average joe like me? Do I get to not be scared about using drivers from shady-manufacturers?
<plasma41>Non-free software should raise concern regardless of whether it's running in user- or kernel-space.
<peanutbutterandc>plasma41, Yes, sir. I understand. And I hope to be able to get to the level where I can write drivers myself, rather than use a proprietary one.
<peanutbutterandc>I have also heard that hurd has designs for non-privileged containers. I wonder if it'd be possible, in hurd, to sandbox a shady driver using a container to minimize the risk of it causing any harm to the users or something? So, instead of printing using a printer for which I only have the 'official' driver directly from the machine, I set up a container, load up the driver inside it, and use that container to do the printing or something?
<plasma41>Unfortunately, the amount of hardware for which there are free device drivers for Hurd pales in comparison to the amount of hardware the has Linux kernel drivers.
<plasma41>As far as printers are concerned, the best thing to do is to choose printers that have free drivers. and are the best places for verifying that
<peanutbutterandc>plasma41, I understand. I wonder if the hurd contributors here do get a chuckle out of this: But HURD does seem so very exciting.
<plasma41>Indeed. :-D
<peanutbutterandc>I'm glad it is the case. :)
<rekado>blood drone is where all the money is made
***snd is now known as DNS
***Emulatorman____ is now known as Emulatorman