Is SATA driver built-in or a loadable module? - Linux

This is a discussion on Is SATA driver built-in or a loadable module? - Linux ; Hello, Are the SATA drivers a loadable module or is it built into the Linux kernel? I am specifically interested in the AHCI driver. I have kernel 2.6.20 I am still a beginner a linux driver development so please bear ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Is SATA driver built-in or a loadable module?

  1. Is SATA driver built-in or a loadable module?

    Hello,

    Are the SATA drivers a loadable module or is it built into the Linux
    kernel?

    I am specifically interested in the AHCI driver. I have kernel 2.6.20

    I am still a beginner a linux driver development so please bear with
    me.

    Thanks!

    Eugene


  2. Re: Is SATA driver built-in or a loadable module?

    In article <1183574994.167193.324190@n2g2000hse.googlegroups.c om>,
    wrote:

    >Are the SATA drivers a loadable module or is it built into the Linux
    >kernel?


    Yes


  3. Re: Is SATA driver built-in or a loadable module?

    On Jul 4, 3:05 pm, e...@no.spam () wrote:
    > In article <1183574994.167193.324...@n2g2000hse.googlegroups.c om>,
    >
    > wrote:
    > >Are the SATA drivers a loadable module or is it built into the Linux
    > >kernel?

    >
    > Yes


    Yes to loadable module or built-in kernel?

    Can you please clarify?

    thanks,


  4. Re: Is SATA driver built-in or a loadable module?

    eugenios@gmail.com coughed up some electrons that declared:

    > On Jul 4, 3:05 pm, e...@no.spam () wrote:
    >> In article <1183574994.167193.324...@n2g2000hse.googlegroups.c om>,
    >>
    >> wrote:
    >> >Are the SATA drivers a loadable module or is it built into the Linux
    >> >kernel?

    >>
    >> Yes

    >
    > Yes to loadable module or built-in kernel?
    >
    > Can you please clarify?
    >
    > thanks,


    Yes to both - most if not all of the SATA drivers may be compiled either
    statically or as a module. Depends on who built the kernel.

    Tim

  5. Re: Is SATA driver built-in or a loadable module?

    On Wed, 04 Jul 2007 19:43:42 -0000 eugenios@gmail.com wrote:
    | On Jul 4, 3:05 pm, e...@no.spam () wrote:
    |> In article <1183574994.167193.324...@n2g2000hse.googlegroups.c om>,
    |>
    |> wrote:
    |> >Are the SATA drivers a loadable module or is it built into the Linux
    |> >kernel?
    |>
    |> Yes
    |
    | Yes to loadable module or built-in kernel?

    Yes


    | Can you please clarify?

    Most drivers can be made as modules. Almost all can be made built-in.
    It's the choice of whoever builds the kernel. If you build you own, you
    can make the choice yourself (changing the choice you dislike that comes
    in the distribution you chose).

    I personally prefer everything to be built-in. Some people prefer quite
    the opposite.

    When a double question is asked as one, and it is a yes/no type question,
    and someone answers with a single "yes" or single "no" answer, that means
    for both parts.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-07-04-1621@ipal.net |
    |------------------------------------/-------------------------------------|

  6. Re: Is SATA driver built-in or a loadable module?

    phil-news-nospam@ipal.net writes:
    > On Wed, 04 Jul 2007 19:43:42 -0000 eugenios@gmail.com wrote:


    [...]

    > Most drivers can be made as modules. Almost all can be made built-in.
    > It's the choice of whoever builds the kernel. If you build you own, you
    > can make the choice yourself (changing the choice you dislike that comes
    > in the distribution you chose).
    >
    > I personally prefer everything to be built-in. Some people prefer quite
    > the opposite.


    There are actually reasons to pick on or the other. If this system
    needs it to boot (like root-FS), it makes more sense to have it
    built-in if the kernel is a per-system-kernel. This is more robust wrt
    possibly damaged file systems and it boots somewhat faster. If it is a
    driver for some non-essential peripheral (like a USB<->serial
    converter or a NIC when access is not mostly or only done over a
    network), a module has some advantages, notably, it can be replaced
    with a (possibly fixed/ modified) module without rebooting the system
    and, if driver and/or hardware are flaky, unloading and reloading the
    module has a high chance of 'forcing it to shut up just now' (Eg
    around Linux 2.6.20, the UHCI driver used to halt the host controller
    of the computer I was using then. While I suspected this to be 'just
    another bug introduced by the maintainer while shuffling code
    for the purpose of having doing so', I was neither motivated to try to
    debug this nor would I have had time to spare. Kicking the module out
    of the kernel and gently inviting it to come back in afterwards used
    to get the USB going again).

  7. Re: Is SATA driver built-in or a loadable module?

    On Thu, 05 Jul 2007 09:49:08 +0200 Rainer Weikusat wrote:
    | phil-news-nospam@ipal.net writes:
    |> On Wed, 04 Jul 2007 19:43:42 -0000 eugenios@gmail.com wrote:
    |
    | [...]
    |
    |> Most drivers can be made as modules. Almost all can be made built-in.
    |> It's the choice of whoever builds the kernel. If you build you own, you
    |> can make the choice yourself (changing the choice you dislike that comes
    |> in the distribution you chose).
    |>
    |> I personally prefer everything to be built-in. Some people prefer quite
    |> the opposite.
    |
    | There are actually reasons to pick on or the other. If this system
    | needs it to boot (like root-FS), it makes more sense to have it
    | built-in if the kernel is a per-system-kernel. This is more robust wrt
    | possibly damaged file systems and it boots somewhat faster. If it is a
    | driver for some non-essential peripheral (like a USB<->serial
    | converter or a NIC when access is not mostly or only done over a
    | network), a module has some advantages, notably, it can be replaced
    | with a (possibly fixed/ modified) module without rebooting the system
    | and, if driver and/or hardware are flaky, unloading and reloading the
    | module has a high chance of 'forcing it to shut up just now' (Eg
    | around Linux 2.6.20, the UHCI driver used to halt the host controller
    | of the computer I was using then. While I suspected this to be 'just
    | another bug introduced by the maintainer while shuffling code
    | for the purpose of having doing so', I was neither motivated to try to
    | debug this nor would I have had time to spare. Kicking the module out
    | of the kernel and gently inviting it to come back in afterwards used
    | to get the USB going again).

    For the SATA driver I would not classify it in this category. However,
    for quite many drivers thus may well be an option. OTOH, you'll find
    that the kernels I run (which I've configured and compiled the way I
    want them to be), module insertion is not even included. But I do have
    quite many things I _may_ need, such as USB and Firewire drives. For me
    it is not hard at all to configure and build a new kernel if I need one.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-07-14-1243@ipal.net |
    |------------------------------------/-------------------------------------|

  8. modularized kernels

    phil-news-nospam@ipal.net writes:
    > On Thu, 05 Jul 2007 09:49:08 +0200 Rainer Weikusat wrote:
    > | phil-news-nospam@ipal.net writes:


    [...]

    > | a module has some advantages, notably, it can be replaced
    > | with a (possibly fixed/ modified) module without rebooting the system
    > | and, if driver and/or hardware are flaky, unloading and reloading the
    > | module has a high chance of 'forcing it to shut up just now'


    [...]

    > For the SATA driver I would not classify it in this category.


    Neither would I.

    [...]

    > OTOH, you'll find that the kernels I run (which I've configured and
    > compiled the way I want them to be), module insertion is not even
    > included. But I do have quite many things I _may_ need, such as USB
    > and Firewire drives. For me it is not hard at all to configure and
    > build a new kernel if I need one.


    Ehh ... I don't usually compile modules I don't plan to use. But if
    everything is built-in, the only way to "fix" a subsystem in a serious
    state of confusion is a reboot. The USB host controller halt I was
    writing about used to happen a couple of times each day (on most
    days). A quick rmmod -f/ modprobe was faster than rebooting the box
    would have been.

  9. Re: modularized kernels

    On Sat, 14 Jul 2007 20:34:24 +0200 Rainer Weikusat wrote:

    | Ehh ... I don't usually compile modules I don't plan to use. But if
    | everything is built-in, the only way to "fix" a subsystem in a serious
    | state of confusion is a reboot. The USB host controller halt I was
    | writing about used to happen a couple of times each day (on most
    | days). A quick rmmod -f/ modprobe was faster than rebooting the box
    | would have been.

    Linux, being a monolithic kernel, if any "subsystem" is in a serious state
    of confusion, the only action I would trust is a reboot.

    BTW, I have encountered a USB controller problem a couple times on my Linux
    desktop at work. It happened to have a stock kernel from FC6, so it had
    modules I could have reloaded. However, I chose to do a reboot instead.
    Guess what ... the problem remained. The controller was still in a state
    of total confusion. So I shutdown again and this time pressed the reset
    button while sitting at the next GRUB menu. Even that did not clear the
    problem. It took a full power off then on cycle to clear it up.

    BTW, what caused that problem was the insertion of a 2nd USB device during
    I/O activity of the 1st USB device. This could possibly have resulted in
    the 1st device connection being bumped loose enough to disrupt an ongoing
    transfer. But USB is supposed to detect that and retry (I don't know if
    the retry is supposed to be done by hardware or software, but the hardware
    is certainly not supposed to freeze harder than a reset when it happens).

    Hardware problems that force me to do a reboot are otherwise quite rare.
    They happen even less at home than at work. Maybe that is because all my
    home computers are hand built by myself.

    And, I would not expect the average user to understand when reinserting a
    driver would actually help. Such practices, IMHO, should be limited to
    those who know what it does, and means, and when it is usable. And yet I
    don't even care to myself.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-07-15-0849@ipal.net |
    |------------------------------------/-------------------------------------|

  10. Re: modularized kernels

    phil-news-nospam@ipal.net writes:
    > On Sat, 14 Jul 2007 20:34:24 +0200 Rainer Weikusat wrote:
    > | Ehh ... I don't usually compile modules I don't plan to use. But if
    > | everything is built-in, the only way to "fix" a subsystem in a serious
    > | state of confusion is a reboot. The USB host controller halt I was
    > | writing about used to happen a couple of times each day (on most
    > | days). A quick rmmod -f/ modprobe was faster than rebooting the box
    > | would have been.
    >
    > Linux, being a monolithic kernel, if any "subsystem" is in a serious state
    > of confusion, the only action I would trust is a reboot.


    That could be because you are confusing different types of confusion
    (sorry for the cheap pun). In case of a software error, potentially
    involving some kind of memory corruption, it could be a bad idea to
    continue running the system (OTOH, I have been using computers where
    the RAM was so ****ed-up that ten different md5sums calculated from
    the same (large amount of) data would yield then different values. But
    it they still mostly worked). But for a hardware error, eg an UHCI HC
    halts itself because it feels like it ('because of an internal error',
    according to Intel docs), trying to reset the device to eventually get
    it going again is a standard practice. It's just that the error
    handling of the Linux-UHCI-driver is less-than-spectacular (print a
    message and ignore the issue), meaning, the only way to cause the HC
    to be resetted is to 're-start' the driver.

    [...]

    > And, I would not expect the average user to understand when reinserting a
    > driver would actually help.


    That's simple: Try it. If it works, fine, if not, nobody is worse off
    than before.


+ Reply to Thread