Find the answer to your Linux question:
Page 4 of 16 FirstFirst 1 2 3 4 5 6 7 8 14 ... LastLast
Results 31 to 40 of 154
Dolda, It seems like I'm having a lot of trouble compiling the kernel. Is it possible to use the old config file that I have from the pre compiled kernel ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #31
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319

    Dolda,

    It seems like I'm having a lot of trouble compiling the kernel. Is it possible to use the old config file that I have from the pre compiled kernel that I'm using now? This way, I can tweak little stuff here and there.
    The best things in life are free.

  2. #32
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I guess that would be possible. Just that I don't really understand where you'll get that config file from if this was a pre-compiled kernel?

  3. #33
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    Perhaps the term pre-compiled kernel is wrong. When I installed debian with it's kernel, it left a config file in the boot sector. This is very close to what the saved config file looks like from xconfig.
    The best things in life are free.

  4. $spacer_open
    $spacer_close
  5. #34
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Ah, OK. Then I guess it should be possible. Just copy that file to .config in your source tree.

  6. #35
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    Dolda,

    It seems like /etc/modules contains modules to be loaded during boot. Since I'm compiling a new kernel, I'm building most of these directly into the kernel instead of leaving them as modules. If I do this, I'm assuming that I need to get rid of the specific lines in /etc/modules. What is the purpose of the other module files in /etc? What is the benefit of leaving something as a module vs directly building it into the kernel?
    The best things in life are free.

  7. #36
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I'm guessing that /etc/modules is Debian-specific, because I don't have it. You're not referring to /etc/modules.conf, are you? /etc/modules.conf is used to specify certain options for the module loaders, such as module search paths, aliases, default module parameters and so on. But if your /etc/modules is to load modules at boot, then yes, you would probably fare best if you removed lines for modules that you don't have.
    There are several benefits to loading code as modules. First of all, if your core kernel gets too large, the boot loader might not be able to load it at all. After boot, however, when the system runs in full protected mode, the kernel can load any number of modules. Also, you must keep in mind that all kernel code is unswappable, so the more kernel that you have loaded, the less memory is available to your programs. Now, sure, kernel code might not take up that much space, but nontheless, it's better to save it than to waste it. By using modules you can make sure to only have the modules that you currently need loaded, to preserve memory. Another great advantage of using modules is that you can unload them and reload them with other parameters, if you'd like to change them. That way, you won't have to reboot your entire system to respecify certain things.

  8. #37
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    Regarding modules, I see the point in saving space. What exactly happens when you select 'M' as a choice during 'make xconfig' to make a choice in to a loadable module? I'm sure the loadable module must have to be hard coded to a certain degree in the kernel hence taking up space.
    The best things in life are free.

  9. #38
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    No, if you compile them as modules, they don't affect the core kernel in any way at all. Why did you think that?

  10. #39
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    My take on this was that even if you choose to load modules at kernel time, the kernel itself must KNOW that there are modules that can be loaded. Exactly what does initrd do? Does this have anything to do with modules and how they work?
    The best things in life are free.

  11. #40
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    initrd in itself has nothing with modules to do. One of its main practical uses, however, is module related. initrd stands for INITialization RamDisk, and is in my opinion one of the best things with Linux. Not that I use it very often, but it makes it very versatile. The idea is that you create a filesystem image on your hard disk/floppy/whatever, and then the bootloader loads it into memory along with the kernel, so to speak, so when the kernel starts booting it is already present in RAM. Then you can mount that filesystem image as the root filesystem, instead of booting from a physical medium. RedHat employs that widely nowadays by allowing certain modules to be loaded before the real root filesystem is mounted (eg. modules that are required to access the real root filesystem). That allows you to put your root file system on eg. a SCSI drive without having to ship a kernel that includes SCSI support.

    Anyway, the kernel must not know which modules that can be loaded. The basic scheme to load a module is as follows. First the module loader specifies a file to load. That file is then loaded into kernel memory, and there's nothing more with that. It just is there, but it's not related to anything. The next step is to resolve all symbols. I don't really know if that is done by the kernel or in userspace, but anyhow all external symbols in the module are replaced with the physical address in the kernel. In that way, it's just like any dynamic loader, only that it's done with the kernel space instead. The last step is to simply call the initialization routine of the module. That is, of course, done in kernel space, but in the calling process' task.
    So you see, the kernel does have to know anything about the module in advance. The only thing that really matters is that all symbols can be resolved.

Page 4 of 16 FirstFirst 1 2 3 4 5 6 7 8 14 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •