27 Oct, 2010

1 commit

  • When calling syscall service routines in kernel, some of arguments should
    be user pointers but were missing __user markup on string literals. Add
    it. Removes some sparse warnings.

    Signed-off-by: Namhyung Kim
    Cc: Phillip Lougher
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Namhyung Kim
     

31 Mar, 2009

2 commits


22 Feb, 2009

1 commit


07 Jan, 2009

1 commit

  • The function autodetect_raid is only used by __init functions, and it refers
    to __initdata, so it needs __init markings. Fixes this error:
    The function autodetect_raid() references
    the variable __initdata raid_noautodetect.
    This is often because autodetect_raid lacks a __initdata
    annotation or the annotation of raid_noautodetect is wrong.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     

02 Nov, 2008

1 commit

  • Removed duplicated #include in init/do_mounts_md.c.

    The same compile error ("error: implicit declaration of function
    'msleep'") got fixed twice:

    - f8b77d39397e1510b1a3bcfd385ebd1a45aae77f ("init/do_mounts_md.c:
    msleep compile fix")

    - 73b4a24f5ff09389ba6277c53a266b142f655ed2 ("init/do_mounts_md.c must
    #include ")

    by people adding the include in two slightly different
    places. Andrew's quilt scripts happily ignore the fuzz, and will
    re-apply the patch even though they had conflicts.

    Signed-off-by: Huang Weiyi
    Signed-off-by: Linus Torvalds

    Huang Weiyi
     

31 Oct, 2008

1 commit


17 Oct, 2008

1 commit

  • This patch fixes the following compile error caused by commit
    589f800bb12c5cd6c9167bbf9bf3cb70cd8e422c ("fastboot: make the raid
    autodetect code wait for all devices to init"):

    CC init/do_mounts_md.o
    init/do_mounts_md.c: In function 'autodetect_raid':
    init/do_mounts_md.c:285: error: implicit declaration of function 'msleep'
    make[2]: *** [init/do_mounts_md.o] Error 1

    Signed-off-by: Adrian Bunk
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

12 Oct, 2008

4 commits

  • RAID autodetect has the side effect of requiring synchronisation
    of all device drivers, which can make the boot several seconds longer
    (I've measured 7 on one of my laptops).... even for systems that don't
    have RAID setup for the root filesystem (the only FS where this matters).

    This patch makes the default for autodetect a config option; either way
    the user can always override via the kernel command line.

    Signed-off-by: Arjan van de Ven
    Acked-by: NeilBrown

    Arjan van de Ven
     
  • fix warning:

    init/do_mounts_md.c: In function ‘md_run_setup’:
    init/do_mounts_md.c:282: warning: ISO C90 forbids mixed declarations and code

    also, use the opportunity to put the RAID autodetection code
    into a separate function - this also solves a checkpatch style warning.

    No code changed:

    md5:
    aa36a35faef371b05f1974ad583bdbbd do_mounts_md.o.before.asm
    aa36a35faef371b05f1974ad583bdbbd do_mounts_md.o.after.asm

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • As requested/suggested by Neil Brown: make the raid code print that it's
    about to wait for probing to be done as well as give a suggestion on how
    to disable the probing if the user doesn't use raid.

    Signed-off-by: Arjan van de Ven <arjan@linux.intel.com

    Arjan van de Ven
     
  • The raid autodetect code really needs to have all devices probed before
    it can detect raid arrays; not doing so would give rather messy situations
    where arrays would get detected as degraded while they shouldn't be etc.

    This is in preparation of removing the "wait for everything to init"
    code that makes everyone pay, not just raid users.

    Signed-off-by: Arjan van de Ven

    Arjan van de Ven
     

25 May, 2008

1 commit


29 Apr, 2008

1 commit


03 Oct, 2006

1 commit

  • Once upon a time we needed to fixed limit to the number of md devices,
    probably because we preallocated some array. This need no longer exists, but
    we still have an arbitrary limit.

    So remove MAX_MD_DEVS and allow as many devices as we can fit into the 'minor'
    part of a device number.

    Also remove some useless noise at init time (which reports MAX_MD_DEVS) and
    remove MD_THREAD_NAME_MAX which hasn't been used for a while.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

27 Jun, 2006

1 commit


07 Jan, 2006

1 commit

  • md supports multiple different RAID level, each being implemented by a
    'personality' (which is often in a separate module).

    These personalities have fairly artificial 'numbers'. The numbers
    are use to:
    1- provide an index into an array where the various personalities
    are recorded
    2- identify the module (via an alias) which implements are particular
    personality.

    Neither of these uses really justify the existence of personality numbers.
    The array can be replaced by a linked list which is searched (array lookup
    only happens very rarely). Module identification can be done using an alias
    based on level rather than 'personality' number.

    The current 'raid5' modules support two level (4 and 5) but only one
    personality. This slight awkwardness (which was handled in the mapping from
    level to personality) can be better handled by allowing raid5 to register 2
    personalities.

    With this change in place, the core md module does not need to have an
    exhaustive list of all possible personalities, so other personalities can be
    added independently.

    This patch also moves the check for chunksize being non-zero into the ->run
    routines for the personalities that need it, rather than having it in core-md.
    This has a side effect of allowing 'faulty' and 'linear' not to have a
    chunk-size set.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

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