09 Oct, 2005

1 commit

  • - added typedef unsigned int __nocast gfp_t;

    - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
    the same warnings as far as sparse is concerned, doesn't change
    generated code (from gcc point of view we replaced unsigned int with
    typedef) and documents what's going on far better.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

22 Sep, 2005

23 commits


30 Aug, 2005

3 commits

  • Lots of places just needs the states, not even linux/tcp.h, where this
    enum was, needs it.

    This speeds up development of the refactorings as less sources are
    rebuilt when things get moved from net/tcp.h.

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

    Arnaldo Carvalho de Melo
     
  • Bonding just wants the device before the skb_bond()
    decapsulation occurs, so simply pass that original
    device into packet_type->func() as an argument.

    It remains to be seen whether we can use this same
    exact thing to get rid of skb->input_dev as well.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Remove the "list" member of struct sk_buff, as it is entirely
    redundant. All SKB list removal callers know which list the
    SKB is on, so storing this in sk_buff does nothing other than
    taking up some space.

    Two tricky bits were SCTP, which I took care of, and two ATM
    drivers which Francois Romieu fixed
    up.

    Signed-off-by: David S. Miller
    Signed-off-by: Francois Romieu

    David S. Miller
     

09 Jul, 2005

1 commit

  • This is part of the grand scheme to eliminate the qlen
    member of skb_queue_head, and subsequently remove the
    'list' member of sk_buff.

    Most users of skb_queue_len() want to know if the queue is
    empty or not, and that's trivially done with skb_queue_empty()
    which doesn't use the skb_queue_head->qlen member and instead
    uses the queue list emptyness as the test.

    Signed-off-by: David S. Miller

    David S. Miller
     

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