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

packaging a tiny/trivial blob in a DFSG-clean way?



In qemu package there's a source file, pc-bios/spapr-rtas/spapr-rtas.S,
which is an PPC assembly file with exactly 5 instructions:

#define KVMPPC_HCALL_BASE       0xf000
#define KVMPPC_H_RTAS           (KVMPPC_HCALL_BASE + 0x0)

.globl	_start
_start:
	mr	4,3
	lis	3,KVMPPC_H_RTAS@h
	ori	3,3,KVMPPC_H_RTAS@l
	sc	1
	blr

(it is "Trivial in-partition RTAS implementation, based on a hypercall").

This file is also included in the upstream source in compiled
form, as pc-bios/spapr-rtas.bin.  This is because it needs
ppc assembler to compile, and not every system out there has
this tool ready available.  The resulting .bin file is 20
bytes long, here's the disassembly output of it:

 objdump -b binary -m powerpc:common -EB -D pc-bios/spapr-rtas.bin

    0:   7c 64 1b 78     mr      r4,r3
    4:   3c 60 00 00     lis     r3,0
    8:   60 63 f0 00     ori     r3,r3,61440
    c:   44 00 00 22     sc      1
   10:   4e 80 00 20     blr


But qemu builds basically on all platforms, and on each platform
it runs, it needs this .bin file to run (emulated) PPC platform.

So we have the following options:

 1) package just this single file, of 20 bytes long, in a
   separate Arch:all package, in it's own separate source.

 2) drop ppc support where this file is required.

Neither of which appears to be good solution.

I think there's on other possibility.  But I'm not sure
whenever it can be considered DFSG-clean.

I can ship something like the above disassembly code,
and build the .bin file during package build time using
just hex tools, on all patforms.  The source and hex-binary
will both be platform-independent.  But on PPC platform,
at build time, I can actually build the .bin file using
the upstream method by calling real compiler/linker/objcopy,
and can compare the result with the result of processing
the hex-binary, and fail if they don't match -- this is to
catch changes in toolchain or the upstream source.

This way, due to trivial nature of the file, we can, with
grain of salt, say that the source is actually modifiable
using just the tools listed in Build-depends, in a form
of hand-crafted binary assembly.  If you know the assembler
(description of which is not listed as Build-depends!),
you can hand-translate a several-instructions-long program
from source into binary form by looking up assembly instruction
codes in the manual.

This is a bit of cheating, but I still think it is better
than to create a separate source package just with that
file.

Comments?

Thanks,

/mjt


Reply to: