On Sat, 24 Nov 2007, Miklos Szeredi wrote:
> > On 11/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > And I know very little about uclibc, so I'd really prefer if somebody
> > > more familiar with that system would do the report.
> >
> > As fuse becomes more and more popular and it is a base component of
> > the kernel, it should be developed/tested/supported with uclibc,
> > klibc and glibc taken into account. You are going to see more and
> > more initramfs or embedded configurations with fuse.
It's really a great pain and absolute showstopper for many quite a while.
Let's try to put the case into some numbers. Searching for 'uclibc
busybox' on
http://forum.ntfs-3g.org
gives the major FUSE symver problems which just recently were viewed about
10,000 times. Since usually about 10% of the people report and look for the
solution upstream that means something like 100,000 failed attempts.
Of course this doesn't include those who don't use ntfs-3g but just want to
use FUSE for whatever reason with uclibc, klibc and others.
> That's great. Still, that doesn't mean, you can't help with reporting
> bugs for uclibc.
I'll report the bug.
Alon, could you please make a simple segfaulting symver test case? Just a
main() and the needed two functions, similar to the construct FUSE uses.
No problem if not then I'll setup the needed environment, it will just
take a bit more time.
> The thing is, even if I add the workaround for this to the fuse
> source, other libraries using versioned symbols will still break. So
> it would make sense to fix the problem at it's root.
Nobody ever told the the real problem shouldn't be fixed. But this is how
it will go, as it almost always does:
report it
wait half year for response/fix
wait another half year for release
wait another half year distros apply
wait a few years more until most people upgrade
But let's suppose it's fixed and new release is made immediately. Then
distros/users still won't upgrade immediately because new versions will
break more important things for them.
Alternatively all these users could use a --disable-compatibility FUSE
configure option and things would just work already today, meanwhile we can
wait for the clean, beautiful, perfect engineering solution whenever, if
ever, is ready.
> > So making the library as small as possible is also a goal.
>
> I think the overhead is insignificant.
Busybox developers are working very hard to save a few __bytes__. They are
providing dozens of utilities in something like 150 kB.
On the other hand, if one installs ntfs-3g then he can wonder what the hell
that 300 kB contains. Almost 100 kB is just libfuse. At least about one kB
seems to be compatibility:
nm --size-sort -td //lib/libfuse.so.2 | grep @FUSE | add 1
967
Well, it's indeed "not so much" but size optimization could start here.
Ntfs-3g is also trying to decrease its size all the time even if new
features are being added constantly.
Szaka
--
NTFS-3G Lead Developer: http://ntfs-3g.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
