Re: [Acpi] Re: ACPI fundamental locking problems

From: Jonathan Lundell <jlundell@pobox.com>
To: Alexander Viro <viro@math.psu.edu>,
	Jamie Lokier <lk@tantalophile.demon.co.uk>
Cc: Daniel Phillips <phillips@bonn-fries.net>,
	Jeff Garzik <jgarzik@mandrakesoft.com>,
	Eugene Crosser <crosser@average.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [Acpi] Re: ACPI fundamental locking problems
Date: Sun, 8 Jul 2001 09:46:18 -0700	[thread overview]
Message-ID: <p05100312b76e3e9b2e53@[207.213.214.37]> (raw)
In-Reply-To: <Pine.GSO.4.21.0107080320280.28651-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0107080320280.28651-100000@weyl.math.psu.edu>

At 3:26 AM -0400 2001-07-08, Alexander Viro wrote:
>On Sat, 7 Jul 2001, Jamie Lokier wrote:
>
>>  Daniel Phillips wrote:
>>  > > Reading a tarball is the distillation of what you describe into
>>  > > efficient form :)
>>  >
>>  > /me downloads tar file definition
>>  >
>>  > Um, gnu tar or posix tar? or some new, improved tar?
>>
>>  I suggest cpio, which is more compact and in some ways more standard.
>>  (tar has a silly pad-to-multiple-of-512-byte per file rule, which is
>>  inappropriate for this).  GNU cpio creates cpio format just fine.
>
>GNU cpio is a race-ridden unmaintained pile of junk. Look at the size
>of, say it, Debian patch to upstream source. Then try to read the
>patched code.  Quite a few of us simply don't have that FPOS on their
>boxen.
>
>Using cpio archive layout is OK, but _please_, don't make it dependent
>on GNU cpio.

If size is an issue (and of course it is), presumably the archive 
would be compressed. As long as tar can be convinced to pad with 
(say) nulls, the padding shouldn't have that much of an impact on 
archive size.
-- 
/Jonathan Lundell.