1. 30 8月, 2005 2 次提交
    • A
      [INET]: Move bind_hash from tcp_sk to inet_sk · a55ebcc4
      Arnaldo Carvalho de Melo 提交于
      This should really be in a inet_connection_sock, but I'm leaving it
      for a later optimization, when some more fields common to INET
      transport protocols now in tcp_sk or inet_sk will be chunked out into
      inet_connection_sock, for now its better to concentrate on getting the
      changes in the core merged to leave the DCCP tree with only DCCP
      specific code.
      
      Next changesets will take advantage of this move to generalise things
      like tcp_bind_hash, tcp_put_port, tcp_inherit_port, making the later
      receive a inet_hashinfo parameter, and even __tcp_tw_hashdance, etc in
      the future, when tcp_tw_bucket gets transformed into the struct
      timewait_sock hierarchy.
      
      tcp_destroy_sock also is eligible as soon as tcp_orphan_count gets
      moved to sk_prot.
      
      A cascade of incremental changes will ultimately make the tcp_lookup
      functions be fully generic.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a55ebcc4
    • A
      [INET]: Introduce inet_sk_rebuild_header · 32519f11
      Arnaldo Carvalho de Melo 提交于
      From tcp_v4_rebuild_header, that already was pretty generic, I only
      needed to use sk->sk_protocol instead of the hardcoded IPPROTO_TCP and
      establish the requirement that INET transport layer protocols that
      want to use this function map TCP_SYN_SENT to its equivalent state.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32519f11
  2. 19 6月, 2005 2 次提交
    • A
      [NET] Rename open_request to request_sock · 60236fdd
      Arnaldo Carvalho de Melo 提交于
      Ok, this one just renames some stuff to have a better namespace and to
      dissassociate it from TCP:
      
      struct open_request  -> struct request_sock
      tcp_openreq_alloc    -> reqsk_alloc
      tcp_openreq_free     -> reqsk_free
      tcp_openreq_fastfree -> __reqsk_free
      
      With this most of the infrastructure closely resembles a struct
      sock methods subset.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60236fdd
    • A
      [NET] Generalise TCP's struct open_request minisock infrastructure · 2e6599cb
      Arnaldo Carvalho de Melo 提交于
      Kept this first changeset minimal, without changing existing names to
      ease peer review.
      
      Basicaly tcp_openreq_alloc now receives the or_calltable, that in turn
      has two new members:
      
      ->slab, that replaces tcp_openreq_cachep
      ->obj_size, to inform the size of the openreq descendant for
        a specific protocol
      
      The protocol specific fields in struct open_request were moved to a
      class hierarchy, with the things that are common to all connection
      oriented PF_INET protocols in struct inet_request_sock, the TCP ones
      in tcp_request_sock, that is an inet_request_sock, that is an
      open_request.
      
      I.e. this uses the same approach used for the struct sock class
      hierarchy, with sk_prot indicating if the protocol wants to use the
      open_request infrastructure by filling in sk_prot->rsk_prot with an
      or_calltable.
      
      Results? Performance is improved and TCP v4 now uses only 64 bytes per
      open request minisock, down from 96 without this patch :-)
      
      Next changeset will rename some of the structs, fields and functions
      mentioned above, struct or_calltable is way unclear, better name it
      struct request_sock_ops, s/struct open_request/struct request_sock/g,
      etc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e6599cb
  3. 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