execve: use direct user mappings
authorAlan Cox <alan@linux.intel.com>
Sun, 25 Jan 2015 00:24:06 +0000 (00:24 +0000)
committerAlan Cox <alan@linux.intel.com>
Sun, 25 Jan 2015 00:24:06 +0000 (00:24 +0000)
If your disk devices don't support this then you'll need to enable the
CONFIG_LEGACY_EXEC option and fix the target. (This probably will get renamed
because if we get to stuff like 68000 it may be we have a cache big enough to
make execve via it useful)

This makes execve much faster, way faster on slow memory devices. The remaining
performance killer is the lack of vfork.

Kernel/syscall_exec.c

index 3b32572..6658031 100644 (file)
@@ -13,6 +13,7 @@ static int bload(inoptr i, uint16_t bl, uint16_t base, uint16_t len)
                if (blk == NULLBLK)
                        uzero((uint8_t *)base, 512);
                else {
+#ifdef CONFIG_LEGACY_EXEC
                        buf = bread(i->c_dev, blk, 0);
                        if (buf == NULL) {
                                kprintf("bload failed.\n");
@@ -21,6 +22,17 @@ static int bload(inoptr i, uint16_t bl, uint16_t base, uint16_t len)
                        uput(buf, (uint8_t *)base, cp);
                        bufdiscard((bufptr)buf);
                        brelse((bufptr)buf);
+#else
+                       /* Might be worth spotting sequential blocks and
+                          merging ? */
+                       udata.u_offset = blk << 9;
+                       udata.u_count = 512;
+                       udata.u_base = (uint8_t *)base;
+                       if (cdread(i->c_dev, 0) < 0) {
+                               kprintf("bload failed.\n");
+                               return -1;
+                       }
+#endif
                }
                base += cp;
                len -= cp;