RE: Building Kernels and Kernel modules

On Mon, 2003-04-28 at 03:21, Kevin Curtis wrote:
> Hi everyone,
> 	I have now signed up to the list as requested.  I work for a company
> that manufactures PCI WAN cards.  We have Intel Linux drivers for our own
> X.25 stack and also sync drivers that allow syncppp or the generic hdlc
> modules to be used.  We would like to port these ultra-linux.  I chose the
> aurora-linux distribution because it was the most upto date, and it
> installed (via the text install) with out any problems.  So far everything
> looks good.

Wow. This is the first time I've ever heard of a hardware vendor giving
any consideration to SPARC/Linux. I'll try to help you guys out as best
I can.

> 	However, there seems to be some things I need to be aware of about
> developing in this environment.  Is there a howto or other publication that
> will make me aware of the "right way" to go about developing?

Not really, most of the rules can be found buried in the archives for
[email protected], but the summation is this:

Right now, if you want a reliable kernel, you had better use
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) for sparc32, and 
gcc version egcs-2.92.11 for sparc64. These are kgcc -v and kgcc -v
-m64, as included in the compat-egcs package in Aurora 1.0.

Make xconfig has been broken for sometime on sparc, use make menuconfig
(or make oldconfig) instead.

When things really start to break in the kernel, look at what Dave
Miller's settings in defconfig are. The closer you match up with him,
the more likely he is to help. ;)

If you're adding a lot of functionality, do not compile much of it into
the kernel. Modularizing as much as possible is key to getting a fully
featured kernel to boot on sparcs.

Even with almost everything modularized, the kernel image may still be
too big to boot (most custom kernels built by users suffer from this
error). You might get a little more space by stripping the symbols from
the kernel. It removes the option of debugging that kernel, however.
Aurora 1.0 works around this by including two kernel images, one with
symbols stripped that is used for booting, and one named
vmlinuz-UNSTRIPPED that is the original, unstripped image for debugging.

strip -R .comment -R .note vmlinux <- strip syntax used by Aurora RPM

Thats all the gotchas I can think of offhand, feel free to ask questions
as you go forward.

~spot
---
Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE
Red Hat Enterprise Architect :: http://www.redhat.com
Project Leader for Aurora Sparc Linux :: http://auroralinux.org
GPG: D786 8B22 D9DB 1F8B 4AB7  448E 3C5E 99AD 9305 4260

The words and opinions reflected in this message do not necessarily
reflect those of my employer, Red Hat, and belong solely to me.

"Immature poets borrow, mature poets steal." --- T. S. Eliot