On 16 Aug 2009, at 21:16, Paul H. Hargrove wrote:
[snip]
I'll keep that info around for anyone else who asks about other
architectures.
Regarding the question of *BSD or Hurd (ignoring that "L" in BLCR
stands for Linux):
While I don't want to totally rule-out the possibility, I doubt
that porting to another OS is an easy task. Counting only arch-
independent code here are about 14,000 lines in cr_module and over
2,000 in vmadump_common.c. I can identify less than 1,500 of those
lines as doing something OS-independent; the rest is all dealing
with Linux kernel data structures. So, to be honest I think if
somebody were to "port" BLCR to another OS they will have earned
the right to name their package something else if they want.
It would be handy for me as a developer to have the same libcr
interface on hurd and *bsd platforms for checkpointing features
should any hurd/BSD developers end up reading this. Might make an
interesting project for a suitably motivated student I guess too, so
I might see about adding it to the list of suggested projects.
Alan,
I the interest of the least confusion among potential users, I do
think marking the package as arch-specific (i386, amd64, arm, ppc,
ppc64) and os-specific (linux) is the best practice. Users who
want BLCR for unsupported arches will probably still ask "why is my
arch not supported?". If/when a future release adds arches, then
the arch-specific list can expand, right?
That is correct, the architecture list can be amended with every
upload that is made. (Correcting it would be a valid reason to make
an upload). From the point of view of an end user it doesn't make any
difference whether the architecture list says 'any' or just the ones
it's known to work on. Debian users only get to see packages that
have correctly built for their architecture in this list of available
packages unless they're explicitly looking for source, in which case
they might be inclined towards porting it. They should also get
marked 'Not For Us' at some point which stops the load on the build
system too.
From my POV the most useful feature of having it listed as 'any' to
start with is that the port maintainers get to see it failing in the
automated build system. I suspect these are also the people most
likely to have time and inclination to add support for their
architecture.
A (limited) survey of existing modules suggests this seems to be the
approach taken by most kernel modules except those that rely on
binary blobs. Since this doesn't impact users at all (only developers
and mostly porters) and given that configure fails reliably and
cleanly I don't think there's too much point changing this.
Alan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
