[module/patch] optional /proc/patches ??
Ville Herva
> All,
>
> I was wondering whether something like a /proc/patches might be useful. This
> could help list patches applied to a kernel such that "uname -a" and "cat
> /proc/patches" provides some good information about the kernel, especially
> stock kernels from distributions. I was able to work up a quick module
> available at the link below. NOTE: I couldn't solve how to add entries fo a
> patchlist structure using regular context diffs, but ed diffs work just
> great. More information in the README attached. I'd very much appreciate any
> feedback on whether this is useful and how it should actually be implemented,
> if at all. Please note that my only access to lkml traffic is via Kernel
> Traffic so I would appreciate being Cc'ed.
This is nice. (It's an idea I've had for sometime, but I've never gotten
around to do anything about it.)
Random notes:
o Perhaps an URL field for each patch would be nice?
o Below is a patch to make it build on (at least newer) 2.2.
I'm a complete newbie here, I should have a look why it doesn't work on
2.2.16 but does on 2.2.21pre2. Also, what is the correct define for
MODULE_LICENSE?
o I'm not sure if it's nicer to have the fields separated with ':' or
pretty printed (some thing like this:
Foo-patch
Version: 0.0.1alpha3
Author: John Doe
URL: http://bfebbd.org
Bar-patch
Version: 0.021alpha3
Author: John Boe
URL: http://afebbd.org
). It is useful anyway.
o I think you may overflow the buffer if fields are too long. Also,
it doesn't work if the patch list is larger than a page (think of redhat
, -ac or -aa kernels...)
o I always thought about adding for example /usr/src/linux/PATCHES text file
that the /proc/patch would then include. I'm not sure it matters, though.
o Have you looked at proconfig: http://www.it.uc3m.es/~ptb/proconfig/
(There are other implementations of that idea, see the recent thread on
linux-kernel http://groups.google.com/groups?hl=en&threadm=20020207203451.GE26826%40bluemug.com&rnum=2&prev=/groups%3Fq%3DHow%2Bto%2Bcheck%2Bthe%2Bkernel%2Bcompile%2Boptions%2B%253F%2Blinux-kernel%26hl%3Den)
Now the only problem is to advogate people to actually use this ;). I'd be
nice to have for example O(1) scheduler or low-latency insert the info line
there.
-- v --
--- ../../patchlist-0.0.1/patchlist.c Mon Mar 11 22:09:29 2002
+++ patchlist.c Tue Mar 12 13:24:46 2002
@@ -45,7 +45,9 @@
MODULE_AUTHOR("Erik M. A. Kline");
MODULE_DESCRIPTION("implements /proc/patches read-only informational file");
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29) // fix me! 2.3.29 is not right even newer 2.2.x support this?
MODULE_LICENSE("GPL");
+#endif
EXPORT_NO_SYMBOLS;
@@ -68,8 +70,13 @@
};
-int patch_proc_read( char *buf, char **start, off_t offset,
+static int
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
+patch_proc_read( char *buf, char **start, off_t offset,
int count, int *eof, void *data )
+#else
+patch_proc_read( char *buf, char **start, off_t offset, int count, int unused )
+#endif
{
int i, len = 0, limit = count - 80;
struct patch_list_elem *pelem = NULL;
@@ -86,15 +93,46 @@
pelem->vers, pelem->authors );
}
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
*eof = 1;
+#endif
return len;
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,29)
+struct proc_dir_entry proc_root_patch =
+{
+ 0, sizeof(PATCH_PROCPATH) - 1, PATCH_PROCPATH,
+ S_IFREG | S_IRUGO,
+ 1, // LNK, DIR or FIL ?
+ 0, 0, // uid, gid
+ 0, // size
+ NULL, // inode ops
+ &patch_proc_read, // get_info
+ NULL, // fill_inode
+ NULL, // next entry
+ NULL, // parent entry
+ NULL, // subdir entry
+ NULL, // void *data
+ NULL, // read_proc
+ NULL, // write_proc
+ NULL, // readlink_proc
+ 0, // usage count
+ 0, // delete flag
+};
+#endif
+
+
int patch_module_init(void)
{
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
if ( create_proc_read_entry( PATCH_PROCPATH,
0, NULL, patch_proc_read, NULL ) == NULL )
return -ERESTARTSYS;
+#else
+ if ( proc_register (&proc_root, &proc_root_patch) < 0)
+ return -ERESTARTSYS;
+#endif
return 0;
}
@@ -103,7 +141,11 @@
void patch_module_exit(void)
{
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
remove_proc_entry( PATCH_PROCPATH, NULL );
+#else
+ proc_unregister (&proc_root, proc_root_patch.low_ino);
+#endif
}
module_exit( patch_module_exit );
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Oleszkiewicz
which i might be able to find if you'd like. I took a different
approach:
Have a script wrap around the patch command to just generate a log file
of the patches that wre applied. (eg linux/patchlog.txt)
Then on kernel build, when we build the whole include/config hierarchy
you can have a script or program take that log and create a header file
out of it. The header file creates a data structure similar to your
struct patch_list_elem patchlist[]. That way, when you are patching the
kernel you aren't dynamically patching some data structure file somewhere.
I found using th md5 checksum of the file to be useful. Your module code
can then take that header file and export it's information via /proc.
I found this useful for a little while, but realized that setting the
EXTRAVERSION variable in the main Makefile was good enough for me. This
could be more useful in an enterprise environment though, when service
people sweep in to debunk a kernel they can easily see what patches were
applied, even if the kernel source was hidden by a sneaky sys admin who
wants to get his money's worth on his service contract by making things
difficult. :>.
> All,
>
> I was wondering whether something like a /proc/patches might be useful.
> This could help list patches applied to a kernel such that "uname -a" and "cat
> /proc/patches" provides some good information about the kernel,
> especially stock kernels from distributions. I was able to work up a quick module
> available at the link below. NOTE: I couldn't solve how to add entries
> fo a patchlist structure using regular context diffs, but ed diffs work
> just great. More information in the README attached. I'd very much appreciate
> any feedback on whether this is useful and how it should actually be
> implemented, if at all. Please note that my only access to lkml traffic is via Kernel
> Traffic so I would appreciate being Cc'ed.
>
> Thanks all,
>
> -Erik (humble linux aficionado)
>
> [patchlist module]
> http://ekline.com/linux/patchlist-0.0.1.tar.gz