)]}' { "log": [ { "commit": "725c25819e4a0dafdcf42a5f31bc569341919c7c", "tree": "cd2f3d763848dc550c19daf42f6146425aff058c", "parents": [ "3dd392a407d15250a501fa109cc1f93fee95ef85", "72d31053f62c4bc464c2783974926969614a8649", "129d6aba444d1e99d4cbfb9866a4652912426b65", "1e19b16a30c34c042f1eaa23db4c99bfad1dac0e" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Oct 10 19:47:12 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Oct 10 19:47:12 2008 +0200" }, "message": "Merge branches \u0027core/iommu\u0027, \u0027x86/amd-iommu\u0027 and \u0027x86/iommu\u0027 into x86-v28-for-linus-phase3-B\n\nConflicts:\n\tarch/x86/kernel/pci-gart_64.c\n\tinclude/asm-x86/dma-mapping.h\n" }, { "commit": "ed6dc4981368aa8ac89b0ea61535cfa2b03533cb", "tree": "8a8a787d6dac517ea0b928e1dc3f8d906add462a", "parents": [ "d26dbc5cf94b0a28acc947285c3b54814a73cb2e" ], "author": { "name": "FUJITA Tomonori", "email": "fujita.tomonori@lab.ntt.co.jp", "time": "Tue Sep 23 01:15:10 2008 +0900" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Sep 22 19:49:18 2008 +0200" }, "message": "x86: remove set_bit_string()\n\n\"export iommu_area_reserve helper funciton\" patch converted all the\nusers of set_bit_string, GART, Calgary and AMD IOMMU drivers, to use\niommu_area_reserve helper function. Now we can remove unused\nset_bit_string function.\n\nSigned-off-by: FUJITA Tomonori \u003cfujita.tomonori@lab.ntt.co.jp\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "77ef50a522717fa040636ee1017179ceba12ff62", "tree": "57b082ad5b314605d5d9dab50068737f324cae60", "parents": [ "a656c8efb40a8700046df20da2195f8aa39ce38a" ], "author": { "name": "Vegard Nossum", "email": "vegard.nossum@gmail.com", "time": "Wed Jun 18 17:08:48 2008 +0200" }, "committer": { "name": "Vegard Nossum", "email": "vegard.nossum@gmail.com", "time": "Tue Jul 22 21:31:34 2008 +0200" }, "message": "x86: consolidate header guards\n\nThis patch is the result of an automatic script that consolidates the\nformat of all the headers in include/asm-x86/.\n\nThe format:\n\n1. No leading underscore. Names with leading underscores are reserved.\n2. Pathname components are separated by two underscores. So we can\n distinguish between mm_types.h and mm/types.h.\n3. Everything except letters and numbers are turned into single\n underscores.\n\nSigned-off-by: Vegard Nossum \u003cvegard.nossum@gmail.com\u003e\n" }, { "commit": "8450e85399031a192ffb34f0f9ac981173db6a31", "tree": "98ac828f3bf850063221440ff91865cfa16857a1", "parents": [ "fbdb7da91b0382d4b148d8b43c2eb4bab642bb5b" ], "author": { "name": "Alexander van Heukelum", "email": "heukelum@mailshack.com", "time": "Sat Jul 05 19:53:46 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Jul 18 14:32:38 2008 +0200" }, "message": "x86, cleanup: fix description of __fls(): __fls(0) is undefined\n\nRicardo M. Correia spotted that the use of __fls() in fls64() did\nnot seem to make sense. In fact fls64()\u0027s implementation is fine,\nbut the description of __fls() was wrong. Fix that.\n\nReported-by: \"Ricardo M. Correia\" \u003cRicardo.M.Correia@Sun.COM\u003e\nSigned-off-by: Alexander van Heukelum \u003cheukelum@fastmail.fm\u003e\nCc: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nCc: Andi Kleen \u003candi@firstfloor.org\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "437a0a54eea7b101e8a5b70688009956f6522ed0", "tree": "a0a2b59e4fc40f01d8ad9b5702698f216e79ff49", "parents": [ "7dbceaf9bb68919651901b101f44edd5391ee489" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Jun 20 21:50:20 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Jun 21 07:57:24 2008 +0200" }, "message": "x86, bitops: make constant-bit set/clear_bit ops faster, gcc workaround\n\nJeremy Fitzhardinge reported this compiler bug:\n\nSuggestion from Linus: add \"r\" to the input constraint of the\nset_bit()/clear_bit()\u0027s constant \u0027nr\u0027 branch:\n\nBlows up on \"gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)\":\n\n CC init/main.o\ninclude2/asm/bitops.h: In function `start_kernel\u0027:\ninclude2/asm/bitops.h:59: warning: asm operand 1 probably doesn\u0027t match constraints\ninclude2/asm/bitops.h:59: warning: asm operand 1 probably doesn\u0027t match constraints\ninclude2/asm/bitops.h:59: warning: asm operand 1 probably doesn\u0027t match constraints\ninclude2/asm/bitops.h:59: error: impossible constraint in `asm\u0027\ninclude2/asm/bitops.h:59: error: impossible constraint in `asm\u0027\ninclude2/asm/bitops.h:59: error: impossible constraint in `asm\u0027\n\nReported-by: Jeremy Fitzhardinge \u003cjeremy@goop.org\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "7dbceaf9bb68919651901b101f44edd5391ee489", "tree": "1d9686536675d4d2307ffe2380af55ff023365b7", "parents": [ "1a750e0cd7a30c478723ecfa1df685efcdd38a90" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Jun 20 07:28:24 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Jun 20 08:08:49 2008 +0200" }, "message": "x86, bitops: make constant-bit set/clear_bit ops faster, adapt, clean up\n\nfix integration bug introduced by \"x86: bitops take an unsigned long *\"\nwhich turned \"(void *) + x\" into \"(long *) + x\".\n\nsmall cleanups to make it more apparent which value get propagated where.\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "1a750e0cd7a30c478723ecfa1df685efcdd38a90", "tree": "9c0326febfd0124cca3b35ebef9d5b4f85fbaeee", "parents": [ "5136dea5734cfddbc6d7ccb7ead85a3ac7ce3de2" ], "author": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Wed Jun 18 21:03:26 2008 -0700" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Thu Jun 19 13:45:51 2008 +0200" }, "message": "x86, bitops: make constant-bit set/clear_bit ops faster\n\nOn Wed, 18 Jun 2008, Linus Torvalds wrote:\n\u003e\n\u003e And yes, the \"lock andl\" should be noticeably faster than the xchgl.\n\nI dunno. Here\u0027s a untested (!!) patch that turns constant-bit\nset/clear_bit ops into byte mask ops (lock orb/andb).\n\nIt\u0027s not exactly pretty. The reason for using the byte versions is that a\nlocked op is serialized in the memory pipeline anyway, so there are no\nforwarding issues (that could slow down things when we access things with\ndifferent sizes), and the byte ops are a lot smaller than 32-bit and\nparticularly 64-bit ops (big constants, and the 64-bit ops need the REX\nprefix byte too).\n\n[ Side note: I wonder if we should turn the \"test_bit()\" C version into a\n \"char *\" version too.. It could actually help with alias analysis, since\n char pointers can alias anything. So it might be the RightThing(tm) to\n do for multiple reasons. I dunno. It\u0027s a separate issue. ]\n\nIt does actually shrink the kernel image a bit (a couple of hundred bytes\non the text segment for my everything-compiled-in image), and while it\u0027s\ntotally untested the (admittedly few) code generation points I looked at\nseemed sane. And \"lock orb\" should be noticeably faster than \"lock bts\".\n\nIf somebody wants to play with it, go wild. I didn\u0027t do \"change_bit()\",\nbecause nobody sane uses that thing anyway. I guarantee nothing. And if it\nbreaks, nobody saw me do anything. You can\u0027t prove this email wasn\u0027t sent\nby somebody who is good at forging smtp.\n\nThis does require a gcc that is recent enough for \"__builtin_constant_p()\"\nto work in an inline function, but I suspect our kernel requirements are\nalready higher than that. And if you do have an old gcc that is supported,\nthe worst that would happen is that the optimization doesn\u0027t trigger.\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "5136dea5734cfddbc6d7ccb7ead85a3ac7ce3de2", "tree": "f6fe41531da78f36c40130bc32cf33ca1e47ab87", "parents": [ "75d3bce2fc0a80f435fe12f2c9ed2632c8ac29e4" ], "author": { "name": "Andrew Morton", "email": "akpm@linux-foundation.org", "time": "Wed May 14 16:10:41 2008 -0700" }, "committer": { "name": "Thomas Gleixner", "email": "tglx@linutronix.de", "time": "Sun May 25 08:51:31 2008 +0200" }, "message": "x86: bitops take an unsigned long *\n\nAll (or most) other architectures do this. So should x86. Fix.\n\nCc: Andrea Arcangeli \u003candrea@qumranet.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n" }, { "commit": "eb2b4e682a6d5b4779a7f1a6a8419982919795f6", "tree": "0319972d5c5ccea9cb63ae0c2db49c39ec12bf18", "parents": [ "9096bd7a66efbe406910365c5206a32eed3875af" ], "author": { "name": "Simon Holm Thøgersen", "email": "odie@cs.aau.dk", "time": "Mon May 05 15:45:28 2008 +0200" }, "committer": { "name": "Thomas Gleixner", "email": "tglx@linutronix.de", "time": "Sat May 10 19:31:45 2008 +0200" }, "message": "x86: revert commit 709f744 (\"x86: bitops asm constraint fixes\")\n\n709f744 causes my computer to freeze during the start up of X and my\nlogin manger (GDM). It gets to the point where it has shown the default\nX mouse cursor logo (a big X / cross) and does not respond to anything\nfrom that point on.\n\nThis worked fine before 709f744, and it works fine with 709f744\nreverted on top of Linus\u0027 current tree (f74d505). The revert had\nconflicts, as far as I can tell due to white space changes. The diff I\nended up with is below.\n\nIt is 100% reproducible.\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n" }, { "commit": "f19dcf4a61ea4a3d155acb239348d09cb264f6a0", "tree": "52e06002f6f3402148247b361ea91257f5853888", "parents": [ "d66462f5314b0e70ddad8032eb76099475ca5571" ], "author": { "name": "Joe Perches", "email": "joe@perches.com", "time": "Sun Mar 23 01:03:07 2008 -0700" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Apr 26 19:21:17 2008 +0200" }, "message": "x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only\n\nSigned-off-by: Joe Perches \u003cjoe@perches.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "d66462f5314b0e70ddad8032eb76099475ca5571", "tree": "473d34bf2662fb008495764dda774e00d563f01a", "parents": [ "5245698f665c4b7a533dcc47a5afdf33095d436a" ], "author": { "name": "Alexander van Heukelum", "email": "heukelum@mailshack.com", "time": "Fri Apr 04 20:49:30 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Apr 26 19:21:17 2008 +0200" }, "message": "x86: finalize bitops unification\n\ninclude/asm-x86/bitops_32.h and include/asm-x86/bitops_64.h are now\nalmost identical. The 64-bit version sets ARCH_HAS_FAST_MULTIPLIER\nand has an extra inline function set_bit_string. The define currently\nhas no influence on the generated code, but it can be argued that\nsetting it on i386 is the right thing to do anyhow. The addition\nof the extra inline function on i386 does not hurt either.\n\nSigned-off-by: Alexander van Heukelum \u003cheukelum@fastmail.fm\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "12d9c8420b9daa1da3d9e090640fb24bcd0deba2", "tree": "60affb5bdc5b857dfb3969234659caedbf2ff02a", "parents": [ "64970b68d2b3ed32b964b0b30b1b98518fde388e" ], "author": { "name": "Alexander van Heukelum", "email": "heukelum@mailshack.com", "time": "Sat Mar 15 13:04:42 2008 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Apr 26 19:21:16 2008 +0200" }, "message": "x86: merge the simple bitops and move them to bitops.h\n\nSome of those can be written in such a way that the same\ninline assembly can be used to generate both 32 bit and\n64 bit code.\n\nFor ffs and fls, x86_64 unconditionally used the cmov\ninstruction and i386 unconditionally used a conditional\nbranch over a mov instruction. In the current patch I\nchose to select the version based on the availability\nof the cmov instruction instead. A small detail here is\nthat x86_64 did not previously set CONFIG_X86_CMOV\u003dy.\n\nImproved comments for ffs, ffz, fls and variations.\n\nSigned-off-by: Alexander van Heukelum \u003cheukelum@fastmail.fm\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "64970b68d2b3ed32b964b0b30b1b98518fde388e", "tree": "7d8eb5ea3ab1a841afa0f7ae1c65e7be4a9ca690", "parents": [ "60b6783a044a55273b637983f52965c2808a6b86" ], "author": { "name": "Alexander van Heukelum", "email": "heukelum@mailshack.com", "time": "Tue Mar 11 16:17:19 2008 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Apr 26 19:21:16 2008 +0200" }, "message": "x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps\n\nThis moves an optimization for searching constant-sized small\nbitmaps form x86_64-specific to generic code.\n\nOn an i386 defconfig (the x86#testing one), the size of vmlinux hardly\nchanges with this applied. I have observed only four places where this\noptimization avoids a call into find_next_bit:\n\nIn the functions return_unused_surplus_pages, alloc_fresh_huge_page,\nand adjust_pool_surplus, this patch avoids a call for a 1-bit bitmap.\nIn __next_cpu a call is avoided for a 32-bit bitmap. That\u0027s it.\n\nOn x86_64, 52 locations are optimized with a minimal increase in\ncode size:\n\nCurrent #testing defconfig:\n\t146 x bsf, 27 x find_next_*bit\n text data bss dec hex filename\n 5392637 846592 724424 6963653 6a41c5 vmlinux\n\nAfter removing the x86_64 specific optimization for find_next_*bit:\n\t94 x bsf, 79 x find_next_*bit\n text data bss dec hex filename\n 5392358 846592 724424 6963374 6a40ae vmlinux\n\nAfter this patch (making the optimization generic):\n\t146 x bsf, 27 x find_next_*bit\n text data bss dec hex filename\n 5392396 846592 724424 6963412 6a40d4 vmlinux\n\n[ tglx@linutronix.de: build fixes ]\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "6fd92b63d0626a8fe7eb8e2e50d19ecaa18cb412", "tree": "840f6cf998c251cdfcae37a03f34b34ac5bea3a5", "parents": [ "18e413f7193ed2f6991d959863f46330813aa242" ], "author": { "name": "Alexander van Heukelum", "email": "heukelum@mailshack.com", "time": "Sun Mar 09 21:01:04 2008 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sat Apr 26 19:21:16 2008 +0200" }, "message": "x86: change x86 to use generic find_next_bit\n\nThe versions with inline assembly are in fact slower on the machines I\ntested them on (in userspace) (Athlon XP 2800+, p4-like Xeon 2.8GHz, AMD\nOpteron 270). The i386-version needed a fix similar to 06024f21 to avoid\ncrashing the benchmark.\n\nBenchmark using: gcc -fomit-frame-pointer -Os. For each bitmap size\n1...512, for each possible bitmap with one bit set, for each possible\noffset: find the position of the first bit starting at offset. If you\nfollow ;). Times include setup of the bitmap and checking of the\nresults.\n\n\t\tAthlon\t\tXeon\t\tOpteron 32/64bit\nx86-specific:\t0m3.692s\t0m2.820s\t0m3.196s / 0m2.480s\ngeneric:\t0m2.622s\t0m1.662s\t0m2.100s / 0m1.572s\n\nIf the bitmap size is not a multiple of BITS_PER_LONG, and no set\n(cleared) bit is found, find_next_bit (find_next_zero_bit) returns a\nvalue outside of the range [0, size]. The generic version always returns\nexactly size. The generic version also uses unsigned long everywhere,\nwhile the x86 versions use a mishmash of int, unsigned (int), long and\nunsigned long.\n\nUsing the generic version does give a slightly bigger kernel, though.\n\ndefconfig:\t text data bss dec hex filename\nx86-specific:\t4738555 481232 626688 5846475 5935cb vmlinux (32 bit)\ngeneric:\t4738621 481232 626688 5846541 59360d vmlinux (32 bit)\nx86-specific:\t5392395 846568 724424 6963387 6a40bb vmlinux (64 bit)\ngeneric:\t5392458 846568 724424 6963450 6a40fa vmlinux (64 bit)\n\nSigned-off-by: Alexander van Heukelum \u003cheukelum@fastmail.fm\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "286275c90f148562b973b1e1f39f9689e6676dc4", "tree": "5d9800fba92a22095dfaebbb794346546e39ebaa", "parents": [ "49f74946f008add0b22723244976a32b365de06f" ], "author": { "name": "Joe Perches", "email": "joe@perches.com", "time": "Sun Mar 23 01:01:45 2008 -0700" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Thu Apr 17 17:41:22 2008 +0200" }, "message": "include/asm-x86/bitops.h: checkpatch cleanups - formatting only\n\nSigned-off-by: Joe Perches \u003cjoe@perches.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "709f744f18ebc3a810d29c8d5502bf20c3cecc70", "tree": "1a2da7360736cb00ec6cbdde68c15bfab505f869", "parents": [ "6e908947b4995bc0e551a8257c586d5c3e428201" ], "author": { "name": "Jan Beulich", "email": "jbeulich@novell.com", "time": "Thu Mar 13 09:08:51 2008 +0000" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Thu Apr 17 17:41:21 2008 +0200" }, "message": "x86: bitops asm constraint fixes\n\nThis (simplified) piece of code didn\u0027t behave as expected due to\nincorrect constraints in some of the bitops functions, when\nX86_FEATURE_xxx is referring to other than the first long:\n\nint test(struct cpuinfo_x86 *c) {\n\tif (cpu_has(c, X86_FEATURE_xxx))\n\t\tclear_cpu_cap(c, X86_FEATURE_xxx);\n\treturn cpu_has(c, X86_FEATURE_xxx);\n}\n\nI\u0027d really like understand, though, what the policy of (not) having a\n\"memory\" clobber in these operations is - currently, this appears to\nbe totally inconsistent. Also, many comments of the non-atomic\nfunctions say those may also be re-ordered - this contradicts the use\nof \"asm volatile\" in there, which again I\u0027d like to understand.\n\nAs much as all of these, using \u0027int\u0027 for the \u0027nr\u0027 parameter and\n\u0027void *\u0027 for the \u0027addr\u0027 one is in conflict with\nDocumentation/atomic_ops.txt, especially because bt{,c,r,s} indeed\ntake the bit index as signed (which hence would really need special\nprecaution) and access the full 32 bits (if \u0027unsigned long\u0027 was used\nproperly here, 64 bits for x86-64) pointed at, so invalid uses like\nreferencing a \u0027char\u0027 array cannot currently be caught.\n\nFinally, the code with and without this patch relies heavily on the\n-fno-strict-aliasing compiler switch and I\u0027m not certain this really\nis a good idea.\n\nIn the light of all of this I\u0027m sending this as RFC, as fixing the\nabove might warrant a much bigger patch...\n\nSigned-off-by: Jan Beulich \u003cjbeulich@novell.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "26996dd22b3cbc9dbe18cf908d2f844a116b6ec1", "tree": "5c85873869cd4e6f907b5f56da013742741bc434", "parents": [ "dbcb4660246c240a159b4037067fdedb563a63cb" ], "author": { "name": "Glauber de Oliveira Costa", "email": "gcosta@redhat.com", "time": "Wed Jan 30 13:31:31 2008 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Wed Jan 30 13:31:31 2008 +0100" }, "message": "x86: change bitwise operations to get a void parameter.\n\nThis patch changes the bitwise operations in bitops.h to get\na void pointers as a parameter. Before this patch, a lot of warnings\ncan be seen. They\u0027re gone after it.\n\nSigned-off-by: Glauber de Oliveira Costa \u003cgcosta@redhat.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n" }, { "commit": "1c54d77078056cde0f195b1a982cb681850efc08", "tree": "2acf18bdf1cd7ff38f79ea09dd75025aa6f60a65", "parents": [ "7bf0c23ed24b0d95a2a717f86dce1f210e16f8a5" ], "author": { "name": "Jeremy Fitzhardinge", "email": "jeremy@goop.org", "time": "Wed Jan 30 13:30:55 2008 +0100" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Wed Jan 30 13:30:55 2008 +0100" }, "message": "x86: partial unification of asm-x86/bitops.h\n\nThis unifies the set/clear/test bit functions of asm/bitops.h.\n\nI have not attempted to merge the bit-finding functions, since they\nrely on the machine word size and can\u0027t be easily restructured to work\ngenerically without a lot of #ifdefs. In particular, the 64-bit code\ncan assume the presence of conditional move instructions, whereas\n32-bit needs to be more careful.\n\nThe inline assembly for the bit operations has been changed to remove\nexplicit sizing hints on the instructions, so the assembler will pick\nthe appropriate instruction forms depending on the architecture and\nthe context.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nCc: Andi Kleen \u003cak@suse.de\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n" }, { "commit": "96a388de5dc53a8b234b3fd41f3ae2cedc9ffd42", "tree": "d947a467aa2da3140279617bc4b9b101640d7bf4", "parents": [ "27bd0c955648646abf2a353a8371d28c37bcd982" ], "author": { "name": "Thomas Gleixner", "email": "tglx@linutronix.de", "time": "Thu Oct 11 11:20:03 2007 +0200" }, "committer": { "name": "Thomas Gleixner", "email": "tglx@linutronix.de", "time": "Thu Oct 11 11:20:03 2007 +0200" }, "message": "i386/x86_64: move headers to include/asm-x86\n\nMove the headers to include/asm-x86 and fixup the\nheader install make rules\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" } ] }