Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 2月, 2010 1 次提交
  3. 12 2月, 2010 1 次提交
  5. 09 2月, 2010 1 次提交
  7. 23 1月, 2010 1 次提交
  9. 17 1月, 2010 2 次提交
  11. 16 1月, 2010 1 次提交
  13. 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
  15. 11 1月, 2010 2 次提交
  17. 02 1月, 2010 1 次提交
  19. 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
  21. 24 12月, 2009 2 次提交
  23. 23 12月, 2009 1 次提交
  25. 22 12月, 2009 1 次提交
  27. 16 12月, 2009 6 次提交
  29. 15 12月, 2009 1 次提交
    • A
      x25: Update maintainer. · 8bf28059
      由 Arnd Bergmann 提交于 
      On Monday 14 December 2009, andrew hendry wrote:
> Thanks, I didn't know X.25 was actively maintained. I get bounces.
> Is the the maintainers out of date?

From looking at the posts on the x.25 mailing list and the changes
that went into the kernel during the last three years in that area,
I think it is safe to say that you are now the maintainer ;-).

The last mail on this topic from Henner Eisen was around 2001.

> AX.25 NETWORK LAYER
> M:      Ralf Baechle <ralf@linux-mips.org>
>
> X.25 NETWORK LAYER
> M:      Henner Eisen <eis@baty.hanse.de>

How about this change?
Signed-off-by: NAndrew Hendry <andrew.hendry@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8bf28059
  31. 12 12月, 2009 3 次提交
  33. 11 12月, 2009 1 次提交
  35. 10 12月, 2009 4 次提交
  37. 09 12月, 2009 2 次提交
  39. 08 12月, 2009 1 次提交
  41. 07 12月, 2009 1 次提交
  43. 05 12月, 2009 2 次提交
  45. 04 12月, 2009 1 次提交