Warning: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in ..../includes/class_bbcode.php on line 2962
Ouch... - Page 2
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Ouch...

  1. #11
    Advisor beezlebubsbum's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    735
    To get more people to be able to use Linux, things such as installing drivers, updating the kernel, and general fixes needs to become way easier. That's the only thing that is better on windows, the fact that you can install a driver by double clicking an EXE files. I don't want to recompile my kernel every time I get a new piece of hardware. Why don't they make drivers RPM or DEB based? Wouldn't it be great if you could APT-GET your drivers? I have sound problems with ALSA and 2.6 kernels with my soundcard, the only way to fix it is to download drivers, and recompile the kernel. Sorry, but it is just easier looking elsewhere (to another distro).
    My Website: http://ttgale.com
    My Website Uptime: http://img.uptimeprj.com/holastickbo...dee9bae2e2.png
    My Server Specs: AMD Athlon X2 3800+, 2gb DDR2 RAM, 1.5TB HDD, Ubuntu 9.10
    My Gaming PC: Intel Core 2 Duo 2.93ghz, 4gb DDR2 RAM, 9800GTX+

  2. #12
    Senior Member
    Join Date
    Apr 2004
    Location
    Atlanta GA
    Posts
    373
    beez, any precompiled drivers can just be inserted, alot of OEM put out linux drivers like this you basically run a shell script and BAM its in place. NVidia for example. 'sh NVInstaller.sh' accept the license and your driver is inserted into the kernels module directory ready to be modprobed and used (No recompile and certainly no rebooting like in windows.)

  3. #13
    Mentor jro's Avatar
    Join Date
    May 2004
    Location
    Pennsylvania, USA
    Posts
    1,206
    Zen is right, dynamic module loading is one more thing to love about Linux. Insert the module for you kernel into the module directory, modprobe it, done. No restarting, you don't even have to log out and log back in, I think I did have to scratch my nose once but that is entirely optional (your nose, not mine). Usually the module needs to be compiled for your specific kernel version but most installers automatically do this for you.

    Sure you can recompile your kernel with the driver built in, but then you have to do it all over again when you update. Hardware I am almost completely certain I am not going to change or update I usually compile into the kernel. Everything else is a module.

    The only thing I am not sure about is if there is a performance difference between running mostly modules or compiling everything in. Anyone shed some light on this?
    jro - http://jeff.robbins.ws
    Linux counter#:213782
    GnuPG ID: 406238E7

  4. #14
    Newbie
    Join Date
    Nov 2004
    Location
    Carson City, Nevada
    Posts
    4
    Quote Originally Posted by beezlebubsbum";p="2818
    I have sound problems with ALSA and 2.6 kernels with my soundcard, the only way to fix it is to download drivers, and recompile the kernel. Sorry, but it is just easier looking elsewhere (to another distro).
    Hi y'all.

    Linux is Linux, if the drivers are contained in the kernel it's a recompile. Either that or download a binary kernel, but it's going to have drivers for a lot of stuff you don't need.

    --glenn

  5. #15
    Newbie
    Join Date
    Nov 2004
    Location
    Texas, USA
    Posts
    8
    Quote Originally Posted by jro";p="2826
    The only thing I am not sure about is if there is a performance difference between running mostly modules or compiling everything in. Anyone shed some light on this?
    I know you already know this stuff jro, but I'll give it a go in case it can help any foo'ers out there. ;-)

    There are a few variables to consider when determining if a driver would offer the best performance gain if compiled in the kernel, or as a module. A few of these considerations would be:

    * Processing power of the system.
    * Total amount of memory available to the system,
    * Amount of memory taken by the kernel and any drivers compiled with it.
    * The kernel's need for the driver to be consistantly remain in memory.
    * The stability of the driver itself.
    * The time required, availability, or desire to compile kernels and modules when updates are needed.

    There are advantages and disadvantages to compiling everything in (not uneccessary drivers of course, only those that the system can use) versus having all the drivers as modules.

    As mentioned, one of the benefits to using modules is that the driver can be loaded dynamically as needed. So, for example, a USB key used on occasion can have necessary drivers loaded as modules when a user plugs in their key, but when a USB key isn't being used (and assuming no other USB devices such as mice or keyboards are in use), the modules can be unloaded to free up the memory for other processes (possibly improving the overall system response if free memory is tight).

    However, it does take time to read the module from disk and load it into memory, In that essence, it would actually take longer to initially access to the device due to that delay than if the module was already loaded to begin with. Of course, to cut hairs, by compiling the driver into the kernel it would take slightly longer for the system to boot, but side-by-side it would still take less time for a kernel with a particular compiled-in driver to boot than a kernel with the driver loaded as a module.

    Aside from those drivers that are required, some can actually benefit the sytem if compiled into the kernel. Take for example the driver for a NIC in a desktop when the system is part of a network. If we know that at each boot the module gets loaded, and we won't be changing the NIC out anytime soon, that driver would be a good candidate for compiliing in with the kernel.

    Other devices that are "hard-wired" to the sytem, such as hard drive controllers, video and sound cards, etc. could also be good candidates. What we don't want to do is waste our memory resources by compiling in drivers for devices or abilities that won't ever be used, or rarely if at all, and analyzing the needs of "part-time" drivers for other usable devices (such as PCMCIA on a laptop that's only used on ocassion for example).

    That's where the fun can begin for those like to tweak their kernel, but keep in mind that as the number of drivers compiled in with the kernel increases, so does the size of the kernel. Therefore access time can increase as well, which can degrade performance on a system with limited memory and processing power.

    With adequate memory a monolithic kernel can be fast, but one of the things I like about Linux is that we can play on both sides of this fence. By not constraining ourself to a purely monolithic kernel, yet having the drivers compiled in for the resources used on a constant basis, the system can still adapt to changes in devices by calling modules. Some may consider this a security concern (the ability to load a module into the running kernel), but for desktops and the various devices we keep hooking up to them, it's almost necessary.

    Another thing to consider is that the more drivers that are compiled into the kernel, the higher the risk of boot failure. If there was a problem that prevented a module from loading, the kernel would fail to load the module but continue on. If that driver had been compiled in with the kernel, we might end up with a kernel panic on our hands instead of only a failed module-load.

    From experience I highly recommend starting light, compiling in a few drivers at a time for the devices there is a constant need for, and testing between each compile to ensure that everything's working. If the system flakes-out or panics, then I have a much better idea as to what driver caused it and can focus on resolving the issue, or leave it as a module (or unused) and work on it later.

    In the end, you'll have a kernel that's tailored and optimized to your system and can set back and take it all in... at least until the next driver or kernel patch arrives!! ;-)

  6. #16
    Newbie
    Join Date
    Nov 2004
    Location
    Carson City, Nevada
    Posts
    4
    dscribner

    Very well put! I'm sure that will be helpful to a lot of newbs. That makes an excellent candidate for a KB article IMHO. To Module or not to Module / Module or Built-In. You should submit it.

    --glenn

  7. #17
    Advisor
    Join Date
    Apr 2004
    Location
    orlando
    Posts
    608
    you do realize that the only real difference you are talking about in speed is reading the module off of the disk, right? the init procedures are called regardless of whether it's built as a module or not.

    IMHO the only time it's advantageous to build as a module instead of built-in is if you want to add capability to you _currently_running_ kernel and don't want to reboot.

Similar Threads

  1. ouch!
    By Stuart in forum General Chat
    Replies: 17
    Last Post: 10-29-2003, 02:09 PM

Bookmarks

Posting Permissions

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