Do you have any objections to merging FUSE in mainline kernel?
It's been in -mm for the 2.6.11 cycle, and the same code was released a month ago as FUSE-2.2. So it should have received a fair amount of testing, with no problems found so far.
The one originally merged into -mm already addressed all major issues that people found (most importantly the OOM deadlock thing), and though there were some minor changes in the interface since then, I feel that the current kernel interface will stand up to the test of time.
> Do you have any objections to merging FUSE in mainline kernel?
I was planning on sending FUSE into Linus in a week or two. That and cpusets are the notable features which are 2.6.12 candidates.
- crashdump seems permanently not-quite-ready
- perfctr works fine, but is rather deadlocked because it is similar-to-but-different-from ia64's perfmon, and might not be suitable for ppc64 (although things have gone quiet on the latter front).
- nfsacl should be OK for 2.6.12 if Trond is OK with it.
- cachefs is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help.
- dm multipath is OK for 2.6.12
- reiser4 is less clear. Once all the review comments have been addressed and we start seeing a bit of vendor pull for it, maybe.
On Wed, Mar 02, 2005 at 07:17:13PM +0100, Miklos Szeredi wrote: > Hi Andrew!
> Do you have any objections to merging FUSE in mainline kernel?
> It's been in -mm for the 2.6.11 cycle, and the same code was released > a month ago as FUSE-2.2. So it should have received a fair amount of > testing, with no problems found so far.
> The one originally merged into -mm already addressed all major issues > that people found (most importantly the OOM deadlock thing), and > though there were some minor changes in the interface since then, I > feel that the current kernel interface will stand up to the test of > time.
Please give me or some other filesystem person some time to look over it, there were a few things that looked really fishy.
And apologies for not having time to look at it earlier, but I'm a little bit too busy right now.
On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote: > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > Do you have any objections to merging FUSE in mainline kernel?
> I was planning on sending FUSE into Linus in a week or two. That and > cpusets are the notable features which are 2.6.12 candidates.
> - crashdump seems permanently not-quite-ready
> - perfctr works fine, but is rather deadlocked because it is > similar-to-but-different-from ia64's perfmon, and might not be suitable > for ppc64 (although things have gone quiet on the latter front).
Not to mention that the ABI is still changing with each release...
> - nfsacl should be OK for 2.6.12 if Trond is OK with it.
> - cachefs is a bit stuck because it's a ton of complex code and afs is > the only user of it. Wiring it up to NFS would help.
> - dm multipath is OK for 2.6.12
> - reiser4 is less clear. Once all the review comments have been addressed > and we start seeing a bit of vendor pull for it, maybe.
On Wed, Mar 02, 2005 at 12:31:23PM -0800, Andrew Morton wrote: > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > Do you have any objections to merging FUSE in mainline kernel?
> I was planning on sending FUSE into Linus in a week or two. That and > cpusets are the notable features which are 2.6.12 candidates.
> - crashdump seems permanently not-quite-ready
> - perfctr works fine, but is rather deadlocked because it is > similar-to-but-different-from ia64's perfmon, and might not be suitable > for ppc64 (although things have gone quiet on the latter front).
I once asked Mikael about using PMC's from kernel-space, he told me it wouldnt be too hard to make them usable via kernel-space through perfctr.
Is perfmon's API useable to kernel users?
That sounds like a good point in favour of a given implementation, no? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> > Do you have any objections to merging FUSE in mainline kernel?
> > It's been in -mm for the 2.6.11 cycle, and the same code was released > > a month ago as FUSE-2.2. So it should have received a fair amount of > > testing, with no problems found so far.
> > The one originally merged into -mm already addressed all major issues > > that people found (most importantly the OOM deadlock thing), and > > though there were some minor changes in the interface since then, I > > feel that the current kernel interface will stand up to the test of > > time.
> Please give me or some other filesystem person some time to look over > it, there were a few things that looked really fishy.
Please do. Although I think the most complex part of FUSE is the device handling, which is not really "filesystem" code. The filesystem part is mostly really straightforward.
Still the more people look at it, the better.
> And apologies for not having time to look at it earlier, but I'm a little > bit too busy right now.
Take your time, I don't want to hurry merging into mainline, but things went very quiet lately on the bug front.
> Miklos Szeredi <mik...@szeredi.hu> wrote: > > > > Do you have any objections to merging FUSE in mainline kernel? > > I was planning on sending FUSE into Linus in a week or two. That and > cpusets are the notable features which are 2.6.12 candidates. > > - crashdump seems permanently not-quite-ready > > - perfctr works fine, but is rather deadlocked because it is > similar-to-but-different-from ia64's perfmon, and might not be suitable > for ppc64 (although things have gone quiet on the latter front).
perfctr has one API update pending, and then the API should be in it final-ish form. David Gibson at IBM has done a ppc64 port, which is about ready to be merged, and someone else has just started working on a mips port.
> Andrew Morton writes: > > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > > Do you have any objections to merging FUSE in mainline kernel?
> > I was planning on sending FUSE into Linus in a week or two. That and > > cpusets are the notable features which are 2.6.12 candidates.
> > - crashdump seems permanently not-quite-ready
> > - perfctr works fine, but is rather deadlocked because it is > > similar-to-but-different-from ia64's perfmon, and might not be suitable > > for ppc64 (although things have gone quiet on the latter front).
> perfctr has one API update pending, and then the API should be > in it final-ish form. David Gibson at IBM has done a ppc64 port, > which is about ready to be merged, and someone else has just > started working on a mips port.
That sounds good. Where do we stand now with ia64? Do we just end up agreeing to differ?
On Wed, 2 Mar 2005, Andrew Morton wrote: > Miklos Szeredi <mik...@szeredi.hu> wrote:
> > Do you have any objections to merging FUSE in mainline kernel?
> I was planning on sending FUSE into Linus in a week or two.
I would certainly vote for FUSE going in. Even if it has some bits that could be improved the code works well. It has been in global use for quite a while. We use it in a production environment on four servers and over 650 workstations to provide a "magic symlink filesystem" (i.e. symlink XYZ points to different place depending on which user looks at it) and we have not experienced any problems. I have also done other testing with a layering fs using fuse and that was very stable (but slower than the symlink approach which is why we went for that).
FUSE may not be perfect but lets face it - which code is? And more importantly a lot of code in the kernel is broken (for at least some people) yet it is in the kernel and FUSE does work well...
> Mikael Pettersson <mi...@csd.uu.se> wrote: > > > > Andrew Morton writes: > > > Miklos Szeredi <mik...@szeredi.hu> wrote: > > > > > > > > Do you have any objections to merging FUSE in mainline kernel? > > > > > > I was planning on sending FUSE into Linus in a week or two. That and > > > cpusets are the notable features which are 2.6.12 candidates. > > > > > > - crashdump seems permanently not-quite-ready > > > > > > - perfctr works fine, but is rather deadlocked because it is > > > similar-to-but-different-from ia64's perfmon, and might not be suitable > > > for ppc64 (although things have gone quiet on the latter front). > > > > perfctr has one API update pending, and then the API should be > > in it final-ish form. David Gibson at IBM has done a ppc64 port, > > which is about ready to be merged, and someone else has just > > started working on a mips port. > > > > That sounds good. Where do we stand now with ia64? Do we just end up > agreeing to differ?
I think so, yes.
The ia64 perfmon has some features perfctr doesn't have, but my perfctr API changes will allow perfctr to grow its feature list and adapt to HW changes without breaking the API. Its unlikely that perfctr will ever implement everything perfmon does, but multiplexing and overflow sample buffering are two features that should be added at some point.
> > > perfctr has one API update pending, and then the API should be > > > in it final-ish form. David Gibson at IBM has done a ppc64 port, > > > which is about ready to be merged, and someone else has just > > > started working on a mips port.
> > That sounds good. Where do we stand now with ia64? Do we just end up > > agreeing to differ?
> I think so, yes.
> The ia64 perfmon has some features perfctr doesn't have, > but my perfctr API changes will allow perfctr to grow its > feature list and adapt to HW changes without breaking the API. > Its unlikely that perfctr will ever implement everything > perfmon does, but multiplexing and overflow sample buffering > are two features that should be added at some point.
Oh well, at least we tried. perfctr supports a lot of architectures and a fair few people want it, so let's get this merged up.
Let's get the ppc64 port included too, just in case that forces late-breaking API changes.
Andrew Morton wrote: > - cachefs is a bit stuck because it's a ton of complex code and afs is > the only user of it. Wiring it up to NFS would help.
Yes, please! I have an application for CacheFS between an NFS client and server (all Linux) very soon :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
