IRC.

1 files changed, 144 insertions, 0 deletions

diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 76b80211..9cb31d1c 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -512,6 +512,18 @@ After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
     <antrik> hm... good point
 
 
+## IRC, freenode, #hurd, 2013-09-20
+
+    <braunr> i should take some time to integrate my pcap changes into the
+      libpcap debian package at least
+    <pinotree> braunr: if upstream is active, i'd say to go there directly
+    <braunr> the problem with that approach is that netdde is still not part of
+      our upstream code
+    <pinotree> don't understand the relation
+    <braunr> i don't want to send the pcap guys code for an interface that is
+      still not considered upstream ...
+
+
 # IRC, freenode, #hurd, 2012-08-14
 
     <braunr> it's amazing how much code just gets reimplemented needlessly ...
@@ -642,3 +654,135 @@ In context of [[libpthread]].
       stuff
     <braunr> there is
     <braunr> but relatively to other improvements, it's low
+
+
+## IRC, freenode, #hurd, 2013-09-14
+
+    <rekado> I'm slowly beginning to understand the virtio driver framework
+      after reading Rusty's virtio paper and the Linux sources of a few virtio
+      drivers.
+    <rekado> Has anyone started working on virtio drivers yet?
+    <youpi> rekado: nobody has worked on virtio drivers, as I know of
+    <rekado> youpi: I'm still having a hard time figuring out where virtio
+      would fit in in the hurd.
+    <rekado> I'm afraid I don't understand how drivers in the hurd work at all.
+      Will part of this have to be implemented in Mach?
+    <youpi> rekado: it could be implemented either as a Mach driver, or as a
+      userland driver
+    <youpi> better try the second alternative
+    <youpi> i.e. as a translator
+    <youpi> sitting on e.g. /dev/eth0 or /dev/hd0
+
+
+## IRC, freenode, #hurd, 2013-09-18
+
+    <rekado> To get started with virtio I'd like to write a simple driver for
+      the entropy device which appears as a PCI device when running qemu with
+      -device virtio-rng-pci .
+    <braunr> why entropy ?
+    <rekado> because it's the easiest.
+    <braunr> is it ?
+    <braunr> the driver itself may be, but integrating it within the system
+      probably isn't
+    <rekado> It uses the virtio framework but only really consists of a
+      read-only buffer virtqueue
+    <braunr> you're likely to want something that can be part of an already
+      existing subsystem like networking
+    <rekado> All the driver has to do is push empty buffers onto the queue and
+      pass the data it receives back from the host device to the client
+    <rekado> The thing about existing subsystems is: I don't really understand
+      them enough.
+    <rekado> I understand virtio, though.
+    <braunr> but isn't your goal understanding at least one ?
+    <rekado> yes.
+    <braunr> then i suggest working on virtio-net
+    <braunr> and making it work in netdde
+    <rekado> But to write a virtio driver for network I must first understand
+      how to actually talk to the host virtio driver/device.
+    <braunr> rekado: why ?
+    <rekado> There is still a knowledge gap between what I know about virtio
+      and what I have learned about the Hurd/Mach.
+    <braunr> are you trying to learn about virtio or the hurd ?
+    <rekado> both, because I'd like to write virtio drivers for the hurd.
+    <braunr> hm no
+    <rekado> with virtio drivers pass buffers to queues and then notify the
+      host.
+    <braunr> you may want it, but it's not what's best for the project
+    <rekado> oh.
+    <braunr> what's best is reusing existing drivers
+    <braunr> we're much too far from having enough manpower to maintain our own
+    <rekado> you mean porting the linux virtio drivers?
+    <braunr> there already is a virtio-net driver in linux 2.6
+    <braunr> so yes, reuse it
+    <braunr> the only thing which might be worth it is a gnumach in-kernel
+      driver for virtio block devices
+    <braunr> because currently, we need our boot devices to be supported by the
+      kernel itself ...
+    <rekado> when I boot the hurd with qemu and the entropy device I see it as
+      an unknown PCI device in the output of lspci.
+    <braunr> that's just the lspci database which doesn't know it
+    <rekado> Well, does this mean that I could actually talk to the device
+      already? E.g., through libpciaccess?
+    <rekado> I'm asking because I don't understand how exactly devices "appear"
+      on the Hurd.
+    <braunr> it's one of the most difficult topic currently
+    <braunr> you probably can talk to the device, yes
+    <braunr> but there are issues with pci arbitration
+    * rekado takes notes: "pci arbitration"
+    <rekado> so, this is about coordinating bus access, right?
+    <braunr> yes
+    <braunr> i'm not a pci expert so i can't tell you much more
+    <rekado> heh, okay.
+    <rekado> what kind of "issues with pci arbitration" are you referring to,
+      though?
+    <rekado> Is this due to something that Mach isn't doing?
+    <braunr> ideally, mach doesn't know about pci
+    <braunr> the fact we still need in-kernel drivers for pci devices is a big
+      problem
+    <braunr> we may need something like a pci server in userspace
+    <braunr> on l4 system it's called an io server
+    <rekado> How do in-kernel drivers avoid these issues?
+    <braunr> they don't
+    <rekado> Or rather: why is it they don't have these issues?
+    <braunr> they do
+    <rekado> oh.
+    <braunr> we had it when youpi added the sata driver
+    <braunr> so currently, all drivers need to avoid sharing common interrupts
+      for example
+    <braunr> again, since i'm not an expert about pci, i don't know more about
+      the details
+    <Hooligan0> pci arbitrations are made by hardware ... no ?
+    <braunr> Hooligan0: i don't know
+    <braunr> i'm not merely talking about bus mastering here
+    <braunr> simply preventing drivers from mapping the same physical memory
+      should be enforced somewhere
+    <braunr> i'm not sure it is
+    <braunr> same for irq sharing
+    <Hooligan0> braunr : is the support for boot devices into the kernel is
+      really needed if a loader put servers into the memory before starting
+      mach ?
+    <braunr> Hooligan0: there is a chicken-and-egg problem during boot,
+      whatever the solution
+    <braunr> obviously, we can preload from memory, but then you really want
+      your root file system to use a disk
+    <braunr> Hooligan0: the problem with preloading from memory is that you
+      want the root file system to use a real device
+    <braunr> the same way / refers to one on unix
+    <braunr> so you have an actual, persistent hierarchy from which the system
+      can be initialized and translators started
+    <braunr> you also want to share as much as possible between the early
+      programs and the others
+    <braunr> so for example, both the disk driver and the root file system
+      should be able to use the same libc instance
+    <braunr> this requires a "switch root" mechanism that needs to be well
+      defined and robust
+    <braunr> otherwise we'd just build our drivers and root fs statically
+    <braunr> (which is currently done with rootfs actually)
+    <braunr> and this isn't something we're comfortable with
+    <braunr> so for now, in-kernel drivers
+    <Hooligan0> humm ... disk driver and libc ... i see
+    <Hooligan0> in other way ... disk drivers can use only a little number of
+      lib* functions ; so with a static version, a bit of memory is lots
+    <Hooligan0> s/lots/lost
+    <Hooligan0> and maybe the driver can be hot-replaced after boot (ok ok,
+      it's more simple to say than to write)