ReactOS on an Ext2/3 partition (instead of NTFS)

[Haos]

Yes, but this is nothing close to porting Linux drivers. It still requires writing the thing from scratch.

[Z98]

The "specification" was never a concern when it comes to open source file systems. It's readily documented anyways, and we really don't have any need to write drivers for other hardware besides the basics needed to get the system up and running.

[z180]

In Linux or BSD you can lookup well written code and you have
an idea how things work.The last Linux port in ReactOS
was the rdesktop client i recall which was from Google Summer of Code.
The only known BSD code in ReactOS is the TCP/IP stack which is from flux-oskit
and they ported it from FreeBSD 2.x or 3.x.I also mention Apple sometimes port
BSD code (mostly FreeBSD)to XNU/OS X which is a system with much differences from BSD.
Also I tell that the Hurd project and the Syllable project have drivers from Linux.
Coherent was different from Linux (SYSTEM V Clone)but ported the Linux CD-ROM drivers.
BSD systems include code from Mach which has a different copyright.
NetBSD ported FPU Emulation from Linux.

[Haos]

In Linux or BSD you can lookup well written code

Have you ever seen Linux kernel sources? Devs that seen them have quite the opposite opinion...

[Z98]

The "last" port from Linux was USB stuff. Porting applications is trivial compared to porting drivers and low level OS components. As you can currently tell, USB still doesn't work in ROS.

[z180]

I dont want to cause trouble but to prove that other projects could be helpful...
As I recall the USB driver was from linux 2.5 and it was replaced by the only open source
USB for NT 4.0 driver from a chinese student who calls himself woodhead which shows
USB ports in the device manager but does not recognize devices,which also can be caused by
incorrect kernel code.USB support would be very good for data exchange.The rdesktop
client ported from linux as part of Google SoC has no server part yet.

[nitrofurano]

Well, my idea would be if ReactOS could be completelly independent of the filesystem format where is it installed, no matter if it were installed on a Fat16/32, Ntfs, Ext2/3, MacOS hfs+, nfs, xfs, etc. - ReactOS could be the very first ms-windows compatible operative system having this kind of flexibility on root filesystem usage!

[FlyingIsFun1217]

Well, my idea would be if ReactOS could be completelly independent of the filesystem format where is it installed, no matter if it were installed on a Fat16/32, Ntfs, Ext2/3, MacOS hfs+, nfs, xfs, etc. - ReactOS could be the very first ms-windows compatible operative system having this kind of flexibility on root filesystem usage!

But to do any of that, it needs to be able to read/write to those FS's, meaning it needs drivers for them. I don't think you're quite clear on how the OS interacts with the file system.

FlyingIsFun1217

[GoBusto]

This thread is pretty much along the same lines as this one.

[bluefoxicy]

Personally I'd rather see a FUSE implementation. Then you can bring up ntfs-3g, or whatever else you want. If you don't like it, fine, rewrite the whole driver from scratch; it just seems to me that a driver that talks to a user space library (glue code) and a nudge at the user space library to talk to the driver through something other than /dev/something is a lot easier than writing a whole file system driver in the short term.

[Haos]

I dont think you are aware of difficulties in porting FUSE/NTFS-3g to NT/win32. If anyone has balls to do it... well we always accept patches (tm). Still, the officialy accepted way of implementing ntfs is going to be via IFS.

[bluefoxicy]

FUSE is in any case just another FS API, with some extra magic on top (talking to a user space library). It's as difficult as writing another file system API-- which is to say, yes, it's difficult. I'm just saying, it only involves getting two pieces of code each designed to talk to each other to.. talk to each other. IFS wants to talk to a file system driver, and the FUSE libraries want to talk to a kernel wanting to talk to a file system driver. There's magic in the middle not happening (a file system driver that talks to IFS, and talks to FUSE, and makes the two play nice together), which is somewhat tricky. That particular magic doesn't involve delicate, complex, and difficult-to-test manipulation of an on-disk data structure, which I'd assume would be a hell of a lot harder.

[Haos]

Still, at the end of the line, FUSE expects Linux kernel, not NT. So its not just porting API, but whole of the structure.

[oiaohm]

Minor correction Fuse kinda needs Posix like OS to work well.

Fuse exists for a lot of OS's http://fuse.sourceforge.net/wiki/index. ... ingSystems Note a few windows ones are listed there.

Big problem lot of Fuse user space filesystem drivers also expect a Posix like OS so not one of the few different windows solutions work well at all.

This covers some of the differences http://pages.cs.wisc.edu/~driscoll/fuse-nt.pdf

bluefoxicy
[quote]That particular magic doesn't involve delicate, complex, and difficult-to-test manipulation of an on-disk data structure, which I'd assume would be a hell of a lot harder.[/quote] So close. It involves the delicate and complex to manipulate representation of a on disk data structure that happens to be incompatible. If it was not hard 1 of the 8 attempts would have done it by now.

[Z98]

So not surprised. The definition of most *nix devs of "cross platform" is it works well on *nix, nevermind whether it's suitable for Windows or not.

Hmm, a wisc address. Maybe I should pay more attention to what my school's CS department does.