<AlmuHS>ok, after a couple of tests to improve the print aesthetics, are is OK. The exec freeze seems has dissapeared ***flor_ is now known as flor
***Server sets mode: +nt
<damo22>i put my hurd hdd into my x220 laptop and it found the ahci controller and 3 disks attached but failed to probe the 2x SSDs, it probed the cdrom <damo22>maybe its because ide was still enabled <damo22>it booted gnumach off the USB -> sata controller but then obviously could not mount root <damo22>hmm i got an "intnull(11)" just when it probed the first disk <youpi>which means an interrupt got raised but without an irq handler <damo22>but i couldnt see the rest of the log it was too fast <damo22>i think we are going to need ioapic support <damo22>but its probably a good idea to finish rumpdisk + pci-arbiter first <youpi>better finish things before starting others, yes <gnu_srs2>youpi: Is implementation of SA_NOCLDWAIT needed for support of WCONTINUED? ***jma is now known as junlingm
<junlingm>youpi: for user intr handling, I think a single read op would be sufficient, without a writing op: userland program read -> a) register a user_intr_t is has not done so, and queue the read until interrupt occurs or b) if the interrupt has been delivered and has not acked, then ack it, and queue the read; or c) the interrupt has not been delivered, then deliver it. <youpi>I do not understand what you wrote <youpi>but again, see the point I have already made: userland would then need to be able to separate knowing that a read is possible from actually making it <youpi>which I'm not sure is actually possible with the mach messages <youpi>or at least it's really not simple for applications to do this <youpi>while a mere device_read() and device_write() is very simple <youpi>and not actually more costly <jrtc27>read+write is also a standard model for how it's done in hardware <jrtc27>read magic address to get an IRQ, write that IRQ back to the same address when done <junlingm>User land simply does a blocking read. when it returns it knows that an interrupt occured. It then handle the interrupt and read again. The mach side sees another read, and knows that the userland has done its handling, and then ack on behalf of it. <junlingm>Sure. but a write op may involve unnecessary memery wiring from device_write_get. It is not a problem, just unnecessary. <youpi>there is no such thing as memory wiring <junlingm>no, a single read means two things: a notification request AND acking the previous notification, at hte same time. <youpi>that'll be bothersome for the user <youpi>we want the process to ack the interrupt as early as possible <youpi>without imposing it to introduce a thread just for this <youpi>I mean, you are coupling two things together <junlingm>doen't mach need to get the write buffer from the userland handler? I tried to do a zero-byte write without device_write_get, it, but mach isn't happy about it. <youpi>that can only bring headaches to people who may want to have them separate <youpi>and interrupt handling clearly this kind of thing <youpi>mach needs to read the data from userland, yes, but it can use the user segment access for that <youpi>everything is already in the cache so it'll just be a memory read <junlingm>And that is what device_write is doing, I guess? It still does a malloc and memcpy, unless it is inband write. <junlingm>but anyway, as I said, it is not a probllem. <youpi>why would it do a malloc/memcpy <youpi>it just hands over the poniter to the driver <youpi>which here would just ignore it <youpi>ah, wait, yes, it'd copy the content <youpi>since drivers get a kernel poniter, not a user pointe <youpi>but really, we're talking about 1 byte <youpi>actually, could 0-byte device_write not just work? <youpi>and yes, one can use device_write_inband instead <junlingm>I would do a zero byte read and write. But even with that, the device_write_get is needed, otherwise mach panics. I don't see why though.