[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: AMD 64 support



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]