An error occurred fetching the project authors.
  1. 06 Mar, 2010 3 commits
  2. 01 Mar, 2010 2 commits
  3. 26 Feb, 2010 4 commits
  4. 25 Feb, 2010 1 commit
    • Matthew Garrett's avatar
      MAINTAINERS: update drivers/platform/x86 information · d0944853
      Matthew Garrett authored
      Many of the drivers/platform/x86 drivers have nothing to do with ACPI, so
      it's kind of inappropriate for them to be stuck under the ACPI mailing
      list. Add a new mailing list (platform-driver-x86@vger.kernel.org) and,
      with Len's blessing, add myself as subsystem maintainer.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Anisse Astier <anisse@astier.eu>
      Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
      Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Daniel Oliveira Nascimento <don@syst.com.br>
      Cc: Harald Welte <laforge@gnumonks.org>
      Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
      Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
      Cc: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
      Cc: Karol Kozimor <sziwan@users.sourceforge.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Lennart Poettering <mzxreary@0pointer.de>
      Cc: Mattia Dongili <malattia@linux.it>
      Cc: Peter Feuerer <peter@piie.net>
      Cc: Sujith Thomas <sujith.thomas@intel.com>
      Cc: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      d0944853
  5. 24 Feb, 2010 1 commit
  6. 23 Feb, 2010 1 commit
  7. 20 Feb, 2010 1 commit
  8. 19 Feb, 2010 1 commit
  9. 18 Feb, 2010 3 commits
  10. 17 Feb, 2010 2 commits
  11. 11 Feb, 2010 1 commit
  12. 09 Feb, 2010 1 commit
  13. 23 Jan, 2010 1 commit
  14. 17 Jan, 2010 2 commits
  15. 16 Jan, 2010 1 commit
  16. 15 Jan, 2010 2 commits
    • Dan Williams's avatar
      MAINTAINERS: transfer maintainership of I/OAT · 9fe3b691
      Dan Williams authored
      Dan Williams takes over I/OAT from Maciej Sosnowski
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9fe3b691
    • Michael S. Tsirkin's avatar
      vhost_net: a kernel-level virtio server · 3a4d5c94
      Michael S. Tsirkin authored
      What it is: vhost net is a character device that can be used to reduce
      the number of system calls involved in virtio networking.
      Existing virtio net code is used in the guest without modification.
      
      There's similarity with vringfd, with some differences and reduced scope
      - uses eventfd for signalling
      - structures can be moved around in memory at any time (good for
        migration, bug work-arounds in userspace)
      - write logging is supported (good for migration)
      - support memory table and not just an offset (needed for kvm)
      
      common virtio related code has been put in a separate file vhost.c and
      can be made into a separate module if/when more backends appear.  I used
      Rusty's lguest.c as the source for developing this part : this supplied
      me with witty comments I wouldn't be able to write myself.
      
      What it is not: vhost net is not a bus, and not a generic new system
      call. No assumptions are made on how guest performs hypercalls.
      Userspace hypervisors are supported as well as kvm.
      
      How it works: Basically, we connect virtio frontend (configured by
      userspace) to a backend. The backend could be a network device, or a tap
      device.  Backend is also configured by userspace, including vlan/mac
      etc.
      
      Status: This works for me, and I haven't see any crashes.
      Compared to userspace, people reported improved latency (as I save up to
      4 system calls per packet), as well as better bandwidth and CPU
      utilization.
      
      Features that I plan to look at in the future:
      - mergeable buffers
      - zero copy
      - scalability tuning: figure out the best threading model to use
      
      Note on RCU usage (this is also documented in vhost.h, near
      private_pointer which is the value protected by this variant of RCU):
      what is happening is that the rcu_dereference() is being used in a
      workqueue item.  The role of rcu_read_lock() is taken on by the start of
      execution of the workqueue item, of rcu_read_unlock() by the end of
      execution of the workqueue item, and of synchronize_rcu() by
      flush_workqueue()/flush_work(). In the future we might need to apply
      some gcc attribute or sparse annotation to the function passed to
      INIT_WORK(). Paul's ack below is for this RCU usage.
      
      (Includes fixes by Alan Cox <alan@linux.intel.com>,
      David L Stevens <dlstevens@us.ibm.com>,
      Chris Wright <chrisw@redhat.com>)
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a4d5c94
  17. 14 Jan, 2010 1 commit
  18. 13 Jan, 2010 1 commit
  19. 11 Jan, 2010 2 commits
  20. 02 Jan, 2010 1 commit
  21. 29 Dec, 2009 1 commit
    • Stefan Richter's avatar
      firewire, ieee1394: update MAINTAINERS entries · 958a29cb
      Stefan Richter authored
      Ben and Kristian have not been involved in maintenance of the IEEE 1394
      drivers for quite some time; submitters are not required to Cc them on
      patches.
      
      The linux1394.org domain has been dead for a while and is no longer
      under control of a Linux developer.  The current web site of the
      Linux 1394 project is http://ieee1394.wiki.kernel.org/.
      
      The classic drivers/ieee1394/ stack is now obsolete from the development
      point of view, though still a useful alternative in productive use.  But
      nobody should attempt to submit style cleanup patches for it or to
      develop new drivers on top of this stack, hence mark its MAINTAINERS
      entry as Obsolete.
      
      drivers/ieee1394/raw1394*, like the rest of the old stack, does not
      receive bigger code changes anymore, hence shrink the MAINTAINERS
      database a bit by dropping raw1394's special entry.  If something
      important and urgent is going to come up for raw1394, I will make sure
      that Dan will be notified of it besides via linux1394-devel.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarDan Dennedy <dan@dennedy.org>
      Cc: Ben Collins <ben.collins@ubuntu.com>
      Cc: Kristian Hoegsberg <krh@bitplanet.net>
      958a29cb
  22. 24 Dec, 2009 1 commit
  23. 23 Dec, 2009 2 commits
  24. 22 Dec, 2009 1 commit
  25. 16 Dec, 2009 1 commit
  26. 15 Dec, 2009 2 commits