cpio: need to fix this

Fri Sep 2 07:09:10 UTC 2005

On Thu, 2005-09-01 at 17:51 -0500, Rob Landley wrote:
> On Thursday 01 September 2005 10:19, Charles C. Bennett, Jr. wrote:
> > Hi Rob -
> >
> >  The thing that was there didn't do anything except throw up it's hands
> > and give up.
> >
> >  Let me put together some analysis to show you what this will actually
> > cost you.  Note that it's quite a bit tighter than what exists in the
> > GNU cpio code to solve the same problem.
> 
> I can certainly believe that. :)
> 
> I'm not against it, and I'd love to see the analysis.  Mostly I'm thinking 
> this is big enough that it should probably have its own CONFIG_FEATURE to 
> chop it out for those who don't need it.
> 
> I'm also curious if there's a way to put it into the shared archive 
> infrastructure, although my one look at the shared archive infrastructure so 
> far involved me making up a patch to delete two files that had no reason to 
> exist.  (And I may just go ahead and apply that if nobody comments on it for 
> long enough.  That's the easy way to get feedback... :)
> 
> Rob

OK...  so I don't know squat about the shared archive infrastructure.  I
did get a look at how busybox tar is dealing with hard links (snicker).
This patch applies to libunarchive/get_header_cpio.c which quite cpio
specific.

I can't imagine someone building cpio into busybox and *not* wanting it
to be able read any and all valid archives....

My initial patch added 320 bytes to the .text segment of the busybox
configuration I build for the appliance I'm working on.  I noticed that
the file_header_t already has a copy of a dev_t with the major and minor
info that I needed in it so I yanked those out of the hardlinks_t.  I
see that xmalloc already checks malloc returns so I stopped checking it
myself.  The free code was in there in two different places so I moved
it out to a function call.  I was copying the link_name when it was
sufficient to just point to it....

Although it looks big I now have code that is necessary and sufficient
to implement hard links as encoded in newc and crc cpio archives.  And I
do it in 224 bytes of code (additional .text) on i386 gcc4.  The heap
overhead per link a fixed 48 bytes (16 byte hardlinks_t plus a 32 byte
file_header_t) and a copy of the filename, variable at runtime.

I looked at doing the implementation of the list operations using
recursion but it did not reduce code size and probably had an adverse
effect on the stack.

   text    data     bss     dec     hex filename
1050315    5816  215416 1271547  1366fb busybox
1050635    5816  215416 1271867  13683b busybox.patch1
1050539    5816  215416 1271771  1367db busybox.patch2

Look closely.  At least for my application, the new code is an increase
of 2 one hundredths of one percent of the overall size of busybox.

No, let's do this...  I've built busybox with everything except cpio
turned off:

   text    data     bss     dec     hex filename
 484546    3028    7080  494654   78c3e bbcpio
 484770    3028    7080  494878   78d1e bbcpio.patched

If all you wanted was a busybox version of cpio that did absolutely
nothing else, you pay an extra 0.04% to get hard link support.

I've attached the new patch.  Attempting to shave it any tighter
probably brings us up against the law of diminishing returns.

ccb

-- 
Charles C. Bennett, Jr. <ccb at acm.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-hardlink.patch
Type: text/x-patch
Size: 5388 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20050902/9ffe4daa/attachment.bin 