From: Eric Sandeen <sandeen@sandeen.net>
To: Keith Keller <kkeller@wombat.san-francisco.ca.us>
Cc: linux-xfs@oss.sgi.com
Subject: Re: A short digression on FOSS (Re: understanding speculative preallocation)
Date: Mon, 29 Jul 2013 08:38:38 -0500 [thread overview]
Message-ID: <51F6705E.5040309@sandeen.net> (raw)
In-Reply-To: <2b9hcaxru.ln2@goaway.wombat.san-francisco.ca.us>
On 7/28/13 11:57 PM, Keith Keller wrote:
> On 2013-07-29, Eric Sandeen <sandeen@sandeen.net> wrote:
>>
>> In general, no. There are a lot of moving parts that interface with
>> the filesystem - one does not simply drop fs/xfs from, say, kernel
>> 3.2 into a 2.6.32 kernel.
>
> I apologize for the confusion, this was not what I was implying was
> possible. Let me try to be more explicit. Unfortunately, I no longer
> have a history of what I did, because I ultimately abandoned it, so my
> example will be hypothetical.
>
> The current stable kernel is 3.10.4. Let's suppose that 3.10.5 comes
> out tomorrow with some interesting patches to fs/xfs. Is it possible
> using dkms to build the 3.10.5 version of the xfs module for a running
> 3.10.4 kernel?
"Probably / Maybe"
It really depends on what changed from 3.10.4 to 3.10.5, but odds are,
kernel interfaces did not change, so - probably fine. If not, you
get to keep all the pieces, etc.
> And if so, is there a way for the module to report its
> own version?
Say it with me: there is no xfs module version. :)
The "module version" is inherited from the kernel it's built against.
$ modinfo xfs
...
vermagic: 2.6.32-279.22.1.el6.x86_64 SMP mod_unload modversions
> There should (in theory) be much less wizardry involved in
> this scenario than in the difficult scenario of porting 3.10's xfs back
> to 2.6, and is more along the lines of what I remember doing a short
> time back). (To be specific, IIRC what I did was took a proposed patch
> against my running kernel version, which had not yet been incorporated
> in the distro kernel, and tested it by replacing the distro kernel's
> module with one I built via DKMS. But as I mentioned, I have no docs on
> this, so I could be misremembering the process.)
Yeah, short version hops are more likely to be ok.
And taking kernel version X's xfs, and applying a bugfix patch, and
rebuilding it against the same kernel headers should be fine. Still
a little wizardry, but not bad for a kernel-savvy person.
> I am not intentionally trying to be difficult. :) I am genuinely
> just curious about the answer. If it's "no" (or perhaps, in this
> specific scenario, it's "use the dkms tools"), it still provides me with
> valuable information I did not previously have.
Sure, I don't think you're being difficult.
The further you go off the reservation, the less tested things are, and
the less likely they are to work. Building a tweaked, same-era module
against a slightly different kernel is likely to be fine; it's when
you get more & more changed / moving parts that it becomes trickier.
But you need to know enough to know what you're changing and/or what
has changed in the kernel, to know if what you're doing is completely
safe, probably safe, or unlikely to be safe...
-Eric
> --keith
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-29 13:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 7:23 understanding speculative preallocation jbr
2013-07-26 11:50 ` Dave Chinner
2013-07-26 17:40 ` Jason Rosenberg
2013-07-26 19:27 ` Stan Hoeppner
2013-07-26 19:43 ` A short digression on FOSS (Re: understanding speculative preallocation) Jay Ashworth
2013-07-27 3:52 ` Stan Hoeppner
2013-07-27 21:00 ` Jay Ashworth
2013-07-28 1:38 ` aurfalien
2013-07-28 1:50 ` Jay Ashworth
2013-07-28 2:08 ` aurfalien
2013-07-28 2:21 ` Jay Ashworth
2013-07-28 5:09 ` Purpose of the XFS list -- was: " Stan Hoeppner
2013-07-28 15:45 ` Jay Ashworth
2013-08-14 17:01 ` Emmanuel Florac
2013-07-28 7:18 ` Stefan Ring
2013-07-28 15:48 ` Jay Ashworth
2013-07-29 0:02 ` Dave Chinner
2013-07-29 0:06 ` Jay Ashworth
2013-07-29 2:41 ` Dave Chinner
2013-07-29 3:12 ` Eric Sandeen
2013-07-29 4:11 ` Stan Hoeppner
2013-07-29 14:33 ` Jay Ashworth
2013-07-29 15:25 ` Dave Howorth
2013-07-29 3:38 ` Keith Keller
2013-07-29 4:32 ` Eric Sandeen
2013-07-29 4:57 ` Keith Keller
2013-07-29 13:38 ` Eric Sandeen [this message]
2013-07-29 18:15 ` Keith Keller
2013-07-29 14:24 ` Jay Ashworth
2013-07-29 14:36 ` Jay Ashworth
2013-07-29 14:57 ` Eric Sandeen
2013-07-29 15:30 ` Jay Ashworth
2013-07-29 17:05 ` Eric Sandeen
2013-07-29 0:00 ` Dave Chinner
2013-07-28 5:15 ` Michael L. Semon
2013-07-26 20:38 ` understanding speculative preallocation Jason Rosenberg
2013-07-26 20:50 ` Ben Myers
2013-07-26 21:04 ` Jason Rosenberg
2013-07-26 21:11 ` Jason Rosenberg
2013-07-26 21:42 ` Ben Myers
2013-07-27 1:30 ` Dave Chinner
2013-07-28 2:19 ` Jason Rosenberg
2013-07-29 0:04 ` Dave Chinner
2013-07-26 21:45 ` Eric Sandeen
2013-07-27 4:26 ` Keith Keller
2013-07-27 1:26 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F6705E.5040309@sandeen.net \
--to=sandeen@sandeen.net \
--cc=kkeller@wombat.san-francisco.ca.us \
--cc=linux-xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.