From: Alan Woodland (ajw05_at_aber.ac.uk)
Date: Mon Aug 17 2009 - 04:23:44 PDT
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