11 Oct, 2007

1 commit

  • It's been a useless no-op for long enough in 2.6 so I figured it's time to
    remove it. The number of people that could object because they're
    maintaining unified 2.4 and 2.6 drivers is probably rather small.

    [ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]

    Signed-off-by: Ralf Baechle
    Signed-off-by: Jeff Garzik
    Signed-off-by: David S. Miller

    Ralf Baechle
     

26 Jul, 2007

1 commit

  • This avoids use of the kernel-internal "xtime" variable directly outside
    of the actual time-related functions. Instead, use the helper functions
    that we already have available to us.

    This doesn't actually change any behaviour, but this will allow us to
    fix the fact that "xtime" isn't updated very often with CONFIG_NO_HZ
    (because much of the realtime information is maintained as separate
    offsets to 'xtime'), which has caused interfaces that use xtime directly
    to get a time that is out of sync with the real-time clock by up to a
    third of a second or so.

    Signed-off-by: John Stultz
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Linus Torvalds

    john stultz
     

21 Jun, 2007

3 commits


08 May, 2007

1 commit


26 Apr, 2007

3 commits

  • To clearly state the intent of copying from linear sk_buffs, _offset being a
    overly long variant but interesting for the sake of saving some bytes.

    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     
  • So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes
    on 64bit architectures, allowing us to combine the 4 bytes hole left by the
    layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
    64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
    :-)

    Many calculations that previously required that skb->{transport,network,
    mac}_header be first converted to a pointer now can be done directly, being
    meaningful as offsets or pointers.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • For the common, open coded 'skb->mac.raw = skb->data' operation, so that we can
    later turn skb->mac.raw into a offset, reducing the size of struct sk_buff in
    64bit land while possibly keeping it as a pointer on 32bit.

    This one touches just the most simple case, next will handle the slightly more
    "complex" cases.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

15 Feb, 2007

1 commit

  • 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: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

09 Feb, 2007

1 commit


06 Feb, 2007

1 commit


17 Sep, 2006

1 commit

  • [PATCH 2/9] s390: netiucv driver fixes

    From: Frank Pavlic
    - missing lock initialization added
    - avoid duplicate iucv-interfaces to the same peer
    - rw-lock added for manipulating the list of
    defined iucv connections

    Signed-off-by: Frank Pavlic
    Signed-off-by: Jeff Garzik

    Frank Pavlic
     

11 Jul, 2006

1 commit


27 May, 2006

1 commit


24 Mar, 2006

1 commit


02 Feb, 2006

1 commit

  • - Remove all CVS generated information like e.g. revision IDs from
    drivers/s390 and include/asm-s390 (none present in arch/s390).

    - Add newline at end of arch/s390/lib/Makefile to avoid diff message.

    Acked-by: Andreas Herrmann
    Acked-by: Frank Pavlic
    Signed-off-by: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

15 Jan, 2006

1 commit


26 Jun, 2005

1 commit

  • This patch changes the memory allocation method for the s390 debug feature.
    Trace buffers had been allocated using the get_free_pages() function before.
    Therefore it was not possible to get big memory areas in a running system due
    to memory fragmentation. Now the trace buffers are subdivided into several
    subbuffers with pagesize. Therefore it is now possible to allocate more
    memory for the trace buffers and more trace records can be written.

    In addition to that, dynamic specification of the size of the trace buffers is
    implemented. It is now possible to change the size of a trace buffer using a
    new debugfs file instance. When writing a number into this file, the trace
    buffer size is changed to 'number * pagesize'.

    In the past all the traces could be obtained from userspace by accessing files
    in the "proc" filesystem. Now with debugfs we have a new filesystem which
    should be used for debugging purposes. This patch moves the debug feature
    from procfs to debugfs.

    Since the interface of debug_register() changed, all device drivers, which use
    the debug feature had to be adjusted.

    Signed-off-by: Martin Schwidefsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Holzheu
     

21 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds