[patch] size optimization for mkswap.c

Bernhard Fischer rep.nop at aon.at
Sat Mar 18 12:04:42 UTC 2006


On Thu, Mar 16, 2006 at 09:39:47PM -0500, Rob Landley wrote:
>On Thursday 16 March 2006 9:02 pm, Bernhard Fischer wrote:
>
>> Still experimenting with this and the needed follow-up bits.
>>
>> We will no longer give useful information *why* we refuse to creat a
>> non-conforming area, iff we go down that path. Initially, i intended to
>> keep the UI differences as few as possible, but if we drop v0 support
>> for busybox-1.2 all at once, i tend to agree that we can favour size
>> over usability as far as error checking is concerned there.
>>
>> i.e.: From now on, there will be *no* verbose error if the user requests
>> -) to create a device with less than 10k size
>> -) to create a device bigger than the available total size
>
>The common case is "mkswap device" or "mkswap file".  Specifying the size 
>isn't often done (no point), so I'm not too worried about the error message 
>for that being bad.

ok.
Moving to bb_xgetlarg basically means we have to drop (ignore) -f(orce)
support, as we check inside bb_xgetlarg if the blocks given are within
range and die if they are not. Just as a side-note.

>
>> -) thus we can as well drop -force support except for sparc.
>>
>> Although i don't use it, i think that we may want keep the support for
>> sparc et al, as it does not pessimize e.g. the x86 code, so it's of no
>> benefit to cripple the implementation.
>
>I have no idea what the issue with sparc is.

Not an issue anymore. All is well.
>
>> One point eventually worth a hint is whether we should support
>> swap-areas with HOST_WIDE_INT (or however it's called ) or not.
>
>What's the issue here?

For me, our current version cannot deal with swap-areas larger
than 2G.




More information about the busybox mailing list