On Mon, 19 May 2003 03:06, Manoj Srivastava wrote: > When I first envisaged the kernel source and kernel-patch > system, I always figured there should be a single source package per > version -- the one you get from kernel.org. *EVERY* arch, including > i386, should provided a kernel-patch package with all the changes for > their arch based on the pristine kernel source.
Definately. This should be done if only to avoid multiple copies of a 27M bzip2 archive wasting everyone's disk space and network bandwidth. Also regarding the i386 arch, multiple patches would be good. Something in the i386 patch gives me lots of 'D' state processes, if the patch was separated into a few smaller patches then it would be easier to track down the cause. > There is also a mechanism to order the order in which > kernel-patches are applied -- so if, say, a m68k kernel image > maintainer wanted to create a patch relative to the i386 patches, > they could depend on that patch, and order the m68k kernel-pacth to > be applied later in the chain than the i386 patch. Or if there's a patch that everyone needs such as the ptrace patch then only one package needs to provide it and everything else can depend on it. Why not have a "security" kernel patch package which starts out as a zero byte file and gets bigger as the need dictates. Next we need a mechanism for tracking which version of each patch was used in the compilation. Was your kernel compiled with version 0 of the security patch or version 1 which has the ptrace fix? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
