Hi, Thanks for everyone's effort put into trying to resolve this.
On 6/28/07, Murali Vilayannur <[EMAIL PROTECTED]> wrote:
Hi pete, Agreed. What I meant to say was that the kmem_cache_create interface may be deprecated soon. Instead of phasing out an argument, a BUG() in the kernel ensures that 3rd party folks such as us fix this issue before the actual release of the 2.6.22 kernel. How about the following patch? I have only compile tested it and made sure that it loads on my machine. But I don't run the latest kernels and so that is not such a good test..:)
The consensus seems to be this is not a trivial issue and may or may not be an issue in the final version of 2.6.22. Apologies if this turns out to have been a waste of time :( At the moment it seems like the path of least pain is to get of the 2.6.22.rc* sequence. 2.6.21 may suffice for my immediate needs. I'll test Murali's patch as soon as I've got my immediate tasks out the way. Thanks again for the prompt assistance. Regards Mark
thanks, Murali On 6/27/07, Pete Wyckoff <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote on Wed, 27 Jun 2007 08:14 -0700: > > Ah pete! thanks for the clarification. I was looking at 2.6.21 hoping > > that that would be the latest. > > It does look like a new ish kernel feature. I am sorta out of the loop > > on the newest kernel issues :( > > Let me look at the code a little bit and work on a patch and send it > > later today. > > Basically, SLAB is deprecated. We need to find out an alternate > > way/interface. > > The verdict is still quite out on SLAB vs the other allocators. But > regardless, they'll all have the same interface. And that interface > no longer accepts a destructor function. We might as well get used > to it. > > Regarding us wasting our time with these pre-release kernels. > Agreed it's a major pain to deal with, and we don't want to waste > time adapting to the daily changes in linux, especially as > reversions are not completely uncommon. But for modifications that > are likely to stick, including the previous slab one mvdv ran into > at compile time, it's a question of fix it now or fix it later. > > We could always just dump the code and go with the fuse version. :) > > -- Pete >
_______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
