<user_oreloznog>Good night hurd, thank you for sharing this wonderful adventure! ***Server sets mode: +nt
<damo22>youpi: to apply spl changes to a debian kernel that means using a patch and committing eg like in debian/patches? <damo22>so i test it like that and when happy send you the patch? <damo22>its a bit of a backward step to what im working on now but it paves the way to getting apic support probably <youpi>damo22: for instance, yes. It's not really backward step, it's just getting things commited progressively <youpi>I'm sorry I have to say that I won't be able to commit a monster 1000-lines patches just like that <youpi>so any kind of step commit will be useful <damo22>im trying to commit regularly so i can break it up, but my own commits are not what i expect will go in <damo22>but its been a work in progress mainly exploring <damo22>i hope i can make my code optional <damo22>so it still compiles with the old pic method by default <damo22>i have a patch that removes the SETIPL() hack and merges the spl1-7 <damo22>im a bit worried that i need to change the linux/ code <damo22>i dont know how i can break that part into steps <damo22>at least with the mach stuff, i can make the APIC module optional <damo22>but if i need to put ifdefs everywhere in linux/ it will be ugly <damo22>compiled gnumach on combined-spl <damo22>i think i figured out why we were using 0x40 as starting vector for pic <damo22>because linux sets the gate as well, and installs interrupt handlers on gate 0x20 <damo22>so when you have a linux driver installed on an irq, it moves the mach vector to somewhere lower <damo22>this will break when i start using apic because it tries to use 24 interrupts and the mapping overlaps <damo22>also, linux drivers set the pic masks manually like gnumach <damo22>so a whole bunch of code is repeated <youpi>that pic mask code will disappear with spl1-6 <youpi>but yeah, the glue code is horrible, that's one of the reasons why we want to get rid of it <youpi>I'd say after removal of spl1-6, get rid of the pic mask, so the code will be cleaner to work on <damo22>i have a patch that could be the first step, just merging the spls <damo22>second patch i could work on removing the pic mask entirely <damo22>because i had to reimplement pic masks for apic and it would be much cleaner without it <damo22>many hard bugs will be prevented <damo22>i dont mind reworking everything <damo22>i needed to explore anyway for my own learning otherwise i could not do this work <damo22>there will still be a concept of masking, but only on or off <youpi>yes, just the interrupt flag <damo22>hmm, so we dont need to mask individual interrupts? <youpi>since your booting with spl1-7 squashed did work, apparently so <youpi>theoretically nowadays' computers are fine with that <youpi>the code might not have been <damo22>but internally, the masks are still there, i just set the priority to 7 <youpi>priority 7 is hardcoded to disabling interrupts entirely <damo22>but somewhere in the code must be a masking of the interrupts that are not being used <damo22>you just dont need all the array <youpi>perhaps the code still does this, but I don't see a reason to keep it <damo22>i think it stores the values it needs in memory and sets them all at once since the PIC has a mask register <damo22>instead of individually toggling them as needed <damo22>so you want me to replace all that with a toggle-as-needed <youpi>I mean there is no need for any toggle at all <damo22>you dont need to enable all irqs <youpi>sure, but that's tedious to avoid enabling them all all the time <youpi>while they are not supposed to happen anyway <youpi>and you might even want to know if they happen because it means something is wrongly configured <damo22>so you want me to make all irqs enabled always, and use cli/sti only in the mach spl handler <damo22>but if you get an interrupt for a vector with no handler? <damo22>i wont need to guess which interrupt is firing for my disk <damo22>it seems to respond quicker to ssh login <damo22>and doesnt have the strange login bug when you log in fast <youpi>not having to reprogram the PIC on each spl change is probably quite cheaper <damo22>is there a way to check the current cli/sti flag? <damo22>without calling one or the other <damo22>if its in the cpu already, i dont even need to store it in memory <damo22>hmm i would need to push it to the stack <damo22>which is equivalent to writing to memory? <youpi>most often yes since that's used very mush <damo22>so its quicker to read it out of the flags <damo22>rather than storing it in a memory location <damo22>i think i'll do it in two stages, keep curr_ipl for now and only have it take 2 values, then remove it for flags <damo22>DEB_BUILD_PROFILES="noxen nodbg" saves me a lot of time <damo22>but i still built it for xen to test compiling <damo22>interesting, i found a problem with linux drivers irq handling... it seems to need pic mask because it probes the irq <damo22>i removed the code that masks the pic <damo22>probe_irq_on() and probe_irq_off() is problematic <damo22>maybe i can allow the linux code to toggle the masks in the pic, but only for probing <damo22>but we are going to need this code for apic too <damo22>so i will write pic.c routines just for probing <damo22>i dont need to store the pic mask anywhere i can read it out of the pic for probing <youpi>damo22: I'd say don't care about probe_irq_on(), just submit a patch that drops any of its use <youpi>that was only useful for ISA systems, with PCI it's never needed <damo22>err, linux drivers use it to detect irqs <youpi>it shows up in the ide driver, but that can be dropped, it's only for odd controllers <youpi>the standard controllers don't need that probing <damo22>it might actually be useful to probe for PCI irqs <youpi>we don't care about NCR53c406a.c <youpi>PCI irqs don't need to be probed <youpi>the device tells us what to use <damo22>they do, otherwise we will need ACPI parser <youpi>probing IRQs is a dumb approach <damo22>you cant get the PCI mapping without ACPI tables <damo22>its actually probably more fun than writing acpi <youpi>I'm not sure which mapping you mention actually <youpi>from reading libpciaccess' x86_pci.c pci_device_x86_probe <youpi>it just reads the irq from the configuration space <youpi>do you mean the pci to apic mapping? <youpi>isn't something that we can actually program ourself? <damo22>you get the PIRQ pin but you dont know which ioapic physical pin is mapped to which <youpi>instead of reading acpi to know how it was programmed? <damo22>or can we just set it to anything we want? <youpi>I haven't ever read APIC documetnation <youpi>but I can tell that probing IRQs is not a simple thing <youpi>you need to know how to trigger an IRQ <damo22>in some systems, PIRQ=0xa for all interrupts <damo22>that doesnt help you find which ioapic pin it is <damo22>i think its specified in the APIC table <damo22>they f$$ked up the mechanism for initing the hardware because OEM manufacturers still use some kind of lookup table to specify the parameters, but they have to compile it to AML and then all OS need to parse it <damo22>would have been so much easier with a static table <damo22>so we cant really use ioapic without including the full acpica code in gnumach? <damo22>there is one possibility, there is a legacy fallback that uses static table overrides <damo22>so do you want me to delete ide driver and NCR53c406a scsi driver? <youpi>disable the parts which use IRQ probing <youpi>it will, when irq is set another way <youpi>which is true for legacy ide <youpi>and true for PCI ide with pic <youpi>basically if (!HWIF(drive)->irq) { panic(); } instead of using probe_irq_on <damo22>damn, timeout waiting for ready on AHCI <damo22>youpi: can you help me identify the mask polarity? i'm having trouble determining if 0xffff means mask all interrupts or 0x0000 means mask all interrupts <damo22>ive currently set the pic mask once, at boot to (0x0000 ^ SLAVE_ON_IR2) <damo22>that should mean "unmask all interrupts except irq2" <gnu_srs2>youpi: How many of the 58 patches to glibc are really needed for a fully functional upstream 2.29 package? <youpi>damo22: according to form_pic_mask(), bits are set in the pic mask to disable an interrupt, so mask 0xffff would disable all interrupts <youpi>gnu_srs2: none of the glibc patches <youpi>none of the gnumach or netdde patches if you are using gnumach network drivers <youpi>(which is the default configuration, it's just that you need to tell qemu to emulate a board supported by network drivers embedded in gnumach) <gnu_srs2>Well: tg-mach-hurd-link.diff was needed for glibc and tg-hurdsig-SA_SIGINFO.diff for util-linux. <youpi>depends what you call "fully functional" <youpi>normally tg-mach-hurd-link.diff shouldn't be needed <youpi>upstream does compile without it <youpi>SA_SIgINFO is needed for some packages <youpi>but if you go that way, all of them become needed at some point <youpi>including the one that drops the ED definition <youpi>only not the -fr.diff translation fixes <gnu_srs2>Since you now have commit access to upstream glibc, maybe some of the Debian patches could be upstreamed. <youpi>a matter of doing it, needs time, help welcome to review patches, etc. <youpi>quite a few of them can't be applied as such, they need work, etc. <youpi>and don't look at the 2.29 sources, rather look at the 2.30 sources, I have renamed some of them to "git-" bnecause they have been applied <youpi>(I mean debian 2.30 sources, in the experimental branch) <gnu_srs2>For the cross-compile, I don't use any Debian packages, only upstream tarballs. (and apply some needed Debian patches) ***Glider_IRC__ is now known as Glider_IRC