[arch-dev-public] AUFS Patches in Kernel
All, I would like to request the addition of the attached patch to the kernel PKGBUILD, to allow maintenance of an aufs package. Aufs is a rewrite of unionfs, with different strengths and weaknesses. The particular strength that makes it compelling is that it handles NFS filesystems as branches of a merged filesystem both correctly and with stability. This allows you to efficiently create diskless workstations where each client sees his own writeable root filesystem based off of a single filesystem image. The impact is two small patches which need to be added to the kernel, each of which exposes a small number of kernel function calls which are needed by aufs. I would appreciate if others would consider this and sign off. Having these patches in the kernel would make us fully aufs-friendly. I have attached the PKGBUILD patch against the current testing 2.6.13.1 kernel, as well as the two patches for your easy perusal. Best, Paul
On Thu, 2007-10-18 at 14:40 -0400, Paul Mattal wrote:
I would appreciate if others would consider this and sign off. Having these patches in the kernel would make us fully aufs-friendly.
I have attached the PKGBUILD patch against the current testing 2.6.13.1 kernel, as well as the two patches for your easy perusal.
I hope you mean 2.6.23.1 ;) As for the patches: all that it does is exporting one extra symbol where external modules can link to. This doesn't change the way the kernel works, so there's no downsides on applying it. +1 from me in this case.
On 10/18/07, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2007-10-18 at 14:40 -0400, Paul Mattal wrote:
I would appreciate if others would consider this and sign off. Having these patches in the kernel would make us fully aufs-friendly.
I have attached the PKGBUILD patch against the current testing 2.6.13.1 kernel, as well as the two patches for your easy perusal.
I hope you mean 2.6.23.1 ;)
As for the patches: all that it does is exporting one extra symbol where external modules can link to. This doesn't change the way the kernel works, so there's no downsides on applying it. +1 from me in this case.
I agree. One extra symbol exported has very little chance of screwing anything up beyond AUFS modules which will be external. Good work Paul. +1 from me
Jan de Groot wrote:
On Thu, 2007-10-18 at 14:40 -0400, Paul Mattal wrote:
I would appreciate if others would consider this and sign off. Having these patches in the kernel would make us fully aufs-friendly.
I have attached the PKGBUILD patch against the current testing 2.6.13.1 kernel, as well as the two patches for your easy perusal.
I hope you mean 2.6.23.1 ;)
As for the patches: all that it does is exporting one extra symbol where external modules can link to. This doesn't change the way the kernel works, so there's no downsides on applying it. +1 from me in this case.
I can drop this in since it sounds like enough agree. One thing I was thinking is that I should actually snapshot the patches, just on principle, since this is currently pulling them from the most current CVS and they might change. I'll put this in and bump the pkgrel. Should I build and upload a new kernel or wait for the next round that tpowa or someone else does? - P
Paul Mattal wrote:
I'll put this in and bump the pkgrel. Should I build and upload a new kernel or wait for the next round that tpowa or someone else does?
I've rebuilt the kernel (2.6.23.1-3). Can drop it in [testing] unless we're waiting for other things to make it into -3. That might just be easier if there are any straggler items that need to be fixed. Once it's in testing, I will drop aufs into [testing] (destined for extra). - P
Am Freitag, 19. Oktober 2007 schrieb Paul Mattal:
Paul Mattal wrote:
I'll put this in and bump the pkgrel. Should I build and upload a new kernel or wait for the next round that tpowa or someone else does?
I've rebuilt the kernel (2.6.23.1-3). Can drop it in [testing] unless we're waiting for other things to make it into -3. That might just be easier if there are any straggler items that need to be fixed.
Once it's in testing, I will drop aufs into [testing] (destined for extra).
- P
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
built kernel for both arches with your additions and latest stable alsa release -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski wrote:
Am Freitag, 19. Oktober 2007 schrieb Paul Mattal:
Paul Mattal wrote:
I'll put this in and bump the pkgrel. Should I build and upload a new kernel or wait for the next round that tpowa or someone else does? I've rebuilt the kernel (2.6.23.1-3). Can drop it in [testing] unless we're waiting for other things to make it into -3. That might just be easier if there are any straggler items that need to be fixed.
Once it's in testing, I will drop aufs into [testing] (destined for extra).
A comment on the aufs package, now that it's in testing: Normally, for packages of this kind, we provide foo (the kernel module) and foo-utils (the userspace piece). This makes it easier for users to work with more than one kernel. Also, in case you had overlooked it, aufs-utils is already in community. T.
Tom K wrote:
A comment on the aufs package, now that it's in testing: Normally, for packages of this kind, we provide foo (the kernel module) and foo-utils (the userspace piece). This makes it easier for users to work with more than one kernel.
I thought about this. If someone wants to maintain aufs for some other kernel, I'm willing to incur the overhead of splitting the package, but otherwise not. What are our list of supported kernels now? I know several went away recently.
Also, in case you had overlooked it, aufs-utils is already in community.
I HAD overlooked that. Thanks! - P
Paul Mattal wrote:
Tom K wrote:
A comment on the aufs package, now that it's in testing: Normally, for packages of this kind, we provide foo (the kernel module) and foo-utils (the userspace piece). This makes it easier for users to work with more than one kernel.
I thought about this. If someone wants to maintain aufs for some other kernel, I'm willing to incur the overhead of splitting the package, but otherwise not.
What are our list of supported kernels now? I know several went away recently.
We have two now - mind you, one of them is kernel26mm in unstable, and I believe that anyone who chooses to use it knows (or should know) what they're getting into. More to the point, my opinion on foo-utils separation is that it makes Arch more accommodating for people who want or need to build their own kernel, as well as allowing for new official kernel packages in the future. T.
Tom K wrote:
Paul Mattal wrote:
A comment on the aufs package, now that it's in testing: Normally, for packages of this kind, we provide foo (the kernel module) and foo-utils (the userspace piece). This makes it easier for users to work with more than one kernel. I thought about this. If someone wants to maintain aufs for some other kernel, I'm willing to incur the overhead of splitting the
Tom K wrote: package, but otherwise not.
What are our list of supported kernels now? I know several went away recently.
We have two now - mind you, one of them is kernel26mm in unstable, and I believe that anyone who chooses to use it knows (or should know) what they're getting into. More to the point, my opinion on foo-utils separation is that it makes Arch more accommodating for people who want or need to build their own kernel, as well as allowing for new official kernel packages in the future.
I guess I have just never entirely understood the benefits of this convention-- and should point out that in my time as a dev we have tried about three different ways that were "the prevailing standard" for a while. Why split the package if the amount of "utils" is small? Can't the person who wants to build aufs for another kernel just make an "aufs-mm" package? How is that substantially worse? It's not immediately obvious to me that splitting kernel module packages in half creates more benefit than it costs-- having to track, upload, namcap, install, test, md5sum, etc. another package. It's one more place to make a mistake for every module package. What do others think? I'm generally in favor of treating package split for kernel modules the same way we treat it for other things.. try to do what the upstream distribution does, unless for efficiency's sake it makes a LOT more sense to split it (i.e. postgresql and postgresql-libs) - P
Am Freitag, 19. Oktober 2007 18:40:47 schrieb Paul Mattal:
Why split the package if the amount of "utils" is small? Can't the person who wants to build aufs for another kernel just make an "aufs-mm" package? How is that substantially worse?
You cannot use this if you have more than one kernel installed. -- http://www.archlinux.de
Pierre Schmitz wrote:
Am Freitag, 19. Oktober 2007 18:40:47 schrieb Paul Mattal:
Why split the package if the amount of "utils" is small? Can't the person who wants to build aufs for another kernel just make an "aufs-mm" package? How is that substantially worse?
You cannot use this if you have more than one kernel installed.
Ah right. Thanks. That was the piece I was missing. Okay, I'll split up aufs. - P
participants (6)
-
Aaron Griffin
-
Jan de Groot
-
Paul Mattal
-
Pierre Schmitz
-
Tobias Powalowski
-
Tom K