On 09/27/2012 10:05 AM, Troy Benjegerdes wrote:
On Wed, Sep 26, 2012 at 03:37:34PM -0600, Ken Dreyer wrote:
On Wed, Sep 26, 2012 at 3:33 PM, Stephan Wiesand
<stephan.wies...@desy.de> wrote:
On Sep 26, 2012, at 00:09 , Ken Dreyer wrote:
My small experience with kabi kmod packages is limited to ATI's video
drivers and OpenAFS. It has worked sometimes, but other times I've had
to rebuild against RHEL 6's newer kernels in order to get a module to
work properly. I'm wondering what's the best direction overall.
To my understanding: Unless a module uses whitelisted symbols only,
kabi-tracking kmod's aren't safe across minor EL6 releases, at least.
They may be safe within minor releases. Alas, the current way of
packaging does not even support that kind of use at all: There's no
way to have more than one module installed at a time, and the single
module will be made available to kernels in which it may render the
system completely unusable, or cause any other kind of problems. As
Simon pointed out, this could well affect data integrity, making the
issue really serious in the openafs case. Taking the risk may be ok
for a display driver. For a filesystem, it probably isn't.
Thank you, that helps me understand. So what will your approach be in
Scientific Linux for this? Also, I guess ELRepo will suffer the same
problem? RPM Fusion is looking at using kabi-tracking for kmods for
EL, which is why I'm interested.
- Ken
This may be a loaded question, but I'll ask it anyway.. With all these
packaging problems with Red Hat, would it be possible to switch to
Debian? The kernel packaging seems a lot more sane.
If Red Hat is a requirement, then what are the perceived obstacles to
making the in-kernel kafs module do all the filesystem stuff, and all
OpenAFS packages need to do is provide userspace tools?
Both fuse and arla (mentioned elsewhere) would also solve the problem,
but you are going to wind up in context-switch hell going to the kernel
for a write, back to userspace through fuse/nnpfs, then back to the
kernel. It will probably work very reliably, but will either be slow
or with a lot of cpu overhead.
I can't speak for the original poster, but I'm stuck with RHEL at my
site. I'm in the IT group for an engineering college at a university.
Our vendor-provided apps aren't supported on debian/ubuntu, only RHEL/SuSE.
Jason
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
