1. 26 3月, 2013 1 次提交
  2. 20 2月, 2013 1 次提交
  3. 12 2月, 2013 1 次提交
  4. 18 12月, 2012 1 次提交
    • A
      random32: rename random32 to prandom · 496f2f93
      Akinobu Mita 提交于
      This renames all random32 functions to have 'prandom_' prefix as follows:
      
        void prandom_seed(u32 seed);	/* rename from srandom32() */
        u32 prandom_u32(void);		/* rename from random32() */
        void prandom_seed_state(struct rnd_state *state, u64 seed);
        				/* rename from prandom32_seed() */
        u32 prandom_u32_state(struct rnd_state *state);
        				/* rename from prandom32() */
      
      The purpose of this renaming is to prevent some kernel developers from
      assuming that prandom32() and random32() might imply that only
      prandom32() was the one using a pseudo-random number generator by
      prandom32's "p", and the result may be a very embarassing security
      exposure.  This concern was expressed by Theodore Ts'o.
      
      And furthermore, I'm going to introduce new functions for getting the
      requested number of pseudo-random bytes.  If I continue to use both
      prandom32 and random32 prefixes for these functions, the confusion
      is getting worse.
      
      As a result of this renaming, "prandom_" is the common prefix for
      pseudo-random number library.
      
      Currently, srandom32() and random32() are preserved because it is
      difficult to rename too many users at once.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Robert Love <robert.w.love@intel.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: David Laight <david.laight@aculab.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      496f2f93
  5. 15 12月, 2012 1 次提交
    • R
      fcoe: Use the fcoe_sysfs control interface · 435c8667
      Robert Love 提交于
      This patch adds support for the new fcoe_sysfs
      control interface to fcoe.ko. It keeps the deprecated
      interface in tact and therefore either the legacy
      or the new control interfaces can be used. A mixed mode
      is not supported. A user must either use the new
      interfaces or the old ones, but not both.
      
      The fcoe_ctlr's link state is now driven by both the
      netdev link state as well as the fcoe_ctlr_device's
      enabled attribute. The link must be up and the
      fcoe_ctlr_device must be enabled before the FCoE
      Controller starts discovery or login.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      435c8667
  6. 20 7月, 2012 1 次提交
  7. 23 5月, 2012 1 次提交
    • R
      [SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs · 8d55e507
      Robert Love 提交于
      This patch has the SW FCoE driver and the bnx2fc
      driver make use of the new fcoe_sysfs API added
      earlier in this patch series.
      
      After this patch a fcoe_ctlr_device is allocated with
      private data in this order.
      
      +------------------+   +------------------+
      | fcoe_ctlr_device |   | fcoe_ctlr_device |
      +------------------+   +------------------+
      | fcoe_ctlr        |   | fcoe_ctlr        |
      +------------------+   +------------------+
      | fcoe_interface   |   | bnx2fc_interface |
      +------------------+   +------------------+
      
      libfcoe also takes part in this new model since it
      discovers and manages fcoe_fcf instances. The memory
      allocation is different for FCFs. I didn't want to
      impact libfcoe's fcoe_fcf processing, so this patch
      creates fcoe_fcf_device instances for each discovered
      fcoe_fcf. The two are paired using a (void * priv)
      member of the fcoe_ctlr_device. This allows libfcoe
      to continue maintaining its list of fcoe_fcf instances
      and simply attaches and detaches them from existing
      or new fcoe_fcf_device instances.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      8d55e507
  8. 10 5月, 2012 1 次提交
  9. 28 3月, 2012 2 次提交
  10. 15 12月, 2011 1 次提交
  11. 25 5月, 2011 1 次提交
  12. 01 5月, 2011 1 次提交
  13. 31 3月, 2011 1 次提交
  14. 13 2月, 2011 3 次提交
  15. 22 12月, 2010 8 次提交
  16. 26 10月, 2010 1 次提交
  17. 28 7月, 2010 14 次提交