Re: blcr: Support for more arches.

From: Alan Woodland (
Date: Mon Aug 17 2009 - 04:23:44 PDT

  • Next message: Alan Woodland: "Fwd: Bug#542643: Does not build with 2.6.30-1-686"
    On 16 Aug 2009, at 21:16, Paul H. Hargrove wrote:
    I'll keep that info around for anyone else who asks about other  
    >  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  
    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.

  • Next message: Alan Woodland: "Fwd: Bug#542643: Does not build with 2.6.30-1-686"