[CentOS-gsoc] kpatch irc log 2015-03-18

[Corey Henderson]

Mentor's note; hopefully fewer questions means we're getting closer to 
proposal writing ;)


	cormander	howdy
	kragniz	cormander: hi there!
	kragniz	how goes with you?
	cormander	good
	kragniz	cormander: cool!
	kragniz	I've been thinking a little about the tooling to create the 
patch packages
	cormander	great
	kragniz	so assuming we're doing the one rpm per patch route, we need to 
create an rpm for each supported kernel, right?
	cormander	that will get very messy
	cormander	I would put all versions that applies to in it
	[ERROR]	The command “path/to/kpatch/repo/<kernel” is not known to the 
server.
	cormander	like so; /path/to/kpatch/repo/<kernel 
version>/patch-name/module.ko
	cormander	or maybe the reverse; 
/path/patch-name/<kernel-version>/module.ko --- up to you
	kragniz	olay, so contain builds of the patch against all supported kernels
	cormander	right
	cormander	in the %post script of the rpm, the userspace script you 
write will determine if an update to the package actually changed the 
checksum of the module for the current running version
	cormander	and only remove / reinsert it if so
	cormander	when you generate the rpm, what your patching is in newer 
kernels, so you won't have to "add" more versions later
	cormander	unless you have a future patch touch the same thing that a 
previous patch does -
	cormander	and you'll have a list of newer modules that are smaller, and 
and bunch of updated files for older kernel versions
	kragniz	that sounds good
	kragniz	is there a drawback to reloading current patches anyway?
	cormander	you run the risk of hitting a function that's on the kernel stack
	kragniz	other than the risk of breaking something
	cormander	and failing to re-insert it
	cormander	so, best to only remove/re-insert stuff when you have to
	kragniz	okay, that sounds reasonable
	kragniz	so the input for this build system would be a source patch, and 
it would build kpatch modules for all kernels it applies cleanly 
against, or would we provide some version limitation?
	kragniz	ie, something.patch is for kernels 3.14 - 3.16 only
	cormander	version limitation. more specifically, release limitation
	cormander	we're only doing EL7 kernels
	kragniz	okay, cool
	kragniz	I need to run for about half an hour, sorry!
	cormander	no problem, just say my name when you're back
	kragniz	will do
	cormander	also - just because a patch cleanly applies doesn't mean it's 
correct. It can even be dangerous. Patch selection is a painfully manual 
process. Hard to automate
	cormander	also, patches often don't cleanly go into kernels that need it
	cormander	you can assume that patch selection is out of scope. The real 
meal of the deal here is the build and release automation
	|<--	imcleod_ has left freenode (Ping timeout: 244 seconds)
	cormander	kragniz: going to sign off shortly, unless you're still around