***Server sets mode: +nt
<almuhs>finally you decided to implement ACPICA in userspace, is not? <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 <almuhs>I'm thinking if remove the search from RSDP, and simply hardcode the APIC table address <damo22>well, i think the APIC address is always the same on i386/x86 <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? <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 <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 ? <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>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 <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 <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>ie, make small incremental changes <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>oh, I remember. The very first patch is the configfrag.ac file <damo22>not really, youre not going to turn on NCPUS >1 at the first step, thats later <damo22>you can parse the table without changing anything <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>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 <almuhs>I have a function called acpi_print_info(), which prints all these address. I can add a call to this function <damo22>im not sure if that is a pointer to the table or a pointer to the hardware registers <damo22>maybe you need to probe the tables anyway <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 <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 <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>yeah you only need that once for the root pointer <damo22>the rest of the tables are laid out sequentially <damo22>i wrote a parser in hurd/acpi/acpi.c <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) ***Shentino_ is now known as Shentino
<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>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. <rekado>blood drone is where all the money is made ***snd is now known as DNS
***Emulatorman____ is now known as Emulatorman
