(Illustration by Gaich Muramatsu)
Hello! On Wed, Jan 11, 2006 at 09:53:50AM +0900, Stephen J. Turnbull wrote: > >>>>> "Denis" == Denis Chapligin <chollya_at_satgate.net> writes: > > Denis> My problem is that i'm trying to build kernels in 'debian > Denis> way', so i have a single .deb package with kernel, some > Denis> patches, additional modules and so on. But coda module > Denis> requires additional work in this case and it comes to be a > Denis> problem whan you have several dozens of servers:) So > Denis> providing a kernel patch for coda module will make a life > Denis> easier . > > But why should there be a separate patch for something that is already > in the kernel? If the module distributed with the kernel doesn't work > for you, let's fix it! But the additional kernel module is provided for every version of coda client.... > >From what Jan says, I guess there's a backward compatibility problem > with the old implicit-single-realm kernel code and the modern explicit > realms code. That should be fixed by adding two build suboptions to > build with the realms code and without, not by maintaining a separate > patch. (Either or both modules could be built, and they would be > named "coda-realms" and "coda-norealms".) The out-of-box kernel module doesn't supports realms. So i have to compile new module manually (i.e. not during automated kernel compilation process) and then manually copy it to all my servers. > This way you could (in theory) upgrade an individual client on-the-fly > with "modprobe -r coda-norealms; modprobe coda-realms". Of course it > probably won't work so well in practice, but at least this would mean > every kernel would be ready for upgrade simply by switching modules. > There could be a lot of problems with versioning and so on. But sounds good :) -- Denis ChapliginReceived on 2006-01-11 07:49:54