Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 12月, 2009 1 次提交
  3. 07 4月, 2009 1 次提交
  5. 30 3月, 2009 2 次提交
  7. 03 1月, 2009 1 次提交
  9. 12 10月, 2008 3 次提交
  11. 04 9月, 2008 1 次提交
  13. 27 7月, 2008 1 次提交
  15. 26 7月, 2008 1 次提交
  17. 24 7月, 2008 1 次提交
  19. 25 4月, 2008 1 次提交
  21. 26 1月, 2008 1 次提交
    • J
      V4L/DVB (7036): radio: Use video_device_release rather than kfree · f37fdf3f
      由 Julia Lawall 提交于 
      The file drivers/media/video/videodev.c defines both video_device_alloc and
video_device_release.  These are essentially just kzmalloc and kfree,
respectively, but it seems better to use video_device_release, as done in
the other media files, rather than kfree, in case the implementation some
day changes.

The problem was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
type T,T1,T2;
identifier E;
statement S;
expression x1,x2,x3;
int ret;
@@

  T E;
  ...
* E = video_device_alloc(...);
  if (E == NULL) S
  ... when != video_device_release(...,(T1)E,...)
      when != if (E != NULL) { ... video_device_release(...,(T1)E,...); ...}
      when != x1 = (T1)E
      when != E = x3;
      when any
  if (...) {
    ... when != video_device_release(...,(T2)E,...)
        when != if (E != NULL) { ... video_device_release(...,(T2)E,...); ...}
        when != x2 = (T2)E
(
*   return;
|
*   return ret;
)
  }
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      f37fdf3f
  23. 09 5月, 2007 1 次提交
  25. 28 4月, 2007 1 次提交
  27. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  29. 13 2月, 2007 1 次提交
  31. 26 9月, 2006 1 次提交
  33. 25 6月, 2006 2 次提交
  35. 07 2月, 2006 1 次提交
  37. 11 1月, 2006 5 次提交
  39. 10 1月, 2006 1 次提交
    • A
      V4L (926_2): Moves compat32 functions from fs to v4l subsystem · 0d0fbf81
      由 Arnd Bergmann 提交于 
      This moves the 32 bit ioctl compatibility handlers for
Video4Linux into a new file and adds explicit calls to them
to each v4l device driver.

Unfortunately, there does not seem to be any code handling
the v4l2 ioctls, so quite often the code goes through two
separate conversions, first from 32 bit v4l to 64 bit v4l,
and from there to 64 bit v4l2. My patch does not change
that, so there is still much room for improvement.

Also, some drivers have additional ioctl numbers, for
which the conversion should be handled internally to
that driver.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
      0d0fbf81
  41. 28 7月, 2005 1 次提交
  43. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4