Skip to content
Snippets Groups Projects
  1. Sep 24, 2013
  2. Sep 23, 2013
    • Nadav Har'El's avatar
      Makefile: Don't hide Gradle's progress · c0ae1bbe
      Nadav Har'El authored
      
      Currently, OSv's "make" builds both the kernel, using a normal Makefile,
      and the sample management framework, using the "Gradle" tool.
      
      We carefully hid Gradle's progress under one output line "GRADLE", but
      this leads to the "make" process hanging for a long time - up to several
      minutes, and all the puzzled user sees is the line "GRADLE". Users who
      didn't go for coffee will likely kill the build at this point ;-) Even
      worse, when Gradle fails, or just hangs (e.g., a bad or slow network
      connection), the user won't even know why.
      
      So let's just run Gradle normally, and let the user see its full output.
      This output is rather pretty and organized, so no real reason to hide it.
      
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      c0ae1bbe
    • Nadav Har'El's avatar
      Clean up "tags" and "TAGS" target · ea6a0dca
      Nadav Har'El authored
      
      Each of the "tags" and "TAGS" make targets was done in a different way,
      causing each to have a different problem:
      
       1. "tags" (ctags) used the "-L" option which turns out is nonportable
          (only available in Exuberant Ctags).
       2. "TAGS" (etags) ran the etags command separately for each source file,
          slowing it down.
      
      The best of both worlds is to use xargs to have ctags/etags operate on
      multiple files in each run using xargs. Because we cannot be sure xargs
      will run ctags/etags only once, we must delete the file first and use
       the "-a" (append) option.
      
      Also, this patch reduces code duplication - there is now one rule for
      both "tags" and "TAGS" targets that uses the correct tool (ctags or etags,
      respectively).
      
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      ea6a0dca
    • Nadav Har'El's avatar
      Merge pull request #41 from jnider/master · f771d2cf
      Nadav Har'El authored
      Update devices-and-drivers.txt
      f771d2cf
    • Nadav Har'El's avatar
      Our select() function is emulated using poll(), which is a sensible thing · b53d39ac
      Nadav Har'El authored
      to do. However, it did several things wrong that this patch fixes. Thanks
      to Paolo Bonzini for finding these problems (see issue #35).
      
      1. When poll() returned a bare POLLHUP, without POLLIN, our select() didn't
      return a read event. But nothing in the manpages guarantees that POLLHUP
      is accompanied by POLLIN, and some special file implementations might
      forget it. As an example, in Linux POLLHUP without POLLIN is common.
      But POLLHUP on its own already means that there's nothing more to read,
      so a read() will return immediately without blocking - and therefore
      select() needs to turn on the readable bit for this fd.
      
      2. Similarly, a bare POLLRDHUP should turn on the writable bit: The
      reader on this file hug up, so a write will fail immediately.
      
      3. Our poll() and select() confused what POLLERR means. POLLERR does not
      mean poll() found a bad file descriptor - there is POLLNVAL for that.
      So this patch fixes poll() to set POLLNVAL, not POLLERR, and select()
      to return with errno=EBADF when it sees POLLNVAL, not POLLERR.
      
      4. Rather, POLLERR means the file descriptor is in an error state, so every
      read() or write() will return immediately (with an error). So when we see
      it, we need to turn on both read and write bits in this case.
      
      5. The meaning of "exceptfds" isn't clear in any manual page, and it
      seems there're a lot of opinions on what it might mean. In this patch I
      did what Paolo suggested, which is to set the except bit when POLLPRI.
      (I don't set exceptfds on POLLERR, or any other case).
      
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      b53d39ac
  3. Sep 22, 2013
  4. Sep 21, 2013
  5. Sep 20, 2013
  6. Sep 19, 2013
  7. Sep 18, 2013
Loading