[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Using "faked" for hostfs? (was: EasyMiNT / Aranym issues)



Hi,

On Friday 11 June 2010, Vincent Rivière wrote:
> Miro Kropacek wrote:
> > mint's unix stuff can't run from hostfs
> > entirely, I'm not sure whos fault it is but I tried to do exactly that
> > some months ago -- i.e. bootstrapped mintara.prg + whole filesystem on
> > hostfs. I came pretty far but then it failed either on some symlinks
> > or unability to create stuff like /pipe/log or so.

I see. Because Aranym doesn't store the extra file properties (access 
rights, owner, file type) anywhere, when you again access the same file,
things break.

To fix that, this information would need to be cought and stored somewhere,
also between Aranym runs.  That wouldn't necessary be that large thing to
add to the hostfs & Aranym.


When building packages, Debian uses "fakeroot" to simulate file operations 
that can be done only by root.  It consists of two parts:

1. fakeroot LD_PRELOAD library that overloads file operations and
    communicates about extra file properties with the fakeroot daemon.

2. Daemon that stores the extra file information.  It's supposed to be able
   also to save and restore this information between sessions, but I'm not
   sure how much that's tested (it's not needed to build Debian packages).

Maybe MiNT hostfs could catch same things as 1) and Aranym could then
use "faked", the fakeroot daemon process, for storing this information?

Btw. Because hostfs is a kernel feature, it can actually work much better
than  fakeroot library (LD_PRELOAD doesn't work with static binaries nor if
somebody clears the environment).


Or if faked daemon turns out not to be suitable for this, something even
simpler could be used.  Each directory could have some subdirectory which
Aranym hides from the emulated system (e.g. ".aranym.fileinfo") and which
contains one (maybe binary) properties file for each of the emulated files
in that directory.

This could be an interesting project for somebody.  :-)


> I use a minimal setup using a boostraped MiNT on hostfs and bash-only on
> the BIOS console, it works well.
>
> The RPM database can't live on an hostfs drive because it lacks some
> locking functions. So you can't use rpm on a fully hostfs system. I
> struggled a lot to understand that.
>
> ARAnyM use internal hacking with the contents of the symlinks (unlike
> NFS for example), I gave up trying serious things on hostfs (such as
> compiling).

Why compiling doesn't work on hostfs?
(That's exactly what was going to do after I've gotten everything set up) 

GCC should be creating just normal files, owned by the user, shouldn't it?


> When using ls, the number of blocks used by the files is incorrect. It
> seems there is a misunderstanding between
> MiNTLib/FreeMiNT/hostfs/ARAnyM. I started investigating that one day,
> but I didn't finished, since it is a minor issue.

hostfs should just get the file size and divide that with a fixed block
size (512 bytes?).  Trying to use host block information won't work,
especially if one's on host file systems which aren't block based...
(like e.g. JFFS2 and UBIFS)


> Some people will say things can't work correctly on Windows because of
> the case-insensitive filesystem, but since things work fine in Cygwin
> itself, I think it should work as fine in MiNT+hostfs.
>
> And finally, MiKRO, I think this is what you tried: copying a full
> EasyMiNT setup from FAT16/ext2 partitions to hostfs should work fine, it
> is a very realistic goal and testcase.

Yes, it working would really be nice...


	- Eero