1. 28 4月, 2010 1 次提交
  2. 09 3月, 2010 1 次提交
  3. 08 3月, 2010 1 次提交
  4. 04 3月, 2010 1 次提交
  5. 27 2月, 2010 4 次提交
  6. 26 2月, 2010 1 次提交
    • M
      MAINTAINERS: update drivers/platform/x86 information · d0944853
      Matthew Garrett 提交于
      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: NMatthew 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
  7. 24 2月, 2010 1 次提交
  8. 23 2月, 2010 1 次提交
  9. 20 2月, 2010 2 次提交
  10. 19 2月, 2010 3 次提交
  11. 18 2月, 2010 2 次提交
  12. 12 2月, 2010 1 次提交
  13. 09 2月, 2010 1 次提交
  14. 23 1月, 2010 1 次提交
  15. 17 1月, 2010 2 次提交
  16. 16 1月, 2010 1 次提交
  17. 15 1月, 2010 3 次提交
    • D
      MAINTAINERS: transfer maintainership of I/OAT · 9fe3b691
      Dan Williams 提交于
      Dan Williams takes over I/OAT from Maciej Sosnowski
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fe3b691
    • M
      vhost_net: a kernel-level virtio server · 3a4d5c94
      Michael S. Tsirkin 提交于
      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: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a4d5c94
    • M
      alpha: add myself as a maintainer, and drop mention of 2.4 · abd4d609
      Matt Turner 提交于
      CC: Richard Henderson <rth@twiddle.net>
      CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      CC: linux-alpha@vger.kernel.org
      Signed-off-by: NMatt Turner <mattst88@gmail.com>
      abd4d609
  18. 13 1月, 2010 1 次提交
  19. 11 1月, 2010 2 次提交
  20. 02 1月, 2010 1 次提交
  21. 30 12月, 2009 1 次提交
    • S
      firewire, ieee1394: update MAINTAINERS entries · 958a29cb
      Stefan Richter 提交于
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NDan Dennedy <dan@dennedy.org>
      Cc: Ben Collins <ben.collins@ubuntu.com>
      Cc: Kristian Hoegsberg <krh@bitplanet.net>
      958a29cb
  22. 24 12月, 2009 2 次提交
  23. 23 12月, 2009 1 次提交
  24. 22 12月, 2009 1 次提交
  25. 16 12月, 2009 4 次提交