I was not actually replying to your post, but, rather I was adding a general post to the thread about compiling a kernel for other users. I thought Eric's guide was a useful thing to mention.
I usually quote a post if I reply to it. I can understand your confusion with my reply. Sorry for the confusion. As a Gentoo user I know you are proficient with compiling a kernel. No disrespect was intended with my post.

Hitest,
Your apology is deeply appreciated. And may you keep firing on all cylinders (pun for "hitest" petrol).

Thank you!
Shingoshi

Hell, I can't even get Gentoo installed! (well, that was a few years ago...spooked me so bad I haven't been back) LOL

You are welcome, Shingoshi!

Gentoo is NOT for the faint of heart. I've heard so many Slackware users complain about trying to use Gentoo, that it's almost pathetic. And many of them have been long time experienced Linux users. I'm one of those more adventurous types. If I see a mountain (figuratively speaking, mind you), I'm the first who wants to climb it. I've done so many of the things that users are NOT supposed to do, that it's become an obsession with me.

One of those things was to use slapt-get to directly upgrade from Slackware to Slamd64. Even Fred (the Slamd64 creator) thought I was insane. But it worked. I did have some problems, simply because of the many programs which I had compiled myself, and hadn't yet upgraded. But for package building, I use src2pkg, which is excellent. As with Tukaani's tukbuild previously, I've also done a lot of testing for src2pkg for 64-bit builds. And I'm still actively engaged in that.

In fact, it's because of my use of src2pkg on my 32-bit system using a 64-bit kernel, that I was aware of linux32. I had to build my own copy of it, since the one from Slamd64 is a 64-bit binary and was of no use to me. I have a very large config file for src2pkg.conf. And because I have to use linux32 for just about everything that I do, I knew it might work in this case as well.

Gnashley (the creator of src2pkg: http://www.linuxquestions.org/user/gnashley-88281/) had been pestering me for some time just to go back and use a 32-bit kernel. And I finally (though reluctantly) conceded. Once I have my new kernel installed and running, hopefully all of my previous problems with not being able to run some 32-bit apps will be over. Although, the compulsive-obsessive in me will still feel like I've submitted to failure.

Shingoshi

I used Gentoo inside a chroot on Slamd64. I wanted to examine building Slackware packages with their automated build system. It really is the gold mine for obsessive builders like me.

I may still go ahead and recompile gcc to allow 64-bit builds. Because all I really want to do is create kernel modules, which I can't do with the default Slackware gcc. But that's another topic which you can find here on Linuxquestions.

Is there something NOT HUGE about HIGHMEM64 on an smp kernel?

I mean maybe someone can explain this to me. Why isn't HIGHMEM64 enabled by default on the kernel-huge-smp? The very name of the kernel is HUGE. So why isn't it built for systems that require the maximum amount of resources available? Why are we being forced to create a kernel with a major option not provided by default. Almost anyone who has a new processor and motherboard, will have the option of using memory in amounts larger than 4GBs. I mean, for crying out loud. Windows is hamstrung to 4GBs. Is the kernel-huge only supposed to be a clone of the Windows limitation?

With the new Intel i7 motherboards, no one is going to be content for long with the limitation of 4GBs. Those boards use a minimum of 6GBs, and a maximum of 72GBs (using 4GB modules). Even on an old socket-775 board, using the Intel ich10r northbridge chip, the maximum amount of available memory is 16GBs. So am I the only one who has thought about this?

Shingoshi

It's called HUGE because it's built with everything (Kitchen sink and all) included and is not a reference to the amount of addressable memory.

It's not a conspiracy... honest

I was asking about the apparent lack of consistency (not conspiracy) here. If it's called HUGE for the sake of "everything in it", that level of completeness should also include (by implication) the amount of memory that can be used. And what may have been good in the past, isn't going to satisfy the concerns I've raised about our current (Intel i7 et. al.) state technology. It is simply no longer adequate to NOT provide compiled kernels with the maximum amount of memory available. Conspiracy or not!

Shingoshi
ps. The HIGHMEM option is likely going to have to be raised to match the new systems (with more than 64GBs) that can run 32-bit Linux.

Once again, do not confuse the name "huge" in this kernel with the addressable memory. It is huge because it contains as much drivers as possible to allow installation on a variety of hardware.

It's explained like this in CHANGES_AND_HINTS.TXT:

And the Slackware-HOWTO states:

It's somewhat unlikely that you will ever need more than 4GB of RAM to install Slackware.

Eric

While it may true that the kernel-huge was intended as an installation kernel, I have never run anything else. I prefer knowing that there is nothing that I could install on my system, that I won't have the appropriate drivers for. It's just my preference. So, expecting users to recompile a kernel, designates Slackware as a do-it-yourself distribution.

Shingoshi

That's exactly what attracts me to Slackware: decisions are not made for me. With Slackware I am stimulated to make my own decisions - I am in control.

I prefer a hundred times a 'do-it-yourself' distribution over a 'we-do-everything-for-you' distribution.

Slackware doesn't "expect" or require users to compile their own kernel, but gives them all the tools & sources necessary to do it *if they choose to do so*.

Where do you see that expectation documented?

And?

I like to have both, Slackware for the "do-it-yourself", and Ubuntu for "I-could-do-it-myself, but you-can-do-it-for-me-because-I'm-a-lazy-****-at-times"

Ok guys! Admittedly, I'm whining! I've already installed and am running a 64-bit kernel. It really confuses the hell out of your system. But the thing that really gets me is that I can't build 64-bit kernel modules. The rest of the stuff (odd issues here and there) I've learned to deal with. So I finally decided to go back and try to build a 32-bit kernel with HIGHMEM64. But for some weird reason, I'm having difficulty trying to build a 32-bit kernel.

First of all, I had to use "linux32 make menuconfig" just to get the HIGHMEM option to show up. The 64-bit kernel was telling the build, "hey, we're building a 64-bit kernel, 32-bit options don't apply here. That alone was annoying until I figured out what was happening. I kept thinking I must be missing something here. I wasn't. It just doesn't show up!

I may have to resort to building a kernel on another box which is running a 32-bit kernel, and see if it succeeds there. It really shouldn't be a problem. But that's the annoying part. If I didn't have another box to build a HIGHMEM64 kernel, I'd likely not be able to do it. So if the stock kernel came built with HIGHMEM64, I would have never experienced any of this. I think sometimes there simply are things that you can't do. Or the difficulty discourages anyone from trying. I didn't write any of this because I hadn't tried. Believe, I tried, all sorts of options and routes to get this done. If all else fails, I'll try installing a 32-bit kernel on this box, and then build the new kernel. Because I really like having my full 8GBs of ram. It's really sweet for mounting /tmp on tmpfs, and building packages there. It's just FAST!!

Shingoshi

Precisely mate. Man, 10 minutes in Ubuntu and I'm bored to death...just, well.....lost for words.....lol