AMD 64 support
Mike A. Harris
mharris at redhat.com
Wed Nov 5 11:48:27 UTC 2003
On Mon, 3 Nov 2003, Mike Snitzer wrote:
>> I wouldnt say that... people are working on an AMD64 fedora currently.
>
>Sure, I'd imagine (based on previous mails you've sent) you are
>one of those people. But the fact remains that RedHat Inc. has
>full-blown support for a native x86_64 install in RHELv3; yet
>they haven't said a word about offering that technology to
>Fedora. This is quite likely by design as they want to see the
>financial fruits of all their effort before giving it away to
>the community they are fostering.
Quite to the contrary. When asked, we always respond, just as I
am right this second. Our website also I believe contains
comments about possibilities of other ports.
Red Hat Linux has not had non-x86 ports for a long time now.
The last non-x86 port was Red Hat Linux 7.2 for Alpha and IA64.
Back in those days, ports to other architectures were done after
the main x86 port was done, and were done under contract to a
given hardware vendor or various vendors. Red Hat has never to
my knowledge produced the operating system for non-x86 processors
except under contract with a vendor who produces systems for the
given processor. While x86 is the mainstay, non-x86 processors
have traditionally just not been a viable profitable platform to
develop the OS for without partnerships and contracts to do the
work in order to make it worthwhile.
Red Hat Linux 9 development was the beginning of our quest to
build our OS simultaneously on all architectures we had contracts
to produce *some* product for. As such, starting then, and ever
since then, we have compiled all of our software on the following
processor platforms:
x86
AMD64
ia64
ppc
ppc64
s390
s390x
x86 is our flagship architecture due to it's obvious large
commodity status, so that is always done. All other
architectures are produced under contract with particular
vendors. We compile all of our software on all 7 architectures
religiously now in order to make things at least compile always
wether a given product we're doing will actually ship on that
architecture or ever be supported. This is because it is
somewhat easier to just keep everything building across the board
always, than it is to come back and roll a special port for a
given architecture down the road.
It also helps to keep the software of higher quality all around
because of the 7 architectures, we have 32bit little endian
(x86), 64bit little endian (ia64, AMD64), 32bit big
endian(ppc,s390), 64bit big endian(ppc64, s390x) completely
covered, maximizing portability between different endianness, as
well as architecture specific problems. This also helps to find
compiler and other toolchain problems much easier. A given
problem might only trigger on a particular architecture, but
might actually be a problem on all architectures. The more
architectural coverage that is seen by the code, the cleaner and
more portable the entire distribution becomes.
However, making sure all rpm packages compile on all 7
architectures is only one part of producing a Linux distribution.
Certain packages require architecture specific work, and that
might require a lot of developer attention in order to fix
problems that arise and are architecture specific. Also, special
features we develop on x86, would need to be ported to the other
architectures in question also, such as NPTL, exec-shield, and
other things. This requires massive kernel engineering time
commitment, glibc engineering time, gcc, XFree86, and other
hardware and toolchain related development. It isn't a small
task, and it doesn't come for free.
Our goal for Fedora Core was to produce an x86 distribution,
similar in nature to previous Red Hat Linux distribution
releases. Aside from that specific goal, another goal was to
continue with our goal to always build on all architectures, so
that the distribution is always as clean as possible. However
there never was a plan to officially release the distribution for
other archtectures than x86.
That doesn't in any way mean that Red Hat does not want to see
non-x86 distribution ports happen. It means that non-x86 ports
were not official Fedora Core 1 project goal targets, and that
aside from making sure all packages build cleanly on all
architectures, there hasn't really been any architecture
specific work done, except more or less on a voluntary basis by
particular developers interested in investigating a problem on a
given non-target arch, or problems that occured in RHEL testing
and got fixed in RHEL, and thus also in Fedora Core.
>RedHat employees have said they openly encourage people to port
>Fedora to other architectures.
Absolutely. And many of us here _at_ Red Hat are some of the
people who will be doing that work ourselves as volunteers. I
for example am interested in making Fedora Core a reality on
AMD64 and Alpha processors. There are a large number of other
engineers here willing to volunteer to make that happen also.
>So the fedora community can take Fedora where they want it to
>go; but RedHat likely won't act as the catalyst for things like
>an x86_64 port.
Well you're very wrong there I'm afraid. Very. Non-x86 ports
are going to be definitely volunteer driven. That doesn't mean
they'll have to be done outside Red Hat at all. It does mean
that when we put in our 8 hours of time at work here, we wont be
spending much if any of that time on non-x86 ports of Fedora.
However we don't put in 8 hour days at Red Hat now do we. ;o)
We need to have some time ourselves to volunteer to do some of
the things that need to be done. The most major thing for each
architecture without question, is the kernel. The kernel needs
work done for every architecture, and that is a LOT of hard work
that needs experienced knowledgeable kernel guru hands on it.
Right now Dave Jones <davej at redhat.com> I hear is hacking on the
AMD64 kernel for Fedora Core 1. I don't know if any other kernel
folk are working with Dave on that or if he's doing it himself.
Either way, it is a lot of work, and it's volunteer work.
Remember that. glibc/gcc et al. I am told are more or less
pretty solid, and most of the rest of the distribution probably
is also.
Keep in mind though, that since non-x86 was not ever an official
target of Fedora Core, while we are interested in doing other
ports, and we want the community to get involved, throughout the
whole development cycle, even though all 7 architectures got
built, there have not been any test releases or betas of any of
it. The only major architectural testing that happened is for
RHEL 3. So in this case, it is RHEL 3 that has improved greatly
the quality of non-x86 architecture support for Fedora Core,
instead of the other way around.
/me sticks his tongue out
There are differences of course between what's in RHEL 3, and
what's in Fedora Core, and so there very well is likely to be
unknown bugs in Fedora Core on non-x86. First we need kernels
for each non-x86 architecture, then we need the installer ported
if necessary to work properly. It's not clear yet what other
work is needed to be done.
>All understandable, its just frustrating in that they've
>obviously done the required work; and they are perfectly content
>with having the Fedora community duplicate that effort of
Considering all of the work that we have done, I'm rather
offended by your short sighted and rather thankless remarks to be
honest. ;o) We've set out to do a great amount of goodwill
here, and not because we had to. Because we WANT to, not just as
a company, but because making the distribution more open and
being a community project is supposed to be a _fun_ thing too.
We also do it because we ourselves not only work on this stuff
daily for a living, but we volunteer to work on it way beyond our
8 hours a day - because we love doing it. We are employees, but
the majority of us are also volunteers, and we'll be contributing
a lot of our own personal spare time to this project as well, and
that includes non-x86 architectures.
>formalizing 64bit library and 32bit library coexistance and so
>on. For all I know RedHat will weigh in and advise on such
>decisions.
Wrong. Rawhide has the latest of everything. We're not holding
back or hiding *ANYTHING*. Fedora Core and rawhide contain the
absolute latest support for anything and everything we have to
offer. As I said above, there is some per architecture kernel
work, installer work, possibly other surprises and gotchas we
absolutely have no idea about yet, but it is not stuff just
sitting idle with no effort happening. But the effort that IS
occuring internally is volunteer driven. To attack us for this
is to insult each and every engineer here who goes out of their
way far beyond the call of duty to contribute something so that
people such as yourself can have bits to play with.
>So that said, has there been any big picture planning for how
>x86_64 support will be added to Fedora Core? A list of which
>tasks need to be accomplished, who the stakeholders that will be
>contributing are, etc.
We've been severely worked to the bone for the last n months
trying to finalize Red Hat Enterprise Linux 3, trying to finish
off Fedora Core, and other high priority critical tasks. We
haven't really had a lot of spare volunteer time to throw around
really as it was tied up either doing work chasing the clock for
our products, or tied up in other volunteer efforts.
I personally do not know of any list of what needs to be done for
each architecture. I stated roughly some of the items above.
There are some known AMD64 issues with XFree86 I'd like to work
on, but that's dependant on spare time. People can scan bugzilla
reports for open "all" "i386/i686/athlon" and "x86_64" bug
reports to get an idea what bugs are open for AMD64. Feel free
to report new ones too.
It'd be a great idea to have a wiki on fedora.redhat.com with
proper ACLs, which allowed Red Hat engineers and Fedora project
community volunteers to place this kind of information.
>We may even want a new fedora-amd64-devel at fedora.redhat.com
>mailing list for the cause. Actually it might be nice if a
>fedora-<arch>-devel mailing list were created for each
>architecture the Fedora community deems worthy.
Personally I'm on about 130 mailing lists. I really don't need
another one. People are too quick to create new mailing lists
nowadays unnecessarily. All 3 existing fedora lists are for the
most part identical off topic clones of each other, and a new
list would probably just add a 4th clone list. fedora-devel-list
is the best place to have these discussions and hit everyone in
one spot. If the volume of per arch discussion really grows to
the size that it warrants another mailing list then that is
something to consider, but doing it prematurely is just
personally an annoyance at least to me. Others may feel
differently of course.
In closing, I'd like to kindly request that you please don't be
so critical about us. I think it is unfair to make these type of
judgements without the full factual information out there, and
without knowing just how much volunteerism goes into the
distribution by Red Hat engineers already. We opened the
distribution development via Fedora Core, so that we could work
more closely with the community, and so much more could be
accomplished both for the good of the community, and the good of
Red Hat as well. The open source concept applied to an entire
Linux distribution as a whole. We may or may not be crazy for
doing so, but then people thought Bob Young was crazy 10+ years
ago for starting a company based on open source technology too.
Boy were all those people wrong 10 years ago weren't they? ;o)
So we've opened things up, but that doesn't mean we can just push
buttons and make people's requests happen instantly. It takes
time to plan things, to develop them, etc. We also need to
plan, design, and develop whatever infrastructure we need in
order to make community involvement easier, perhaps that can even
be done directly in collaboration with people like yourself. We
need to put the infrastructure in place for people to build
packages, to test things, and various other suggestions people
have made or which we've come up with.
This wont happen overnight, and neither will an AMD64 port of
Fedora, nor an Alpha port - both of which I'm interested in. The
best thing people who truely want to be a part of this community
can do, is to become involved in a positive minded and open
manner, with due patience. Ask us questions, and we'll generally
answer them. Feel free to make suggestions too. Join the IRC
#fedora-devel channel, and communicate on the fedora-devel
mailing list. Please try to refrain from negativity and
insulting discussion though - that doesn't help anything and
doesn't improve the project, or the atmosphere. Keep an open
mind also, and to get involved wherever you feel comfortable
doing so.
If someone wants to make a list of what needs to be done for
AMD64, PPC or Alpha, by all means, someone start keeping track,
and we can probably put it up on a web page or something.
Actually what would be perfect, would be a public bug tracker
bug, which links to actual bug reports that are issues needing
work. That way we've got individual problems reported and/or
RFEs, as well as a tracker.
Count me in on AMD64 and Alpha, and many other mad hatters here
too. Dunno who all is interested in PPC, but there are some
internal folk. Perhaps we should have a web page listing
interested volunteers per architecture too? Damn, a wiki would
be nice, and I actually hate wikis. ;o)
Anyhow, hopefully I've squelched some conspiracy theories,
Slashdot FUD, and other bogosities now, and we can all work
together on producing real 64bit Fedora Core stuff, and get rid
of this x86 junk. ;oP
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
More information about the devel
mailing list