1. 21 9月, 2006 5 次提交
  2. 10 1月, 2006 1 次提交
    • H
      [CRYPTO] Allow multiple implementations of the same algorithm · 5cb1454b
      Herbert Xu 提交于
      This is the first step on the road towards asynchronous support in
      the Crypto API.  It adds support for having multiple crypto_alg objects
      for the same algorithm registered in the system.
      
      For example, each device driver would register a crypto_alg object
      for each algorithm that it supports.  While at the same time the
      user may load software implementations of those same algorithms.
      
      Users of the Crypto API may then select a specific implementation
      by name, or choose any implementation for a given algorithm with
      the highest priority.
      
      The priority field is a 32-bit signed integer.  In future it will be
      possible to modify it from user-space.
      
      This also provides a solution to the problem of selecting amongst
      various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5cb1454b
  3. 02 9月, 2005 1 次提交
    • H
      [CRYPTO]: Added CRYPTO_TFM_REQ_MAY_SLEEP flag · 64baf3cf
      Herbert Xu 提交于
      The crypto layer currently uses in_atomic() to determine whether it is
      allowed to sleep.  This is incorrect since spin locks don't always cause
      in_atomic() to return true.
      
      Instead of that, this patch returns to an earlier idea of a per-tfm flag
      which determines whether sleeping is allowed.  Unlike the earlier version,
      the default is to not allow sleeping.  This ensures that no existing code
      can break.
      
      As usual, this flag may either be set through crypto_alloc_tfm(), or
      just before a specific crypto operation.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64baf3cf
  4. 15 7月, 2005 1 次提交
  5. 07 7月, 2005 3 次提交
  6. 24 5月, 2005 1 次提交
    • H
      [CRYPTO]: Only reschedule if !in_atomic() · 15333038
      Herbert Xu 提交于
      The netlink gfp_any() problem made me double-check the uses of in_softirq()
      in crypto/*.  It seems to me that we should be checking in_atomic() instead
      of in_softirq() in crypto_yield.  Otherwise people calling the crypto ops
      with spin locks held or preemption disabled will get burnt, right?
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15333038
  7. 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