tech-userlevel archive

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

Re: bsdcpio and bsdtar installed by default

On 5-Jun-08, at 12:39 PM, Christos Zoulas wrote:

By whom? Are you volunteering? Seriously it is not like our pax has the cleanest code. I have spent many hours debugging various problems in it
and I don't want to keep doing it. FreeBSD uses libarchive too, and it
is actively and well maintained. Plus you get the advantage of being
able to use the archiving API from other programs instead of needing to
invoke tar!

I'm all for good clean code that's actively and well maintained.

I'm also in full agreement that the current pax implementation is buggy and ugly and could have been replaced with any of many better implementations long ago. I too have poked around in it more often than I ever wanted to.

However I'm not so sure it's a good idea to use libarchive from programs that want to unpack things instead of invoking dedicated archive programs as separate processes, just as I'm not so sure it's a good idea to use compression and decompression APIs directly instead of starting separate processes running dedicated compression and decompression programs. Use of separate processes is even more important as multi-processor platforms become more common. Using LWP threads and library APIs for these purposes is possible I suppose, but I strongly object to using threads when they're not absolutely 110% necessary beyond any doubt. Vfork() and execv() are not the expensive operations here. We already have to maintain separate programs for such features anyway. We already need to have high-performance pipes too. The problems with threads are many and widely documented, even just within NetBSD's PR database alone.

                                        Greg A. Woods; Planix, Inc.

Home | Main Index | Thread Index | Old Index