[oi-dev] Fuse and NTFS-3g

[ken mays]

Hi,


Ref: https://www.illumos.org/issues/252 

illumos-fuse2: https://bitbucket.org/gwr/illumos-fuse2a

oi-sfe fuse 2.8.6: https://bugs.illumos.org/issues/1729

I saw a rejection from Richard Lowe for a request for Illumos to update the OSOLfuse modules to fuse 2.8.4.
From his explanation, fuse is not part of Illumos so the rejection made sense at the time. Bayed, are we now opposing this notion?

As for illumos-gate2, Gordon, is it better to use the fuse 2.8.6 sources and implement your patches to it (vfs related) to create packages to update the fuse packages (based on OSOLfuse 20100615 (2.7.x) sources) in oi-sfe?? We could just use your previous work and start from there to test and review or from the native fuse 2.8.x sources and port your code. I've already ported fuse 2.8.6 for oi-sfe purposes, so either way we want to spin the bottle is fine with me.


See:
system/file-system/fuse-ext2 at 0.0.5,5.11-0.151.1:20111014T184713Z     
system/file-system/fusefs at 0.20100615,5.11-0.151.1:20111014T184714Z     
system/file-system/libfuse at 0.20100615,5.11-0.151.1:20111014T184714Z 


Also, I don't mind if someone else picks up the continual work effort from the oi-sfe side of the fence. Just, let us move forward on the topic...

~ Ken Mays




________________________________
From: Gordon Ross <gordon.w.ross at gmail.com>
To: OpenIndiana Developer mailing list <oi-dev at openindiana.org>
Sent: Sunday, November 6, 2011 12:47 AM
Subject: Re: [oi-dev] Fuse and NTFS-3g

On Sun, Nov 6, 2011 at 12:15 AM, Bayard G. Bell
<buffer.g.overflow at gmail.com> wrote:
> On Fri, 2011-11-04 at 18:41 +0000, Bayard G. Bell wrote:
>> On Thu, 2011-11-03 at 09:58 +0100, Damian Wojsław wrote:
>> > Hi
>> >
>> > I would like to work on inclusion of fuse and ntfs-3g into main
>> > openindiana package repo and also maintain packages if they get
>> > included. Is OI interested?
>>
>> Two points: this project is now hosted at opensolaris.org, so please
>> consider forking it somewhere like bitbucket [...]

If someone wants to debug/extend/maintain that code,
then yes, bitbucket or somewhere would be a good idea.

>> [...]   I also take Gordon's point about the stability of
>> something like a semi-orphaned kernel module for which we don't have
>> upstream issue tracking (forking gets this out in the open). Whether we
>> flag this by repo or other metadata (and there are other cases where we
>> ought to consider this, such as transitioning off of legacy libraries),
>> we should have some way of marking caveat emptor.

That was the reason for my question.  I'm not sure what level of
stability that opensolaris code has.  Some have found it useful.

> Hm, looking at the GSoC project ideas page, I noticed that gwr has
> previously forked fuse for illumos (see bottom of
> https://www.illumos.org/projects/illumos-gate/wiki/Project_Ideas). Could
> we please start from this base? I think fuse support is something that
> should be coordinated with the illumos upstream, including giving
> SFE-maintained patches a long-term home.

That little "science project" I started was fun, and I'd _love_ to
see someone with interest in that take it forward.  The initial
results were very promising, but there's much more work to do.
(For more info, see: https://bitbucket.org/gwr/illumos-fuse2a )

However, unless and until someone does more work on that
"science project", I don't think it's really a contender to be
"the illumos 'fuse' module".  (And if there's not some more
testing, debugging, etc. done on the old opensolaris fuse
code, I'm not sure that's really a contender either!:)

Gordon

_______________________________________________
oi-dev mailing list
oi-dev at openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20111106/f0513bc6/attachment-0005.html>