AROS Arix/Filesystem

Requirements

• (A) It should be possible to install AROS on hdd/usb using InstallAROS in exactly the same manner as on pc-i386
• (B) It should be possible to use all software that manipulates disk structure (i.e. HDToolBox)
• (C) It should be possible to reuse as much as possible the existing AROS code base
• (D) It should be possible to utilize Linux ATA/SATA support to support all Motherboards that Linux supports
• (E) It should be possible to utilize Linux file system support to support partitions with file systems that Linux supports
• (F) It should be possible for newly inserted medium (CDROM, USB, etc) to be automatically visible in AROS without user interaction

Are A,B,C in oposition to D,E?

Solutions

S1: ata.device-like shim over Linux kernel and AROS file systems

Description:

ata.device-like shim communicated with /dev/ node that exposes functions needed by ata.device interface. Most probably it requires writing some linux-side code for exposing ata functions. Linux kernel needs also to be modified to disable "partition detection" after the initial mounting of AROS partition, because we don't want Linux kernel to handle partition at the same time as AROS would be doing it.

Advantages:

• It it known what needs to be implemented
• Integration at low level allows for A, B, C and D

Disadvantages

• Not possible to implement E
• Modifications needs to Linux kernel

Questions:

• What will Linux kernel do in such setup when someone inserts a pen driver? Will this count as disk as will be handled by ata.device-like shim or will such action be invisible to AROS?

S1.a: linuxfs-handler

• C:Mount supplies the Linux FS type to use (ext3, jffs, etc) via the CONTROL parameter.
• Handler translates the DOS device (ie DH1:) to a mount of the desired filesystem using the '-o loop,offset=XXXX /dev/sda' method (Linux doesn't need to know about partitions)
• Handler translates DOS packets into Linux read/write/etc syscalls to the Linux filesystem

S2: "insert" partitions into AROS when Linux kernel detects them

Description:

We let Linux detect new partition and send UDEV event about it. AROS captures that event and access the partition using emul-handler file system.

Advantages:

• Integration at medium level allows D and E
• AROS sees all partitions (HDD, CDROM, USB, Network?) with single approach

Disadvantages:

• Solution does not allow A
• Not yet known how to implement

Questions:

• We don't want those partition to be mounted in the initrd file system. In that case is it possible for emul-handler to work at all?

S3: ata.device-like shim over Linux kernel and AROS file systems, but AROS "returning" control to Linux if no native systems found

Description:

Solution S1 with fallback. If AROS does not know how to handle a certain file system, a signal is sent to Linux kernel to handle it. Then UDEV event is captured by AROS and the partition is mounted using emul-handler.

Advantages:

• Allows requirement E for reading/writting

Disadvantages:

• Not known how to implement
• Modifications needed to Linux kernel