[Bug 1532] Review Request -- First Test of Loading tarfile info IMFS

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1532





--- Comment #18 from Ralf Corsepius <ralf.corsepius at rtems.org>  2010-06-11 03:34:38 ---
> Chris came up with the objcopy way of doing this.
So why add it?

> I had never managed to make it work across targets reliably.
This doesn't surprize me ... a "can of worms" in action ;)

>  Blob -> .c/.h -> .o via reasonably normal makefile rules.
Yes, this approach is much more portable. Whether rtems-bin2c in its present
shape is ideal for this, is a different topic. A pure script would certainly be
superior. 

> On a move general note, we have been dependent on tar for a LONG LONG time.
> I don't recall anyone ever having an issue. 
Well, ... what shall I say. 

May-be RTEMS user base is to small, may-be nobody noticed the issues lurking,
may-be the test cases are too primitive, may-be everybody is using gnutar?

May-be currently nobody is using one of the broken versions of "tar" (I don't
recall when, but some years ago, gtar has had such kind of bug. IIRC, it had
renderd old SunOS generated tarballs unreadable under Linux).

There are easy ways to trigger such issues (exceed the limitations of ustar):
Create a tarball containing a deep hierarchy of directoriesm, extra long files
names in a non ASCI locale, as "root". 

To furtherly complicate the situation, consider adding "special" files (e.g.
devices, such as /dev/hdx) to a tarball - A standard tar will not be able to
extract these tarballs correctly (A real world example for a usecase of this is
the *BSD tarballs. Standard gtar doesn't extract them properly). 


> "tar cf XXX files is the command
> to use.  We only support symlinks, regular files and directories on
> uncompressed files.

> The case insensitive issue on MacOS is something we have to avoid on the host
> side to prepare test cases.
And ... availabilty of symlinks on the host;) 
(Does Mingw/Cygwin meanwhile have a working ln -s?)

> Perhaps we need to split into 3 PRs:
Agreed.

> + testing untar (my immediate goal)
Easiest approach: 
Add *.c/*.h containing a "hex'ed" version of a tarball (e.g. rtems-bin2c
generated versions).

> + tar requirements (verification, etc)
> + preferred technique for binary blob -> .o conversion


> But right now whether we do the others perfectly or not, the test has an
> issue I was hoping Chris could spot. :)
There are further issues, besides those already mentioned with this patch.
E.g.: the source tree needs to be considered "read-only"
=> Normal "configure" or "make" processes must not write to it
(c.f. the rpcgen case - This is similar)

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.