On Fri, Jan 05, 2001 at 03:43:29PM -0500, Charles Fultz wrote:
> David Cantrell said:
>
> > Charles Fultz wrote:
> >
> > > I think that the make [config, menuconfig, xconfig] should check
> > > /dev/openprom/compatible, and if it equals one of 'sun4c', 'sun4d', or
> > > 'sun4m' it should not give the option of PCI and/or PS/2
> > > keyboard/mouse. How's that sound?
> >
> > That's not a good idea. It makes it difficult for distributors to build
> > kernels unless they are building them on the target machine. 9 times out
> > of 10, we don't build a kernel on the target machine, but rather a build
> > machine.
>
> I guess I don't understand how it's bad. Can you elaborate a bit more
> on this? I understand that you don't usually build a kernel for a
> specific machine on that particular machine, that makes sense.
>
> I understand that if you build a kernel for a 32bit machine
> (sun4[cdm] in this case), you may be building it on a 64bit (ultra [sun4u])
> machine. And in my suggestion you would still see the PCI & PS/2
> option. But, if you were building a 32bit kernel on a 32bit machine,
> you wouldn't get that option which is how I'd like it.
>
> Suggestions, complaints, and comments are encouraged on this subject.
>
I don't like the idea of the kernel config examining your machine and
enabling or disabling what you see based on what's in the machine. I
think that should be left to the person building the kernel.
Also, the PCI option *is* valid for 32-bit SPARC machines, just not all of
them. The driver doesn't operate like the PCI driver in Intel kernels.
If you enable the PCI option on a 32-bit SPARC machine that doesn't have
that, it craps out. On an Intel machine you can have the PCI support in
the kernel, boot it on a VLB system and have it work.
I believe it boils down to the people that needed this driver in 32-bit
SPARC kernels just "got it done" and stopped after that. No one seems
interested in maintaining it or enhancing it, so it presents us with
problems like the keyboard thing we just recently discovered. But, all in
all, it wasn't a big deal. It was annoying, but no one's head exploded as
a result of it. :)
There are several things in the kernel config that you can see on SPARC
and SPARC64 that absolutely will not compile. I don't know why they are
there. Some even fail and kick out a message like "You lose, contact
DaveM." So I imagine that sometime somewhere someone was able to get that
to build.
And in addition to that, there are things that I think should be enabled
in the kernel config that aren't. Like USB support. :) I went down to
Best Buy yesterday and bought a Xircom USB expansion card and I'm going to
see if I can make that work in my Ultra 5. Wouldn't that be cool? I had
to patch the OHCI driver a bit on the sparc64 platform, but it wasn't a
big deal. I haven't heard of anyone trying this or even caring for that
matter. Either I'll fry the card or I'll be syncing my Handspring Visor
on my Ultra 5. :)
> > I'm looking into e2fsprogs right now to see if there's a new release or
> > anything like that. I don't know why it would segfaulting. Perhaps the
> > disklabel support in the kernel, but I don't know.
>
> I'm building a new kernel that will (hopefully) make everything
> better. Like I said, I only had the problem during setup.
OK, keep me posted on what you find out.
--
David Cantrell | david@slackware.com *
KG6CII | Slackware Linux Project
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT