[ros-kernel] ROS NTFS Install

[Digital Infra, Inc.]

Hello ROS developers.


As Mike Nordell wrote, this is just a starting point.
but I am happy that probably ROS guys seem to admit a loop back way as one option.
Thanks!.

First of all, the fundamental problem is, you dont know loop back tech,
and I am not sure about freeldr.
how about installing a loop back something?
my recommendation is topologi Linux.
URLs from my previous post is this:
>
>Topologi Linux - Slackware without splitting your HDD.
>  http://www.topologilinux.com/
>MLD Linux - another loop back Linux. Japanese commercial software.
>you can download trial version from the company's ftp site.
>  http://www.mlb.co.jp/linux/support-mld7/hwtest.html
>  ftp://www.mlb.co.jp/pub/linux/mld7/mld7hwtest.exe
>

Second, I think using NTLDR to boot ROS/conoppix is better than
making freeldr to recognize a boot image on NTFS directly.
because, anyway, and someday, you have to understand what NTLDR does to boot Windows.
and when once you did it, it is not difficult to make a vmlinux which pretends to be
nearly same behavior as loader part of ntoskrnl.exe.
in other words, to boot vmlinux on NTFS from NTLDR, it needs just
understanding what NTLDR does, not big hacking.

and once vmlinux runs from NTLDR, you can run ROS from linux with
same stuff like loadlin.exe or kexec.
NTLDR -> ROSloader.exe ( acts same as ntoskrnl.exe ) -> vmlinux
      -> loadROS.elf -> ROS.
a little bit complicated, but very versatile way.
you can apply this tech to other areas.
ex, MBR -> GRUB -> vmlinux -> loadROS.elf -> ROS, or
vmlinux -> loadROS.elf -> |NFS| -> ROS on a file server,  etc.


and some of you get wrong with a loop back tech.
I will make it clear -- it does not need Windows, nor ntfs.sys,
nor details of ntfs format.
it does not need even writing ability to NTFS.
what it needs is, only telling a sector mapping of a virtual partition file.
actually , I have succeeded to write any fs (ext3, raiser, JFS,,,) to NTFS virtually.
It writes c:/conoppix/virtualdisk.4GB or such on NTFS, with current Linux NTFS driver.

            --- Okajima.


>Rick Langschultz wrote:
>
>> I don't think having react os installed in a loop back filesystem would
>> be feasible because of the vast amounts of memory that NT can
>> take just serving up web pages, files, and users.
>
>That's not an issue. The problem is how to get such a filter driver loaded
>early enough to start acting as the boot-disk driver for the OS, but late
>enough to be loaded after the real disk and FS driver.
>
>Throw in very early access required for a registery hive and the need to
>modify freeloader to be able to do this, and you might appreciate the real
>issues. The memory requirements is of no matter - they'd be less than a few
>hundreds of KB.
>
>But this isn't really touching the issue of NTFS, which is the subject of
>this post, so let's move on to that one...
>
>[snip]
>
>> And the ntfs will be very hard to implement considering the
>> fact that it is a fairly new fs that always is changing whenever
>> M$ wants to change it.
>
>It's over a decade old, so its age surely isn't the problem. As for the
>"moving target", the core of NTFS hasn't changed that much since NT 3.1.
>Actually, I don't think the core of it has changed at all. The real problem
>is that NTFS isn't fully specified, and there is no free reference
>implementation of it. Almost anyone can write code to read NTFS, it's the
>writing that is causing troubles (more precise; allocating new files, and to
>a lesser extent writing of compressed files).
>
>But back to what Linux/*nix users call a "loopback" device/driver (which in
>NT-speak is the interface for 127.0.0.1, which is not related), and how such
>a thing could/would work to be able to make an image file on an existing FS
>the boot disk of ROS.
>
>System binaries needs a place to be stored. As the purpose is to make a
>single file present itself as a bootable disk, the obvious choice would be
>to store them in the image file just as they are today. An added benefit is
>that current tools would still work with this (e.g. mtools), since the disk
>image would be no different in layout than a plain Bochs/QEMU image file.
>
>Freeloader needs to be able to read these files, to be able to start the
>system. Ergo, freeloader needs to be made aware of such an image file. If
>the image file was stored on FAT it wouldn't be much of a problem, since
>freeloader already understands FAT. It would only be a matter of turning one
>call into another recursion.
>
>Today: open and read e.g. ntoskrnl.exe -> FS driver -> disk.
>Tomorrow (to get this working) it would have to become:  open and read e.g.
>ntoskrnl.exe -> FS driver -> emulated_disk -> FS driver -> real_disk.
>
>As is obvious, to get it working if the image file is placed on an NTFS
>partition, freeloader will have to gain a working (basic) knowledge about
>NTFS.
>
>But this is only the beginning of the problems. Once the OS is loaded into
>memory there would have to be a driver in ROS that:
> 1. Presents itself as a disk, so that the OS can mount the boot FS.
> 2. Uses an existing FS driver, or in the *really* Q&D case has its own
>minimal FS built-in (*) and directly uses the disk driver for the real disk,
>to be able to locate and use the image file.
> 3. Preferrably hides the existing hardware partition (or even disk), at
>least initially.
>
>(*) This would for NTFS _not_ have to be a fully working FS driver. It would
>only have to be able to do lookups of a named file, and be able to map a
>virtual block (in the image file) to a physical block of the disk, basically
>sharing the exact same functionality freeloader would require anyway.
>
>That would obviously not be all - the startup code of ROS would have to be
>modified to also know about this scenario, f.ex. to be able to load the
>registry hive - but I hope this post serves as a starting point of what is
>required and how to do it.
>
>/Mike
>
>_______________________________________________
>Ros-kernel mailing list
>Ros-kernel at reactos.com
>http://reactos.com/mailman/listinfo/ros-kernel
>