From: John Hasler on
Yousuf Khan
> Anyways, what sort of driver modules are not compiled? How do they run
> then?

The system boots up running entirely out of RAM (using a RAM
filesystem), probes the hardware to find out what it is dealing with,
and loads the driver modules it needs.

See <http://en.wikipedia.org/wiki/Initrd>

--
John Hasler
jhasler(a)newsguy.com
Dancing Horse Hill
Elmwood, WI USA
From: AZ Nomad on
On Sun, 17 Jan 2010 12:59:47 -0600, Ignoramus15099 <ignoramus15099(a)NOSPAM.15099.invalid> wrote:
>On 2010-01-17, AZ Nomad <aznomad.3(a)PremoveOBthisOX.COM> wrote:
>> On Sun, 17 Jan 2010 12:06:24 -0600, Ignoramus15099 <ignoramus15099(a)NOSPAM.15099.invalid> wrote:
>>>On 2010-01-17, Yousuf Khan <bbbl67(a)yahoo.com> wrote:
>>>> dennis(a)home wrote:
>>>>> However there are compiled in options that could break a linux system if
>>>>> they have been used by the OP.
>>>>> Its unlikely and they probably wouldn't be asking such simple questions
>>>>> if they had.
>>>>
>>>> That is part of the question, are there any compiled in options in the
>>>> standard Ubuntu distro kernel that I will have to worry about? For
>>>> example for the chipset. I remember from the old days of Linux that most
>>>> drivers were compiled in, and now they are mostly run-time loaded; but
>>>> are there still any holdovers left that are only compiled in?
>>
>>>There are some drivers that are not compiled in by default; those tend
>>>to be experimental or incomplete drivers.
>>
>> There are few drivers that are compiled in. The vast majority are
>> modules and not loaded unless the hardware is detected.

>Sure. But some are not even compiled as modules.

Yes. All 0.005% of them.
Everything that isn't a core driver can be built as a module and
a distribution like ubuntu does everything as modules when possible.
From: Baron on
dennis(a)home Inscribed thus:

>
>
> "AZ Nomad" <aznomad.3(a)PremoveOBthisOX.COM> wrote in message
> news:slrnhl4aq6.63t.aznomad.3(a)ip70-176-155-130.ph.ph.cox.net...
>> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan
>> <bbbl67(a)spammenot.yahoo.com> wrote:
>>>Just purchased a new motherboard/chipset and processor for my
>>>desktop. Haven't switched them out yet, waiting to see what
>>>preparations I need to take on Ubuntu before going for it? I'll be
>>>keeping the existing hard drives and video card, as is.
>>
>> ubuntu isn't a microsoft product; there's no code to disable
>> the system after a hardware cange.
>
> There isn't any in windows either.

Rubish ! Windows monitors every change you make.

> However there are compiled in options that could break a linux system
> if they have been used by the OP.

????

--
Best Regards:
Baron.
From: Aragorn on
On Sunday 17 January 2010 07:59 in alt.os.linux, somebody identifying as
Yousuf Khan wrote...

> AZ Nomad wrote:
>
>> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan
>> <bbbl67(a)spammenot.yahoo.com> wrote:
>>
>>> Just purchased a new motherboard/chipset and processor for my
>>> desktop. Haven't switched them out yet, waiting to see what
>>> preparations I need to take on Ubuntu before going for it? I'll be
>>> keeping the existing hard drives and video card, as is.
>>
>> ubuntu isn't a microsoft product; there's no code to disable
>> the system after a hardware cange.
>
> More worried about drivers. The motherboard will be going from Nvidia
> chipset to ATI chipset. Onboard video will change likewise, but
> discrete graphics will remain Nvidia 8600GT.

Stock distribution kernels are always built without processor- or
chipset-specific optimizations. They contain generic code that will
work on all processors or motherboard chipsets of that particular
market segment. By this I mean the type of distribution you are
installing, i.e. IA32 (alias x86, x86-32 or i586 (or perhaps i686)) or
AMD64 (alias x86-64).

The idea behind a binary GNU/Linux distribution is that it would be
compatible with as much of the hardware as possible for that particular
platform - e.g. AMD64 - without getting into any optimizations specific
for Intel or AMD, or chipset optimizations. All chipsets and
processors for the x86 platform processors understand generic x86
instructions, and in some cases the Linux kernel can pick a subset of
(slightly) more optimized instructions specific to a given chipset by
autodetecting what is there.

Processor and chipset support is built into the kernel itself - i.e.
statically linked - as well as some very common peripheral support -
e.g. generic PATA and SATA support and ext3 filesystem support - but
support for other peripherals (like videocards) is loaded via driver
modules. These driver modules are usually all included in the /initrd/
image, and for some, the kernel will autodetect which one to load,
while others are being loaded with prejudice, regardless of whether the
hardware supported by those modules is present or not.

