Aha .. I understand. Still, starting with the oldest possible version might be the way to go to avoid being overwhelmed by Linux kernel dependencies.
But I may be wrong .. it'll get clearer when I can get the time to eyeball the code. WBR // Love On Tue, Apr 5, 2011 at 7:17 PM, Adam <[email protected]> wrote: > That's what I remember. I think it was originally JFS1 or something and it > became JFS later on. > > It was then made for OS/2 Warp and then it got open-sourced for Linux > distros. > > I could be wrong; but I am 98% sure I am correct about this. > > > On Tue, 05 Apr 2011 22:15:50 +1000, Love Nystrom <[email protected]> > wrote: > > You sure it was ported AIX -> OS/2, and not the other way around? >> >> WBR // Love >> >> On Tue, Apr 5, 2011 at 5:57 PM, Adam <[email protected]> wrote: >> >> AFAIK only NTFS has this root; JFS has been around for a while in the AIX >>> systems. It was ported to OS/2 Warp 4.5 later on. >>> >>> Well at least they're both better than all that >>> ext1/ext2/ext3/ext4/extπ/whatever gibberish. The biggest problem is (and >>> it >>> has actually happened to me before) these guys can run out of "inodes" >>> and >>> what not. >>> >>> >>> On Tue, 05 Apr 2011 19:40:09 +1000, Love Nystrom <[email protected] >>> > >>> wrote: >>> >>> Hi Adam, >>> >>>> >>>> Thanks for the pointer. >>>> JFS may be a viable alternative to NTFS indeed, they probably have the >>>> same >>>> root (HPFS)? >>>> >>>> The bulk of porting it to ReactOS will probably be "un-porting" it's >>>> Linux >>>> kernel dependency patches. >>>> I'm fetching the whole CVS repository from SourceForge right now, but >>>> I'm >>>> not sure when >>>> I will get the time to start eyeballing it .. I should be doing RL stuff >>>> today but find my butt >>>> glued to the chair again >>>> (Water_stoppage==Shower_impossible==I_refuse_to_go_public)! >>>> >>>> Peace >>>> // Love >>>> >>>> On Tue, Apr 5, 2011 at 3:02 PM, Adam <[email protected]> wrote: >>>> >>>> I would also recommend looking at porting JFS - the sources are >>>> >>>>> available. >>>>> This is the file system that IBM originally used in OS/2 Warp 4.5X (and >>>>> also >>>>> AIX if I am not mistaken) and is a very solid file system. Something >>>>> IBM >>>>> seemed to be doing right. >>>>> >>>>> I am not sure about all the details of it, but AFAIK it also supports >>>>> things like ACLs too. >>>>> >>>>> >>>>> On Tue, 05 Apr 2011 17:56:40 +1000, Love Nystrom < >>>>> [email protected] >>>>> > >>>>> wrote: >>>>> >>>>> Hi Bryan, >>>>> >>>>> >>>>>> Just like Aleksey, I would welcome an effort to simplify IFS >>>>>> implementation. >>>>>> >>>>>> Seen as NTFS is (and always will be?) not well documented, I've been >>>>>> thinking about >>>>>> supporting some alternative, OSS, journaling file system in ReactOS, >>>>>> e.g. >>>>>> ReiserFS, >>>>>> to allow us to provide the (relative) fail-safety of file transaction >>>>>> journaling that NTFS has. >>>>>> Also, hopefully, to enable us to implement NT's access privilege >>>>>> system (Security) on files. >>>>>> >>>>>> So far, it remains just a thought, since I can't allocate the time to >>>>>> adapt >>>>>> e.g ReiserFS to >>>>>> an NT IFS, and if I'm not mistaken, our IFS implementation has >>>>>> shortcomings >>>>>> of it's own >>>>>> which You may need to address as well in implementing Your proposal. >>>>>> >>>>>> In addition to "Windows NT File System Internals" I would also >>>>>> recommend >>>>>> "Windows Internals, 4th Edition" for additional/complementary insight. >>>>>> Especially Ch.12 "File Systems", but Ch.8-12 are all relevant, and the >>>>>> whole >>>>>> book is strongly recommended (by everyone, I think). >>>>>> >>>>>> It will be a BIG job I think (thesis big), and I hope You have the >>>>>> structural >>>>>> "common sense" to make it a success, and not a mess ;). >>>>>> It would be most welcome ! >>>>>> >>>>>> Comment Your code scrupulously :) >>>>>> >>>>>> Best Regards >>>>>> // Love >>>>>> >>>>>> On Sun, Apr 3, 2011 at 1:55 PM, <[email protected]> wrote: >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> >>>>>> From: Bryan Donlan <[email protected]> >>>>>>> To: ReactOS Development List <[email protected]> >>>>>>> Date: Sat, 2 Apr 2011 18:26:23 -0400 >>>>>>> Subject: [ros-dev] [GSoC] IFS wrapper project proposal draft >>>>>>> Hello, >>>>>>> >>>>>>> After reading the ReactOS GSoC ideas page, I became interested in the >>>>>>> IFS wrapper driver project idea[1], and would appreciate any comments >>>>>>> on my project proposal before I formally submit it. >>>>>>> >>>>>>> First, a bit about me. I am a student in a dual-major program, >>>>>>> studying Computer Science and Japanese at the University of >>>>>>> Massachusetts at Amherst. I have had some experience in kernel >>>>>>> development previously; as part of an internship at a research >>>>>>> project >>>>>>> at my University, I wrote some network flow analysis code running in >>>>>>> the Linux kernel. While filesystem work will be a first for me, I >>>>>>> think it will be an interesting leaning experience. I am fluent in >>>>>>> English and Japanese, and am in the UTC-0400 timezone >>>>>>> (TZ=US/Eastern). >>>>>>> My freenode username is bd_, and my myReactOS username is bdonlan. >>>>>>> >>>>>>> In preparation for writing this proposal, I obtained a copy of the >>>>>>> "Windows NT File System Internals: A Developer's Guide" book from >>>>>>> O'Reilly. Although a bit dated, it has been enourmously helpful in >>>>>>> helping me get an idea of what I'm getting into. >>>>>>> >>>>>>> My goal in this project will be to write a library to significantly >>>>>>> simplify writing a NT File System Driver. Although writing a >>>>>>> kernel-mode filesystem will never be as easy as with, eg, FUSE, it >>>>>>> should be possible to abstract away many of the idiosyncracies of the >>>>>>> NT filesystem API, at least. For example, the wrapper library may >>>>>>> handle: >>>>>>> * Automatically queueing asynchronous filesystem operations on a >>>>>>> worker >>>>>>> thread >>>>>>> * Parsing paths and invoking a FS-supplied traversal function for >>>>>>> each >>>>>>> directory element >>>>>>> * Interfacing with the NT cache manager, including flushing data from >>>>>>> the cache when a non-cached operation is performed on a cached file, >>>>>>> and establishing cache maps for the underlying device for a >>>>>>> disk-based >>>>>>> file system >>>>>>> * Providing a common implementation of byte range locks and oplocks, >>>>>>> and disabling fast I/O when they are in use >>>>>>> * Caching directory entry lookups >>>>>>> * Performing typical input validation/security checks needed by all >>>>>>> NT >>>>>>> filesystems >>>>>>> * Helper tools may also be provided to load pseudo-filesystems >>>>>>> (filesystems with neither network nor disk backing) on an ad-hoc >>>>>>> basis >>>>>>> >>>>>>> Essentially, the library should make it easy for the filesystem >>>>>>> designer to focus on the actual filesystem, rather than the NT IFS >>>>>>> interfaces - a read call would be able to skip all the preparation >>>>>>> and >>>>>>> checks, and directly go to perform the actual I/O. >>>>>>> >>>>>>> Major milestones for the project may include: >>>>>>> - Prepare a sketch of the API and callbacks for the IFS helper >>>>>>> library >>>>>>> (subject to change if necessary) >>>>>>> - Implement enough of the wrapper library to implement a simple >>>>>>> pseudo-filesystem demonstrating non-cached reads and writes >>>>>>> - Add support for cached reads/writes (interaction with the cache >>>>>>> manager, caching for on-disk metadata) >>>>>>> - Demonstrate a disk-based filesystem without metadata update support >>>>>>> (MINIX FS or FAT?) >>>>>>> - Demonstrate a disk-based filesystem with full read-write support >>>>>>> - If time allows, add support for ancillary features, such as byte >>>>>>> locks, oplocks, and notify watchers. >>>>>>> >>>>>>> The interfaces exposed by the filesystem library will of course be >>>>>>> clearly documented. Filesystems needing more advanced support will >>>>>>> also be able to override any IFS callbacks they choose. >>>>>>> >>>>>>> I have an existing consulting commitment that will take some of my >>>>>>> time, but I expect to be able to put in 20-30 hours of work per week >>>>>>> into this project. Further, I hereby swear that I have not used nor >>>>>>> seen the source code to any version of the Windows operating system >>>>>>> nor any Microsoft product that may be related to the proposed project >>>>>>> that is under a license incompatible with contribution to ReactOS, >>>>>>> including but not limited to the leaked Windows 2000 source code and >>>>>>> the Windows Research Kernel. >>>>>>> >>>>>>> I would appreciate any comments on my proposal before formally >>>>>>> submitting it to the GSoC site. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bryan Donlan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>>>> >>>>> >>>>> >>> -- >>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>> >>> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
