From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Murray <murrayie@yahoo.co.uk>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: Xen 4.3: x86 32 bit code removed or depreciated?
Date: Wed, 10 Jul 2013 14:15:26 +0100 [thread overview]
Message-ID: <51DD5E6E.2060401@eu.citrix.com> (raw)
In-Reply-To: <1373461460.47805.YahooMailNeo@web171302.mail.ir2.yahoo.com>
On 10/07/13 14:04, Ian Murray wrote:
>
>
>
> ----- Original Message -----
>> From: George Dunlap <George.Dunlap@eu.citrix.com>
>> To: Ian Murray <murrayie@yahoo.co.uk>
>> Cc: Jan Beulich <JBeulich@suse.com>; xen-devel <xen-devel@lists.xen.org>
>> Sent: Wednesday, 10 July 2013, 12:28
>> Subject: Re: [Xen-devel] Xen 4.3: x86 32 bit code removed or depreciated?
>>
>> On Wed, Jul 10, 2013 at 12:18 PM, Ian Murray <murrayie@yahoo.co.uk> wrote:
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Jan Beulich <JBeulich@suse.com>
>>>> To: Ian Murray <murrayie@yahoo.co.uk>
>>>> Cc: xen-devel <xen-devel@lists.xen.org>
>>>> Sent: Wednesday, 10 July 2013, 11:34
>>>> Subject: Re: [Xen-devel] Xen 4.3: x86 32 bit code removed or
>>> depreciated?
>>>>>>> On 10.07.13 at 12:23, Ian Murray
>> <murrayie@yahoo.co.uk>
>>>> wrote:
>>>>> I have seen in various places that x86 32 bit support would be
>> dropped for
>>>>> 4.3 and the only mention in the release material is a one-liner in
>> the
>>>> "Xen
>>>>> 4.3 Feature List" in the wiki
>>>>>
>>>>> * Remove 32-bit and ia64
>>>>> I know a lot of code was removed for ia64 because there are
>> comments to the
>>>>> effect in the commit statistics, but no mention of 32-bit/x86.
>>>>>
>>>>> Has the code been actively removed, or is still there but
>> depreciated?
>>>> I'm sorry, but why do you ask here rather than checking the sources
>>>> (xen/arch/x86/x86_32/ is gone, just to name a simple and obvious
>>>> example) or the commit log (5d1181a5 "xen: Remove x86_32 build
>>>> target." is pretty explicit I would think).
>>> Apology accepted. :)
>>>
>>> You assume that I am fully familiar with the source layout to know what is
>> missing and that I possess more than rudimentary git skills or am experienced
>> enough to know the exact search terms that would yield results. Well, I am not
>> and I don't.
>>> Yes, I could have discovered this myself, but it would have taken me some
>> time to arrive at a definitive answer (as I am no expert) and I thought it
>> quicker and not too onerous on other people to ask the list; Sorry, if that
>> wasn't the case for you. You didn't have to "waste" your time
>> answering me and I am sure it took more time to back up your complaint than a
>> simple "yes" or "no", but thanks for the answer to my
>> question. I do appreciate it. Unfortunately, nobody pays me to sit and look at
>> Xen source code, so I have to do it outside of my day job.
>>> Of course, I did look in the release notes which is where it *should be*
>> but IMHO those release notes look more like marketing spiel than anything useful
>> technically.
>>
>> I think that's a bit unfair. The release notes page is 1/3 new
>> features, 1/3 comment on the change to installing in /usr/local/ by
>> default (technical) and 1/3 known issues, which are also very
>> technical in nature. Even the new features contain a lot of
>> techinical links: how to switch to the old qemu if you have problems,
>> how to use the new multiple USB device feature, and links to how to
>> set up openvswitch on your system.
> Yes, it probably was a bit unfair. Sorry. I was in a bad mood by that point and it was a bit off-the-cuff. ;) It's probably because a few media sites have been quoting it verbatim, rather actual content
Reporters are pretty lazy. :-) If you make an announcement and write it
in the form of the article you want published, many news outlets will
just take what you wrote and publish it unchanged. One of the reasons
for having the release notes be part marketing is so that we can
influence what people say in the announcements. If it's ready to be
quoted, then reporters will often just copy it or quote it verbatim; but
if it's not, then who knows what they'll come up with (if they say
anything at all).
Obviously there's a balance to be struck there, but I think we didn't do
too badly.
-George
next prev parent reply other threads:[~2013-07-10 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 10:23 Xen 4.3: x86 32 bit code removed or depreciated? Ian Murray
2013-07-10 10:34 ` Jan Beulich
2013-07-10 11:08 ` Matthew Daley
2013-07-10 11:21 ` George Dunlap
2013-07-10 11:10 ` George Dunlap
2013-07-10 11:28 ` Ian Murray
2013-07-10 11:32 ` George Dunlap
2013-07-10 12:03 ` David Vrabel
2013-07-10 12:44 ` Ian Murray
2013-07-10 11:18 ` Ian Murray
2013-07-10 11:28 ` George Dunlap
2013-07-10 13:04 ` Ian Murray
2013-07-10 13:15 ` George Dunlap [this message]
2013-07-10 14:42 ` Pasi Kärkkäinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51DD5E6E.2060401@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=murrayie@yahoo.co.uk \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.