[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] New Year's starting over ... bsd-user
From: |
Sean Bruno |
Subject: |
Re: [Qemu-devel] New Year's starting over ... bsd-user |
Date: |
Thu, 5 Jan 2017 08:57:01 -0700 |
User-agent: |
Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
On 01/05/17 04:33, Peter Maydell wrote:
> On 3 January 2017 at 16:18, Sean Bruno <address@hidden> wrote:
>> I'm pondering where to start with getting FreeBSD's bsd-user code into
>> shape so it could actually be reviewed and accepted now that its sort of
>> working again (signal handling fixed finally).
>>
>> I almost feel like the existing code should be purged, except that it
>> gives a good history (and this seems lazy to me).
>>
>> As a first pass, I guess, I'd like to at least make i386 user run on
>> x86_64. What would you folks like to see in a first pass?
>
> So, here's my thoughts on this. I think our goals here are
> * get the out-of-tree code into the tree, over time
> * help you get to a point where you're maintaining and fixing
> the FreeBSD code with us upstream, rather than deploying
> downstream patches
>
> and the primary obstacle is this big pile of non-upstreamed
> code. From my end I don't think it really matters too much
> what order we try to tackle things in, as long as the chunks
> that arrive for upstream review are not too large and seem at
> least vaguely coherent. If i386-on-x86_64 seems like you can
> extract it sensibly then I think it's as good a place to start
> as anything else (though of course it's of pretty much zero
> practical utility :-)).
>
Its a good-enough place to draw a line. Its just an arbitrary point
that I chose.
Let me see how gruesome the patchset would be from the branch that I
created the other day.
> Whether you want to keep the sparc support or delete it is
> I think up to you as the maintainer -- if it's broken and
> nobody cares about it I think we can happily delete it.
> On the other hand if you want to fix it up and keep it around
> then that's fine too.
>
I'll table this point for after we are merged up.
> At some point it would be good to get the BSDs into the set of
> things we test when merging code, so we don't regress them.
> That would ideally require hardware we can access though (the only
> real-hw setup in the gcc compile farm is an ancient NetBSD
> 5.1 install). I guess instructions-for-BSD-novices on how to
> setup a VM on a Linux box would do in a pinch.
>
> (We should also try to avoid breaking bsd-user on the other
> BSDs in the course of fixing up FreeBSD -- do you know how
> many of the other BSD hosts work right now?)
>
AFAIK, its only FreeBSD that has interest in keeping bsd-user
maintained. OpenBSD isn't super interested in this application and
NetBSD has their own way (pkgsrc) to cross compile for other architectures.
sean
signature.asc
Description: OpenPGP digital signature