03 May, 2011

1 commit


17 Mar, 2011

1 commit

  • While changing our build system over to use the headers_install target
    as part of our klibc build, the following message started showing up in
    our logs:

    make[2]: `scripts/unifdef' is up to date.

    It turns out that the build blindly invokes a recursive make on this
    target, which causes make to emit this message when the target is
    already up to date. This isn't seen for most targets as the rest of the
    build relies primarily on the default target and on PHONY targets when
    invoking make recursively.

    Silence the above message when building unifdef as part of
    headers_install by hiding it behind a new PHONY target called
    "build_unifdef" that has an empty recipe.

    Signed-off-by: Mike Waychison
    Acked-by: WANG Cong
    Signed-off-by: Michal Marek

    Mike Waychison
     

15 Oct, 2010

1 commit

  • This patch adds the support for the C version of recordmcount and
    compile times show ~ 12% improvement.

    After verifying this works, other archs can add:

    HAVE_C_MCOUNT_RECORD

    in its Kconfig and it will use the C version of recordmcount
    instead of the perl version.

    Cc:
    Cc: Michal Marek
    Cc: linux-kbuild@vger.kernel.org
    Cc: John Reiser
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

16 Sep, 2009

1 commit

  • Many years ago when this driver was written, it had a use, but these
    days it's nothing but trouble and distributions should not enable it
    in any situation.

    Pretty much every console device a sparc machine could see has a
    bonafide real driver, making the PROM console hack unnecessary.

    If any new device shows up, we should write a driver instead of
    depending upon this crutch to save us. We've been able to take care
    of this even when no chip documentation exists (sunxvr500, sunxvr2500)
    so there are no excuses.

    Signed-off-by: David S. Miller

    David S. Miller
     

03 May, 2009

1 commit

  • The powerpc kernel always requires an Open Firmware like device tree
    to supply device information. On systems without OF, this comes from
    a flattened device tree blob. This blob is usually generated by dtc,
    a tool which compiles a text description of the device tree into the
    flattened format used by the kernel. Sometimes, the bootwrapper makes
    small changes to the pre-compiled device tree blob (e.g. filling in
    the size of RAM). To do this it uses the libfdt library.

    Because these are only used on powerpc, the code for both these tools
    is included under arch/powerpc/boot (these were imported and are
    periodically updated from the upstream dtc tree).

    However, the microblaze architecture, currently being prepared for
    merging to mainline also uses dtc to produce device tree blobs. A few
    other archs have also mentioned some interest in using dtc.
    Therefore, this patch moves dtc and libfdt from arch/powerpc into
    scripts, where it can be used by any architecture.

    The vast bulk of this patch is a literal move, the rest is adjusting
    the various Makefiles to use dtc and libfdt correctly from their new
    locations.

    Signed-off-by: David Gibson
    Signed-off-by: Linus Torvalds

    David Gibson
     

07 Apr, 2009

1 commit

  • This reverts commit 8b249b6856f16f09b0e5b79ce5f4d435e439b9d6.

    This 'fix' is not necessary; we just need to undo the damage caused
    accidentally by Igor/Mauro in 4b29631db33292d416dc395c56122ea865e7635c
    ("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")

    Signed-off-by: David Woodhouse

    David Woodhouse
     

08 Jan, 2009

1 commit

  • Rafael reported:

    I get the following error from 'make modules_install' on my test boxes:

    HOSTCC firmware/ihex2fw
    /home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
    compilation terminated.
    make[3]: *** [firmware/ihex2fw] Error 1
    make[2]: *** [_modinst_post] Error 2
    make[1]: *** [sub-make] Error 2
    make: *** [all] Error 2

    where the configuration is that the kernel is compiled on a build box
    with 'make O= -j5' and then is mounted over NFS read-only by
    each test box (full path to this directory is the same on the build box and on
    the test boxes). Then, I cd into , run 'make modules_install' and get
    the error above.

    The issue turns out to be that we when we install firmware pick
    up the list of firmware blobs from firmware/Makefile.
    And this triggers the Makefile rules to update ihex2fw.

    There were two solutions for this issue:
    1) Move the list of firmware blobs to a separate file
    2) Avoid ihex2fw rebuild by moving it to scripts

    As I seriously beleive that the list of firmware blobs should be
    done in a fundamental different way solution 2) was selected.

    Reported-and-tested-by: "Rafael J. Wysocki"
    Signed-off-by: Sam Ravnborg
    Cc: David Woodhouse

    Sam Ravnborg
     

27 Aug, 2008

1 commit

  • In August 2006 I posted a patch generating a minimal SELinux policy. This
    week, David P. Quigley posted an updated version of that as a patch against
    the kernel. It also had nice logic for auto-installing the policy.

    Following is David's original patch intro (preserved especially
    bc it has stats on the generated policies):

    se interested in the changes there were only two significant
    changes. The first is that the iteration through the list of classes
    used NULL as a sentinel value. The problem with this is that the
    class_to_string array actually has NULL entries in its table as place
    holders for the user space object classes.

    The second change was that it would seem at some point the initial sids
    table was NULL terminated. This is no longer the case so that iteration
    has to be done on array length instead of looking for NULL.

    Some statistics on the policy that it generates:

    The policy consists of 523 lines which contain no blank lines. Of those
    523 lines 453 of them are class, permission, and initial sid
    definitions. These lines are usually little to no concern to the policy
    developer since they will not be adding object classes or permissions.
    Of the remaining 70 lines there is one type, one role, and one user
    statement. The remaining lines are broken into three portions. The first
    group are TE allow rules which make up 29 of the remaining lines, the
    second is assignment of labels to the initial sids which consist of 27
    lines, and file system labeling statements which are the remaining 11.

    In addition to the policy.conf generated there is a single file_contexts
    file containing two lines which labels the entire system with base_t.

    This policy generates a policy.23 binary that is 7920 bytes.

    (then a few versions later...):

    The new policy is 587 lines (stripped of blank lines) with 476 of those
    lines being the boilerplate that I mentioned last time. The remaining
    111 lines have the 3 lines for type, user, and role, 70 lines for the
    allow rules (one for each object class including user space object
    classes), 27 lines to assign types to the initial sids, and 11 lines for
    file system labeling. The policy binary is 9194 bytes.

    Changelog:

    Aug 26: Added Documentation/SELinux.txt
    Aug 26: Incorporated a set of comments by Stephen Smalley:
    1. auto-setup SELINUXTYPE=dummy
    2. don't auto-install if selinux is enabled with
    non-dummy policy
    3. don't re-compute policy version
    4. /sbin/setfiles not /usr/sbin/setfiles
    Aug 22: As per JMorris comments, made sure make distclean
    cleans up the mdp directory.
    Removed a check for file_contexts which is now
    created in the same file as the check, making it
    superfluous.

    Signed-off-by: Serge Hallyn
    Signed-off-by: David Quigley
    Signed-off-by: James Morris

    Serge E. Hallyn
     

01 Oct, 2006

1 commit

  • The driver for /proc/config.gz consumes rather a lot of memory and it is in
    fact possible to build it as a module.

    In some ways this is a bit risky, because the .config which is used for
    compiling kernel/configs.c isn't necessarily the same as the .config which was
    used to build vmlinux.

    But OTOH the potential memory savings are decent, and it'd be fairly dumb to
    build your configs.o with a different .config.

    Signed-off-by: Andrew Morton
    Cc: "Randy.Dunlap"
    Cc: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ross Biro
     

25 Sep, 2006

2 commits


17 Dec, 2005

1 commit


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