> You should consider bringing the kernel module up to kernel codingI'm certainly interested in bringing the code up to kernel coding standards (for example, I'd be happy to address any issues with the code that are brought to my attention). I'm not sure whether submitting it for mainline makes sense since the software doesn't significantly benefit from being bundled with the kernel. Instead, it might be more important to 1) package the userspace update-construction software for common Linux distributions to make it easily available to interested users, and 2) to provide binary kernel updates for common distribution kernels so that users can simply sign up and get fewer "your machine needs to be rebooted now for an update to take effect" notifications. I'm open to suggestions about how I should proceed, however. I've considered modifying the system for use in other contexts, but I don't think that I'll get around to such a project anytime soon; my current focus is on making it easier for people to perform rebootless kernel security updates. Jeff Arnold jbarnold@mit.edu --
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
