Re: [Xen-devel] Upping gcc requirement for x86

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 3/30/18 11:37 AM, George Dunlap wrote:
> On Fri, Mar 30, 2018 at 5:11 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote:
>> On 3/30/18 3:50 AM, George Dunlap wrote:
>>> On Thu, Mar 29, 2018 at 6:47 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote:
>>>> On 3/29/18 12:05 PM, George Dunlap wrote:
>>>>> On Thu, Mar 29, 2018 at 4:45 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>>>>>
>>>>> Long term I think we want to get away from building seabios ourselves
>>>>> altogether; but it's a bit late in the release cycle to work out that
>>>>> kind of change.
>>>>>
>>>>> On the whole I'd probably go with #3 at this point.
>>>>>
>>>>>  -George
>>>>>
>>>>
>>>> Violent agreement here. Every distro wants to see this so they can share
>>>> these blobs. Its what lead to the change to tracking tags in
>>>> 3dd926a25d866364ce6d46c21f9ac05a82fa7ffb originally.
>>>
>>> I don't understand what you mean -- AFAIK there's no *dependency* from
>>> Xen to any particular version of SeaBIOS (unlike QEMU).  If 1.9 won't
>>> compile with gcc 4.4, but 1.8 does, we can just point the tag to 4.4.
>>> Distros will be compiling their own SeaBIOS versions anyway, no?
>>>
>>> Or am I missing your point somehow?
>>>
>>>  -George
>>>
>>
>> My point was we explicitly moved to testing/shipping tags so that we
>> distros could say "oh this is what the Xen folks tested with I have
>> confidence that if we ship the same version it should work for users".
>>
>> I think we want to get away from building it ourselves and defaulting to
>> telling distros they need to provide it.
> 
> Those seem like sort of contradictory goals to me, particularly if the
> goal of a distro is to share seabios between KVM and Xen.

Hardly. Back when I was more active in packaging bits I would have liked
to see that as I likely would have used that as a baseline.

> 
> FWIW for the CentOS Virt SIG, I
> * build seabios separately
> * Only update when the version in "CentOS core" (i.e., RHEL) is larger
> than the version I've built
> * Then just pull the latest package from Fedora.

I've always built SeaBIOS separately on Gentoo and for as long as I've
touched recipes in Yocto. I've also built it separately at various
employers. QEMU and Xen then depended on that separate build.

> 
> The only reason I build a separate one at all is that the one in
> "CentOS Core" seems to have some KVM-focused patches which break it
> under Xen.  In an ideal world I would get that fixed and just use the
> seabios from the base version of the OS -- the same as I would any
> other library.
> 
> If we want distros to build their own version of seabios, we should
> also decouple the expectation that a given version of Xen matches (or
> needs to match) a given version of seabios.

Hence my point of test against a baseline everything newer is suppose to
be compatible as they aren't removing existing Xen functionality.

> 
> AFAIK this decoupling has already taken place, it's just that nobody
> knows about it.  seabios-master has been tested with Xen for ages, so
> all versions of seabios released in the last several years should Just
> Work>
> That's why I said to downgrade to 1.8 in our builder -- because I
> expected distros to ignore that value and use 1.10 or whatever the
> newest version is anyway.
> 
> Are you aware of any seabios / Xen dependencies -- particular versions
> of vanilla seabios that don't work with particular versions of Xen?
> 

There have been a few over the years. I can't explicitly enumerate them
but they've usually been .0 releases.

-- 
Doug Goldstein

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel