path: root/open_issues/dde.mdwn
diff options
Diffstat (limited to 'open_issues/dde.mdwn')
1 files changed, 77 insertions, 0 deletions
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]]:
<antrik> right
+# IRC, freenode, #hurd, 2012-02-19
+ <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration
+ <youpi> 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
+ <braunr> i'm not familiar with the new gnumach interface for userspace
+ drivers, but can this pci enumerator be written with it as it is ?
+ <braunr> (i'm not asking for a precise answer, just yes - even probably -
+ or no)
+ <braunr> (idk or utsl will do as well)
+ <youpi> I'd say yes
+ <youpi> since all drivers need is interrupts, io ports and iomem
+ <youpi> the latter was already available through /dev/mem
+ <youpi> io ports through the i386 rpcs
+ <youpi> the changes provide both interrupts, and physical-contiguous
+ allocation
+ <youpi> it should be way enough
+ <braunr> youpi: ok
+ <braunr> youpi: thanks for the details :)
+ <antrik> 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
+ <antrik> 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
<youpi> 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]]:
<youpi> because hardware is slow anyway
<ArneBab> jupp
<ArneBab> but it is important to see that in real life
+# IRC, freenode, #hurd, 2012-04-01
+ <youpi> antrik: I wonder whether you could actually not route the IRQs to a
+ non-zero ring, AIUI you can in the x86 IDT table
+ <antrik> youpi: you mean having a userspace server for each (non-timer)
+ interrupt?
+ <antrik> youpi: how would a userspace IRQ handler interact with the
+ scheduler?
+ <youpi> antrik: it doesn't necessarily have to
+ <youpi> provided that it's trusted
+ <antrik> youpi: how would you do CPU time accounting if there is no
+ interaction with the scheduler?...
+ <youpi> antrik: you don't necessarily want to care about it
+ <antrik> 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...
+ <youpi> yes
+ <youpi> which is usually needed for interrupt handlers anyway
+ <antrik> 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
+ <youpi> the IRQ handler can wake up a thread, yes
+ <youpi> no need for anything special there
+ <antrik> 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...
+ <youpi> it would permit userland to quickly react to the IRQ
+ <youpi> such as acknowledge it to the hardware etc.
+ <antrik> 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
+ <youpi> I never said it was a good idea
+# IRC, freenode, #hurd, 2012-04-06
+ <braunr> oh i forgot about my work on pcap
+ <braunr> is devnode (or devopen or whatever) in the upstream repository now
+ ?
+ <antrik> can't say for sure, but I'd be surprised... don't remember seeing
+ any movement in that regard :-(
+ <braunr> wasn't it needed for dde ?
+ <antrik> hm... good point