For instance, the stock PCLinuxOS kernel I'm using on this machine here
loads many different types of network adapter modules, of which only
two actually have the hardware present in the system - one being an
on-board connector, the other being a PCI plug-in card.

My advice however would be to disable your on-board video adapter in the
BIOS, because nVidia drivers don't work well with two different types
of video adapters in your system.

The bottom line is that the only variable that seems to exist between
both your old and your new system is that the motherboard and CPU are
different, and those differences will be handled by the Linux kernel
itself through its built-in generic support for just about every
chipset and CPU with the exception of bleeding edge stuff[1] and by
the /initrd/ via all the driver modules it contains. The proprietary
nVidia driver will be working with the same video adapter card, so that
should not be a problem either. Things that require a proprietary
driver module might not be supported, though. This depends on your
distribution and whether it includes proprietary drivers or not.


[1] If the chipset is too new for the kernel, then it'll still be
supported for essential functionality, but then some optional
things might not be correctly detected, e.g. certain hardware
monitoring functions or the likes.

--
*Aragorn*
(registered GNU/Linux user #223157)
From: Kadaitcha Man on
"Aragorn", thou legless lecherous. Like the toad, ugly and venomous. Ye
tehee'd:

> On Sunday 17 January 2010 07:59 in alt.os.linux, somebody identifying as
> Yousuf Khan wrote...
>
>> AZ Nomad wrote:
>>
>>> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan
>>> <bbbl67(a)spammenot.yahoo.com> wrote:
>>>
>>>> Just purchased a new motherboard/chipset and processor for my
>>>> desktop. Haven't switched them out yet, waiting to see what
>>>> preparations I need to take on Ubuntu before going for it? I'll be
>>>> keeping the existing hard drives and video card, as is.
>>>
>>> ubuntu isn't a microsoft product; there's no code to disable the
>>> system after a hardware cange.
>>
>> More worried about drivers. The motherboard will be going from Nvidia
>> chipset to ATI chipset. Onboard video will change likewise, but
>> discrete graphics will remain Nvidia 8600GT.
>
> Stock distribution kernels are always built without processor- or
> chipset-specific optimizations. They contain generic code that will
> work on all processors or motherboard chipsets of that particular market
> segment. By this I mean the type of distribution you are installing,
> i.e. IA32 (alias x86, x86-32 or i586 (or perhaps i686)) or AMD64 (alias
> x86-64).
>
> The idea behind a binary GNU/Linux distribution is that it would be
> compatible with as much of the hardware as possible for that particular
> platform - e.g. AMD64 - without getting into any optimizations specific
> for Intel or AMD, or chipset optimizations. All chipsets and processors
> for the x86 platform processors understand generic x86 instructions, and
> in some cases the Linux kernel can pick a subset of (slightly) more
> optimized instructions specific to a given chipset by autodetecting what
> is there.
>
> Processor and chipset support is built into the kernel itself - i.e.
> statically linked - as well as some very common peripheral support -
> e.g. generic PATA and SATA support and ext3 filesystem support - but
> support for other peripherals (like videocards) is loaded via driver
> modules. These driver modules are usually all included in the /initrd/
> image, and for some, the kernel will autodetect which one to load, while
> others are being loaded with prejudice, regardless of whether the
> hardware supported by those modules is present or not.
>
> For instance, the stock PCLinuxOS kernel I'm using on this machine here
> loads many different types of network adapter modules, of which only two
> actually have the hardware present in the system - one being an on-board
> connector, the other being a PCI plug-in card.
>
> My advice however would be to disable your on-board video adapter in the
> BIOS, because nVidia drivers don't work well with two different types of
> video adapters in your system.
>
> The bottom line is that the only variable that seems to exist between
> both your old and your new system is that the motherboard and CPU are
> different, and those differences will be handled by the Linux kernel
> itself through its built-in generic support for just about every chipset
> and CPU with the exception of bleeding edge stuff[1] and by the /initrd/
> via all the driver modules it contains. The proprietary nVidia driver
> will be working with the same video adapter card, so that should not be
> a problem either. Things that require a proprietary driver module might
> not be supported, though. This depends on your distribution and whether
> it includes proprietary drivers or not.
>
>
> [1] If the chipset is too new for the kernel, then it'll still be
> supported for essential functionality, but then some optional things
> might not be correctly detected, e.g. certain hardware monitoring
> functions or the likes.

Translation: Linux is always compiled for the absolute lowest common
denominator. If your processor is a 1985 386-SX, Linux is guaranteed to
run on it.