summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2005-05-01[PATCH] DocBook: changes and extensions to the kernel documentationPavel Pisa1-0/+2
I have recompiled Linux kernel 2.6.11.5 documentation for me and our university students again. The documentation could be extended for more sources which are equipped by structured comments for recent 2.6 kernels. I have tried to proceed with that task. I have done that more times from 2.6.0 time and it gets boring to do same changes again and again. Linux kernel compiles after changes for i386 and ARM targets. I have added references to some more files into kernel-api book, I have added some section names as well. So please, check that changes do not break something and that categories are not too much skewed. I have changed kernel-doc to accept "fastcall" and "asmlinkage" words reserved by kernel convention. Most of the other changes are modifications in the comments to make kernel-doc happy, accept some parameters description and do not bail out on errors. Changed <pid> to @pid in the description, moved some #ifdef before comments to correct function to comments bindings, etc. You can see result of the modified documentation build at http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz Some more sources are ready to be included into kernel-doc generated documentation. Sources has been added into kernel-api for now. Some more section names added and probably some more chaos introduced as result of quick cleanup work. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] kallsyms C_SYMBOL_PREFIX supportYoshinori Sato1-20/+56
kallsyms does not consider SYMBOL_PREFIX of C. Consequently it does not work on architectures using that prefix character (h8300, v850). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-22[PATCH] USB: scripts/mod/file2alias.c: handle numeric ranges for USB bcdDeviceRoman Kagan1-23/+88
Another attempt at that... The attached patch fixes the longstanding problem with USB bcdDevice numeric ranges incorrectly converted into patterns for MODULE_ALIAS generation. Previously it put both the lower and the upper limits into the pattern, dlXdhY, making it impossible to fnmatch against except for a few special cases, like dl*dh* or dlXdhX. The patch makes it generate multiple MODULE_ALIAS lines covering the whole range with fnmatch-able patterns. E.g. for a range between 0x0001 and 0x8345 it gives the following patterns: 000[1-9] 00[1-9]* 0[1-9]* [1-7]* 8[0-2]* 83[0-3]* 834[0-5] Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the max no. of patters is 2 * 4 - 1 = 7. The values are BCD (binary-coded decimals) and not hex, so patterns using a dash seem to be safe regardless of locale collation order. The patch changes bcdDevice part of the alias from dlXdhY to dZ, but this shouldn't have big compatibility issues because fnmatch()-based modprobing hasn't yet been widely used. Besides, the most common (and almost the only working) case of dl*dh* becomes d* and thus continues to work. The patch is against 2.6.12-rc2, applies to -mm3 with an offset. The matching patch to fix the MODALIAS environment variable now generated by the usb hotplug function follows. Signed-off-by: Roman Kagan <rkagan@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18[PATCH] 2.6.12-rc1-mm3 Fix ver_linux script for no udev utils.Steven Cole1-1/+1
Without the attached patch, the ver_linux script gives the following if udev utils are not present. ./scripts/ver_linux: line 90: udevinfo: command not found The patch causes ver_linux to be silent in the case of no udevinfo command. Signed-off-by: Steven Cole <elenstev@mesatop.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds94-0/+34478
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!