[arch-dev-public] kernel26 unionfs/aufs conflict
Hey guys, The unionfs patch in our kernel right now is old, and suffers from a few pretty bad bugs that cause frequent kernel panics. Anyhow, there's a new version at http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.3.1_for_2.6.24... which works fine. However, it looks like it directly conflicts with the splice patch needed for aufs. Both unionfs and the aufs patch export a couple functions for modules to use in splice.c, and they happen to export them as different function names, hence the conflict. I'd argue that the unionfs patch does it "more correctly" given that it prefixes the function names with vfs_, where the aufs patch simply exports them as-is (there goes the namespace. ick.). Now, we can work around this with a dirty little hack that just exports both names, and has one simply call/return the other. Another alternative is to let unionfs do it their way, and patch our out-of-tree aufs module accordingly, which isn't a whole lot cleaner. The last option is to drop either aufs or unionfs, which isn't exactly desirable either... although they do provide similar functionality. Anyhow, I need some opinions here, and it's ultimately up to the kernel maintainers. I'm willing to write patches for options 1 or 2 if that's how you want to do it. As an aside, I'm going to read up on it and figure out who really does it the "right" way and let the other project know about it. -S
Am Mittwoch, 26. März 2008 schrieb Simo Leone:
Hey guys,
The unionfs patch in our kernel right now is old, and suffers from a few pretty bad bugs that cause frequent kernel panics. Anyhow, there's a new version at http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.3.1_for_2.6.2 4.4.diff.gz which works fine. However, it looks like it directly conflicts with the splice patch needed for aufs. Both unionfs and the aufs patch export a couple functions for modules to use in splice.c, and they happen to export them as different function names, hence the conflict. I'd argue that the unionfs patch does it "more correctly" given that it prefixes the function names with vfs_, where the aufs patch simply exports them as-is (there goes the namespace. ick.).
Now, we can work around this with a dirty little hack that just exports both names, and has one simply call/return the other. Another alternative is to let unionfs do it their way, and patch our out-of-tree aufs module accordingly, which isn't a whole lot cleaner. The last option is to drop either aufs or unionfs, which isn't exactly desirable either... although they do provide similar functionality.
Anyhow, I need some opinions here, and it's ultimately up to the kernel maintainers. I'm willing to write patches for options 1 or 2 if that's how you want to do it.
As an aside, I'm going to read up on it and figure out who really does it the "right" way and let the other project know about it.
-S
Hi to reconsider, you were the guys that wanted those filesystem stuff in the kernel, I just add/fix hardware support which doesn't conflict with such stuff, so figure out how to fix it send patches that it works for the stuff you need it. Checkout Aufs from latest CVS and try to combine it that it works. I don't use any of this filesystems. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Wed, Mar 26, 2008 at 08:34:37AM +0100, Tobias Powalowski wrote:
Hi to reconsider, you were the guys that wanted those filesystem stuff in the kernel, I just add/fix hardware support which doesn't conflict with such stuff, so figure out how to fix it send patches that it works for the stuff you need it. Checkout Aufs from latest CVS and try to combine it that it works. I don't use any of this filesystems.
Ok, let's assume for right now that we aren't going to drop either of them. Would you, as the kernel maintainer, prefer the in-tree solution of effectively aliasing the function names; or the out-of-tree solution of patching aufs to deal with unionfs's function names? Either will work just fine. -S
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Simo Leone Verzonden: woensdag 26 maart 2008 10:10 Aan: arch-dev-public@archlinux.org Onderwerp: Re: [arch-dev-public] kernel26 unionfs/aufs conflict
On Wed, Mar 26, 2008 at 08:34:37AM +0100, Tobias Powalowski wrote:
Hi to reconsider, you were the guys that wanted those filesystem stuff
in the
kernel, I just add/fix hardware support which doesn't conflict with such stuff, so figure out how to fix it send patches that it works for the stuff you need it. Checkout Aufs from latest CVS and try to combine it that it works. I don't use any of this filesystems.
Ok, let's assume for right now that we aren't going to drop either of them. Would you, as the kernel maintainer, prefer the in-tree solution of effectively aliasing the function names; or the out-of-tree solution of patching aufs to deal with unionfs's function names? Either will work just fine.
I would prefer to have these symbols exported only once and patch the package that needs these kernel symbols with a different name. Yes, it's a little bit more work for the external module maintainer, but it keeps our kernel cleaner that way.
On Wed, Mar 26, 2008 at 4:20 AM, Jan de Groot
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Simo Leone Verzonden: woensdag 26 maart 2008 10:10 Aan: arch-dev-public@archlinux.org Onderwerp: Re: [arch-dev-public] kernel26 unionfs/aufs conflict
On Wed, Mar 26, 2008 at 08:34:37AM +0100, Tobias Powalowski wrote:
Hi to reconsider, you were the guys that wanted those filesystem stuff
in the
kernel, I just add/fix hardware support which doesn't conflict with such stuff, so figure out how to fix it send patches that it works for the stuff you need it. Checkout Aufs from latest CVS and try to combine it that it works. I don't use any of this filesystems.
Ok, let's assume for right now that we aren't going to drop either of them. Would you, as the kernel maintainer, prefer the in-tree solution of effectively aliasing the function names; or the out-of-tree solution of patching aufs to deal with unionfs's function names? Either will work just fine.
I would prefer to have these symbols exported only once and patch the package that needs these kernel symbols with a different name. Yes, it's a little bit more work for the external module maintainer, but it keeps our kernel cleaner that way.
Agreed. Lets patch aufs if we can to use the unionfs symbol.
On Wed, Mar 26, 2008 at 04:10:08AM -0500, Simo Leone wrote:
Ok, let's assume for right now that we aren't going to drop either of them. Would you, as the kernel maintainer, prefer the in-tree solution of effectively aliasing the function names; or the out-of-tree solution of patching aufs to deal with unionfs's function names? Either will work just fine.
Hmmm on second thought, the out-of-tree solution is going to be slighly easier to deal with, and will save us having patches that depend on one another in the kernel. Please update the unionfs patch to this one: http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.3.1_for_2.6.24... And remove splice-2.6.24.patch . I will commit a patched aufs package to testing sometime soon after you make those changes. Thanks, -S
Simo Leone wrote:
On Wed, Mar 26, 2008 at 04:10:08AM -0500, Simo Leone wrote:
Ok, let's assume for right now that we aren't going to drop either of them. Would you, as the kernel maintainer, prefer the in-tree solution of effectively aliasing the function names; or the out-of-tree solution of patching aufs to deal with unionfs's function names? Either will work just fine.
Hmmm on second thought, the out-of-tree solution is going to be slighly easier to deal with, and will save us having patches that depend on one another in the kernel.
Please update the unionfs patch to this one: http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.3.1_for_2.6.24... And remove splice-2.6.24.patch .
I will commit a patched aufs package to testing sometime soon after you make those changes.
Thanks for handling this, Simo. If it is determined that we want to patch aufs to do things the cleaner way that maintains the namespace, I'll do it. We use aufs here for doing diskless nfs workstations for our whole company. Once I get out from under the crushing load of real-life stuff that has got me pegged until May, I hope to document/publicize our methods for that. Thanks to all of you for doing so much for Arch while I am unable. I hope to get back on the bandwagon again as I emerge from under my rock. Though we have some things to work on, Arch is still the best. :) - P
participants (5)
-
Aaron Griffin
-
Jan de Groot
-
Paul Mattal
-
Simo Leone
-
Tobias Powalowski