[Top][All Lists]

[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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]