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

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,

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

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 |
|------------------------------------/-------------------------------------|

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).

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 |
|------------------------------------/-------------------------------------|

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.

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 |
|------------------------------------/-------------------------------------|

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.