1. 12 6月, 2008 3 次提交
  2. 10 6月, 2008 1 次提交
  3. 09 6月, 2008 2 次提交
  4. 07 6月, 2008 5 次提交
  5. 05 6月, 2008 1 次提交
    • D
      V4L/DVB (7166): [v4l] Add new user class controls and deprecate others · 39028ec6
      David Woodhouse 提交于
      These were removed in commit 26d507fc:
      
      > -#define V4L2_CID_HCENTER               (V4L2_CID_BASE+22)
      > -#define V4L2_CID_VCENTER               (V4L2_CID_BASE+23)
      > -#define V4L2_CID_LASTP1                        (V4L2_CID_BASE+24) /*
      > last CID + 1 */
      > +
      > +/* Deprecated, use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */
      > +#define V4L2_CID_HCENTER_DEPRECATED    (V4L2_CID_BASE+22)
      > +#define V4L2_CID_VCENTER_DEPRECATED    (V4L2_CID_BASE+23)
      
      But there was no warning in Documentation/feature-removal-schedule.txt
      and I'm receiving reports that it's breaking userspace apps (the
      gstreamer-v4l2 plugin breaks in Fedora rawhide). You can't just pull
      things from the published userspace API like that.
      
      Please can we revert the addition of _DEPRECATED to these ioctl
      definitions. Perhaps we can add a runtime warning if they actually get
      used? Or a compile-time warning if we can manage that?
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      39028ec6
  6. 04 6月, 2008 5 次提交
  7. 03 6月, 2008 2 次提交
  8. 01 6月, 2008 1 次提交
    • A
      capabilities: remain source compatible with 32-bit raw legacy capability support. · ca05a99a
      Andrew G. Morgan 提交于
      Source code out there hard-codes a notion of what the
      _LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
      raw capability system calls capget() and capset().  Its unfortunate, but
      true.
      
      Since the confusing header file has been in a released kernel, there is
      software that is erroneously using 64-bit capabilities with the semantics
      of 32-bit compatibilities.  These recently compiled programs may suffer
      corruption of their memory when sys_getcap() overwrites more memory than
      they are coded to expect, and the raising of added capabilities when using
      sys_capset().
      
      As such, this patch does a number of things to clean up the situation
      for all. It
      
        1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
           legacy value.
      
        2. adopts a new #define strategy for the kernel's internal
           implementation of the preferred magic.
      
        3. deprecates v2 capability magic in favor of a new (v3) magic
           number. The functionality of v3 is entirely equivalent to v2,
           the only difference being that the v2 magic causes the kernel
           to log a "deprecated" warning so the admin can find applications
           that may be using v2 inappropriately.
      
      [User space code continues to be encouraged to use the libcap API which
      protects the application from details like this.  libcap-2.10 is the first
      to support v3 capabilities.]
      
      Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
      Thanks to Bojan Smojver for the report.
      
      [akpm@linux-foundation.org: s/depreciate/deprecate/g]
      [akpm@linux-foundation.org: be robust about put_user size]
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NAndrew G. Morgan <morgan@kernel.org>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: Bojan Smojver <bojan@rexursive.com>
      Cc: stable@kernel.org
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      ca05a99a
  9. 30 5月, 2008 7 次提交
  10. 29 5月, 2008 2 次提交
    • I
      sched: re-tune NUMA topologies · ea3f01f8
      Ingo Molnar 提交于
      improve the sysbench ramp-up phase and its peak throughput on
      a 16way NUMA box, by turning on WAKE_AFFINE:
      
                   tip/sched   tip/sched+wake-affine
      -------------------------------------------------
          1:             700              830    +15.65%
          2:            1465             1391    -5.28%
          4:            3017             3105    +2.81%
          8:            5100             6021    +15.30%
         16:           10725            10745    +0.19%
         32:           10135            10150    +0.16%
         64:            9338             9240    -1.06%
        128:            8599             8252    -4.21%
        256:            8475             8144    -4.07%
      -------------------------------------------------
        SUM:           57558            57882    +0.56%
      
      this change also improves lat_ctx from 6.69 usecs to 1.11 usec:
      
        $ ./lat_ctx -s 0 2
        "size=0k ovr=1.19
        2 1.11
      
        $ ./lat_ctx -s 0 2
        "size=0k ovr=1.22
        2 6.69
      
      in sysbench it's an overall win with some weakness at the lots-of-clients
      side. That happens because we now under-balance this workload
      a bit. To counter that effect, turn on NEWIDLE:
      
                    wake-idle          wake-idle+newidle
       -------------------------------------------------
           1:             830              834    +0.43%
           2:            1391             1401    +0.65%
           4:            3105             3091    -0.43%
           8:            6021             6046    +0.42%
          16:           10745            10736    -0.08%
          32:           10150            10206    +0.55%
          64:            9240             9533    +3.08%
         128:            8252             8355    +1.24%
         256:            8144             8384    +2.87%
       -------------------------------------------------
         SUM:           57882            58591    +1.21%
      
      as a bonus this not only improves the many-clients case but
      also improves the (more important) rampup phase.
      
      sysbench is a workload that quickly breaks down if the
      scheduler over-balances, so since it showed an improvement
      under NEWIDLE this change is definitely good.
      ea3f01f8
    • I
      revert ("sched: fair-group: SMP-nice for group scheduling") · 6363ca57
      Ingo Molnar 提交于
      Yanmin Zhang reported:
      
      Comparing with 2.6.25, volanoMark has big regression with kernel 2.6.26-rc1.
      It's about 50% on my 8-core stoakley, 16-core tigerton, and Itanium Montecito.
      
      With bisect, I located the following patch:
      
      | 18d95a28 is first bad commit
      | commit 18d95a28
      | Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      | Date:   Sat Apr 19 19:45:00 2008 +0200
      |
      |     sched: fair-group: SMP-nice for group scheduling
      
      Revert it so that we get v2.6.25 behavior.
      Bisected-by: NYanmin Zhang <yanmin_zhang@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6363ca57
  11. 28 5月, 2008 2 次提交
  12. 27 5月, 2008 2 次提交
  13. 07 6月, 2008 1 次提交
  14. 26 5月, 2008 1 次提交
  15. 25 5月, 2008 5 次提交