Linux has FUSE FS, does FreeBSD has created his own protocol for userspace filesystem?

[Ferocious1881]

As the title says.

 

[bsduck]

FreeBSD has the same FUSE available: fusefs(5)

 

[Ferocious1881]

FreeBSD has the same FUSE available: fusefs(5)

I mean something that is not FUSE, like porting others protocols, or inventing a novel protocol, but not FUSE.

 

[kpedersen]

Yep, and we also have a number of useful ports utilizing it:

• fusefs-ntfs
• fusefs-exfat
• fusefs-sshfs

Edit: Just saw your last post. We have a number of layers, like Wine, LinuxKPI (Graphics and WiFi) and NDISulator to help with driver abstractions if thats what you meant?

 

[Ferocious1881]

Yep, and we also have a number of useful ports utilizing it:

• fusefs-ntfs
• fusefs-exfat
• fusefs-sshfs

Edit: Just saw your last post. We have a number of layers, like Wine, LinuxKPI (Graphics and WiFi) and NDISulator to help with driver abstractions if thats what you meant?

I meant if containers are like Linux attempt to do FreeBSD's Jails, then what is the attempt of FreeBSD to do FUSE?

 

[kpedersen]

Oh right. Its still called FUSE but it is quite different internally.

Also, the concept of FUSE came from Hurd, not Linux. The early Linux implementation was called AVFS.

 

[bsduck]

The attempt of FreeBSD to do FUSE is fusefs(5)
No need to reinvent the wheel. Similar implementations exist for other OS, including MacOS.

 

[Ferocious1881]

Oh right. Its still called FUSE but it is quite different internally.

Also, the concept of FUSE came from Hurd, not Linux. The early Linux implementation was called AVFS.

There is a different API interface to the userspace part of FreeBSD's FUSE?

 

[kpedersen]

There is a different API interface to the userspace part of FreeBSD's FUSE?

No. FUSE for Solaris, macOS, Linux, OpenBSD, FreeBSD, Windows, etc all export the same API. That is the most important part!

 

[Ferocious1881]

No. Solaris, macOS, Linux, OpenBSD, FreeBSD, etc all export the same API. That is the most important part!

Then it is not different as to have a port of Linux FUSE, and means that is not an answer to my question.

No need to reinvent the wheel. Similar implementations exist for other OS, including MacOS.

And the plan9 protocol is another different attempt to FUSE and beyond. Have heard that is better than FUSE.

 

[kpedersen]

Then it is not different as to have a port of Linux FUSE, and means that is not an answer to my question.

I guess going way back, the TCP stack of Linux (and Windows and POSIX in general) is based on BSD's. Especially if you don't consider the exposed API to be different from the implementation.

And the plan9 protocol is another different attempt to FUSE and beyond. Have heard that is better than FUSE.

9p is good. It is rarely provided in the same way as FUSE but it is still in common use as virtio drivers for qemu.

 

[T-Aoki]

What's the "unacceptable" drawbacks of FUSE?
If none, use FUSE API for all possible OS'es is clearly the best thing.
The best is that A"B"I are 100% match for all OS'es on the same CPU architecture like amd64 and licensed under BSD n Clause or more permissive license. This way, all OS'es can use the pre-built binary regardless whichever OS is used to build it. But it's just a dream.

If some functionality is missed in the API to implement specific filesystems, discussion between develpers on all OS'es supporting FUSE should be held.

 

[Ferocious1881]

What's the "unacceptable" drawbacks of FUSE?
If none, use FUSE API for all possible OS'es is clearly the best thing.
The best is that A"B"I are 100% match for all OS'es on the same CPU architecture like amd64 and licensed under BSD n Clause or more permissive license. This way, all OS'es can use the pre-built binary regardless whichever OS is used to build it. But it's just a dream.

If some functionality is missed in the API to implement specific filesystems, discussion between develpers on all OS'es supporting FUSE should be held.

FUSE has some drawbacks that makes FUSE unfit for some theoretical and existing Operating Systems, like having following the original UNIX file permission system, even if FreeBSD is not one of these Operating Systems. FUSE is not perfect.

The best is that A"B"I are 100% match for all OS'es on the same CPU architecture like amd64 and licensed under BSD n Clause or more permissive license. This way, all OS'es can use the pre-built binary regardless whichever OS is used to build it. But it's just a dream.

I don't think that any OS is interested in a ABI compatible with other OSes, I have the, maybe wrong, notion that even the UNIX standard body The Open Group has given up in any dream of getting there.

If some functionality is missed in the API to implement specific filesystems, discussion between develpers on all OS'es supporting FUSE should be held.

Do you mean FUSE consortium?

 

[kpedersen]

like having following the original UNIX file permission system, even if FreeBSD is not one of these Operating Systems. FUSE is not perfect.

Thats fair. Mapping between foreign filesystems can be complex (or outright broken), though not entirely FUSE's fault. The nature of the problem is difficult to solve.

Perhaps you would be more interested in network file systems which provide that abstraction for you? NFS, Samba?

 

[Ferocious1881]

Also the paper The Design and Implementation of the Anykernel and Rump Kernels by Antti Kantee presents something, that by my own opinion a better approach to get some kind of FUSE, and for the looks of it, it can be retrofitted in a monolithic kernel like FreeBSD without too much effort, which also gives a great improvement in the quality of FreeBSD kernel development.

 

[Jose]

I guess going way back, the TCP stack of Linux (and Windows and POSIX in general) is based on BSD's. Especially if you don't consider the exposed API to be different from the implementation.

Not Linux. Its early TCP stack was written by Alan Cox, and used to credit Swansea University. I can't find a source, but I believe the reason why Linux didn't adopt the BSD stack was the AT&T / BSDI lawsuit was still grinding its way through the courts.

Swansea/Linux trivium

Has anyone ever noticed that, during the Linux boot process, there used to be a kernel message "Based upon Swansea University Computer Society NET3.039"? It had to do with the TCP/IP networking stack, and was removed from the source code in 2003:http://twenty.sucs.org/TheSociety/AboutThere are...

americymru.net

I know the early, third-party Windows TCP stack (Trumpet Winsock) was a straight port of the BSD code to Windows 16/32. I suspect the MS-Developed stack was probably mostly a BSD port, but it's impossible to prove.

 

[kpedersen]

Not Linux. Its early TCP stack was written by Alan Cox, and used to credit Swansea University.

Indeed but the public API was still a clone of BSDs (later ratified as POSIX).

 

[kpedersen]

I know the early, third-party Windows TCP stack (Trumpet Winsock) was a straight port of the BSD code to Windows 16/32. I suspect the MS-Developed stack was probably mostly a BSD port, but it's impossible to prove.

Ah, I used to have a really interesting citation for that one. If I recall, it stated that Windows XP's earlier version of Winsock was based on an older implementation of BSDs stack (it even explained why). But then it was rewritten around Vista era.

I can't seem to track it down, I believe it was linked in one of neozeed's articles and it was an archive.org link to one of Microsoft's websites.

 

[Jose]

Yeah, it's getting really hard to find links to old stuff. I don't know if it's search engine bias for newer results, or the information just going dark. I hope it's only the former, but I suspect it's both.