Hi -

On 2016-10-17 at 14:36 "Ronald G. Minnich" <rminn...@gmail.com> wrote:
> In qemu, it still shows the device as having zero bytes.
> But it does find it.

I'll take this whole patch set as is, since you all are basically the
maintainers of it and you're actively fixing it up.  


Merged to master at bd57db6e170d..e68a8934c7fd (from, to]

You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/bd57db6e170d...e68a8934c7fd



Here's a few other things to either fix in the future or keep in mind:


1) This:

@@ -211,16 +209,38 @@ static int prid = 1;
+/* ALL time units in this file are in milliseconds. */ 
+static uint32_t ms(void)
+{
+   return (uint32_t)(epoch_nsec() / 1048576); 
+}

This should probably be epoch_nsec() / 1000000.


2) Krefs

Any use of krefs in ported Plan 9 code will need looked at.  I noticed
this:

+static void releasedrive(struct kref *kref)
+{
+   printk("release drive called, but we don't do that yet\n");
+}
+

Usually, it'll require a rewrite / restructuring of the code.  Just
FYI. 


3) waserror:

 static void esleep(int ms)
 {
-   struct proc *up = externup();
+   ERRSTACK(2);
    if (waserror())
        return;
-   tsleep(&up->sleep, return0, 0, ms);
+   kthread_usleep(ms * 1000);
    poperror();
 }

The rules for waserror:
- Have as many ERRSTACK as there are waserrors (so 1, not 2).  It's not
  going to crash, but it'll consume more stack space.
- Every path from a waserror needs either a poperror or a nexterror.
  This is different than Plan 9, so it is always something that
  needs attention during a driver port. 

In the example code (and in other places), the error path does not
have a poperror or nexterror.  It looks like you are trying to catch the
error and just return. To do so:

        if (waserror()) {
                poperror();
                return;
        }

4) Magic unicode characters 

+   printd("ahci: %s: resetdisk: %s → %s\n",

Plan 9 (and Go) is way to clever with their fancy characters.


5) PCI phantoms

+   /* In earlier days bus address 0xff caused problems so we only
  iterated to
+    * PCI_MAX_BUS - 1, but this should no longer be an issue.
+    * Old comment: phantoms at 0xff */

Your changes are fine.  From what I recall, we had machines where we'd
see devices appear multiple times in the PCI space, once at their 'real'
location, and another time on bus 0xff.  I don't know exactly what the
phantoms are, though this has a few clues:

https://pcisig.com/sites/default/files/specification_documents/ECN-alt-rid-interpretation-070604.pdf

Barret

-- 
You received this message because you are subscribed to the Google Groups 
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akaros+unsubscr...@googlegroups.com.
To post to this group, send email to akaros@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to