On Oct 21, 1996 at 13:05, Paul Edwards of 3:711/934.9 wrote:

 PE> Well unfortunately I didn't have HPFS support in my boot image, so I had
 PE> to recompile the kernel.

I don't think *anyone's* default kernel has HPFS built-in;  the boot image
is only used to install the operating system.  After that, you really
should compile your own kernel (they're up to 2.0.23, BTW, and are getting
ready to release 2.0.24 - I'm still running 2.0.20 at work).

 PE> I did so, and that fixed that problem, but gave me millions of warnings
 PE> about /lib/modules/... being out of date or something.

Sounds like you stuffed up the modules or something.

 PE> As far as I could tell, this should have been fixed by a "make
 PE> modules" followed by a "make modules_install", but
all the latter
 PE> command did was say "ls *.o" not found or something.

Assuming you hadn't run "make clean" or something in the interim.

Basically, the Linux 2.0.x kernel consists of at the least, one part, and
at the most, three parts:

(a) the monolithic (core) kernel itself;
(b) any modules (effectively, "device drivers");  and,
(c) the kernel daemon server process (kerneld).

If you chose anything to compile as a module, then perhaps you should go
back and make a monolithic kernel with everything built-in to start with
(after all, you have 64Mb).

The purpose of kerneld is to detect when a module that isn't already in
memory is required, so it loads it in;  when the module hasn't been used
for 60 seconds, it gets turfed out of memory.

On the machines at work, anything that can be a module (and isn't required
for booting the system), like serial port support, NFS/CD-ROM file systems,
network cards and so forth, are all modules.  As the machine boots, kerneld
detects when a module is required (like the NIC driver), and it's loaded
in.

The modules themselves live in
"/lib/modules/".  You can also be
quite clever in how the whole thing hangs together;  at work, I have:

    /lib/modules/2.0.20
    /lib/modules/boot
    /lib/modules/current

When building a kernel, the modules are installed into the appropriate
directory matching their version (2.0.20 above).  "current" is
just a soft symlink to the current version of kernel I'm using (important
during transition phases between kernel versions).  "boot" is a
single directory with soft symlinks to the drivers that are most likely to
be needed during startup (like the NIC driver).

The core/monolithic kernel is that pesky "/vmlinuz" file that
some users decide to delete...

 PE> Anyway, I think I shouldn't be using any modules, so I found out all the
 PE> places in rc.d that were using modules, and commented them out...

*sigh*

 PE> ...and nothing seemed to go wrong, so I guess I'm halfway somewhere.

Go back, uncomment it all, go into "/lib/modules", and blow away
any directory that shouldn't be there - like the whole bloody lot if you've
compiled without modules (are you sure you didn't compile-in
"kerneld" support?).

 PE> I was wondering whether I should run Dos-binkley, dos-squish/tobruk,
 PE> dos-msged under Linux, but unfortunately dosemu doesn't come
 PE> "already-working", so I have to go and figure that out. 
What a bummer!

Maybe that's just as well.  :-)

 PE> And I don't know if MSGED/386 works under dosemu. MSGED/386 works under
 PE> a dos full-screen in os/2.  BFN.  Paul.

A DOS full-screen session under OS/2 has VCPI support;  no idea what's in
dosemu, I stay away from it (and Executor, and WINE, and...) like the
plague.  I've had my fill of environment/operating system emulators, thank
you.

 PE> P.S. When X11 didn't like the fact that I didn't have a /dev/console...

That seems to be a (well-)known bug.  Next time you're on-line, check out
InfoMagic's site (http://www.infomagic.com/ or ftp://ftp.infomagic.com/)
for bugfixes.

 PE> I decided to softlink /dev/console to /dev/tty0.  That didn't fix the
 PE> problem...

I'm not surprised!

 PE> ...but is that what you're meant to do with "/dev/console" anyway?

Not really.  Most of what exists in "/dev" has two strange
numbers (in a full directory listing) which identifies the
"device" to the kernel.  The console will have a different
"device" identifier to the terminal devices.

I *think* a "MAKEDEV console" fixed it, but I can't recall. 
Check InfoMagic's site, anyway;  if the fix isn't there, let me know as I
*think* I saved a list of bugs around here somewhere...

Cheers..

    - dave
    d.begley{at}ieee.org

---