From 1dc28d745d45be6764072af1da0ceda52a0c17a3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 17 Apr 2012 00:16:32 +0200 Subject: IRC. --- open_issues/dde.mdwn | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) (limited to 'open_issues/dde.mdwn') diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index adb070cd..84ad2f40 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -187,6 +187,37 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: right +# IRC, freenode, #hurd, 2012-02-19 + + antrik: we should probably add a gsoc idea on pci bus arbitration + DDE is still experimental for now so it's ok that you have to + configure it by hand, but it should be automatic at some ponit + + +## IRC, freenode, #hurd, 2012-02-21 + + i'm not familiar with the new gnumach interface for userspace + drivers, but can this pci enumerator be written with it as it is ? + (i'm not asking for a precise answer, just yes - even probably - + or no) + (idk or utsl will do as well) + I'd say yes + since all drivers need is interrupts, io ports and iomem + the latter was already available through /dev/mem + io ports through the i386 rpcs + the changes provide both interrupts, and physical-contiguous + allocation + it should be way enough + youpi: ok + youpi: thanks for the details :) + braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + # IRC, freenode, #hurd, 2012-02-20 I was a bit wary of including the ton of dde headers in hurd-dev @@ -361,3 +392,49 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: because hardware is slow anyway jupp but it is important to see that in real life + + +# IRC, freenode, #hurd, 2012-04-01 + + antrik: I wonder whether you could actually not route the IRQs to a + non-zero ring, AIUI you can in the x86 IDT table + youpi: you mean having a userspace server for each (non-timer) + interrupt? + youpi: how would a userspace IRQ handler interact with the + scheduler? + antrik: it doesn't necessarily have to + provided that it's trusted + youpi: how would you do CPU time accounting if there is no + interaction with the scheduler?... + antrik: you don't necessarily want to care about it + youpi: well, that would mean that all drivers handling interrupts + would have to be trusted to not use more than a very small part of CPU + time... + yes + which is usually needed for interrupt handlers anyway + youpi: nah, the bottom handler only has to do very basic stuff; + afterwards, we can pass off to "normal" driver processes, scheduled just + like other processes... but that requires some interaction between the + IRQ handler and the scheduler I think + the IRQ handler can wake up a thread, yes + no need for anything special there + so the userspace IRQ server would just decide what process to wake + up, and then call the scheduler to do a normal task switch? I guess + that's possible; but I'm not sure it would buy much... + it would permit userland to quickly react to the IRQ + such as acknowledge it to the hardware etc. + yeah, but my point is that I don't see much benefit in having this + part of the code isolated in a userspace process... it has to be trusted + anyways, and it's pretty trivial too + I never said it was a good idea + + +# IRC, freenode, #hurd, 2012-04-06 + + oh i forgot about my work on pcap + is devnode (or devopen or whatever) in the upstream repository now + ? + can't say for sure, but I'd be surprised... don't remember seeing + any movement in that regard :-( + wasn't it needed for dde ? + hm... good point -- cgit v1.2.3