 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 10 Dec 2008 15:29:48 -0500, Tom Austin wrote:
>
>> It came in handy when I was still trying to figure out how to make it
>> boot. I could boot into a full environment without having to worry
>> about how to access the CF card and mount it. I could actually get it
>> up and running, then play with things until I figured it out.
>
> Oh yeah, very much so. The thing to remember is if you rebuild your
> kernel, you also need to rebuild your initrd with 'mkinitrd' or you'll
> find the system won't boot.
>
> Jim
actually now that I've had more time to think about it, I was actually
using initramfs which has settings to build and pack with the kernel
image. Made it very simple indeed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 10 Dec 2008 16:27:30 -0500, Tom Austin wrote:
> actually now that I've had more time to think about it, I was actually
> using initramfs which has settings to build and pack with the kernel
> image. Made it very simple indeed.
Oh, yeah, that definitely would make it simple. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> No Linux drivers for what high-end expensive graphics cards, exactly?
No accelerated Linux drivers for almost any graphics card.
...I mean for DirectFB, not X :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Do you have *any idea* how long it takes to compile the Linux kernel? I
> mean, damn, how *big* is it?? I thought the final binary was only a few
> KB in size...
My kernel size is about 1,4MB and compiling it takes a few minutes on
Core2Duo system. So it does not take long at all. If you forgot one
driver, the recompile takes even less as not everything has to be
recompiled again.
Why?
Because troubleshooting is easier as I know what is in the kernel and
what is not. Loading it is marginally faster because I only use what I
need. Booting is faster for the same reasons.
For the record: it takes only 11 seconds for my system to go from Grub
menu to login (no X at that point). I use Gentoo.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> My kernel size is about 1,4MB and compiling it takes a few minutes on
> Core2Duo system. So it does not take long at all. If you forgot one
> driver, the recompile takes even less as not everything has to be
> recompiled again.
I still remember compiling Gtk2hs on my laptop. Man, that took a long
time! Mind you, we're talking about a machine with a 32bit processor...
Plus, GTK+ is *huge*!
Still, I guess once you take the "kernel" and add 50,000 device drivers,
it's going to end up rather large. (And presumably even if you disable
something, it still has to do some minimal processing to see that it's
disabled.)
> Why?
>
> Because troubleshooting is easier as I know what is in the kernel and
> what is not. Loading it is marginally faster because I only use what I
> need. Booting is faster for the same reasons.
I would have thought changing the runlevel scripts would have a far
bigger impact...
> For the record: it takes only 11 seconds for my system to go from Grub
> menu to login (no X at that point). I use Gentoo.
For the record: my PC takes about 30 seconds just for the BIOS to finish
doing it's thing. I don't really know why... (Might have something to do
with the RAID functionallity I'm not using.)
I use Windows XP.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's the classical monolithic kernel vs. microkernel war. There are
> advantages and disadvantages in both methods.
Ah ok, so on Windows the kernel includes code to call/use any generic driver
(that is not part of the kernel itself), but on Linux the kernel actually
includes the drivers. And that means if you want to add/remove drivers from
your system completely, you need to recompile the kernel under Linux. Is
that right?
> For example, one disadvantage of Windows is that each new version of
> Windows always breaks a bunch of old drivers, so when you upgrade Windows
> you may find out that your old peripheral just doesn't work anymore.
Yep, am aware of that, usually with non-so-popular hardware you have to wait
an age for the developer to release new drivers.
> When the driver is integrated into the kernel, like in linux, it will
> obviously always work even if the kernel is seriously updated (because
> all the embedded drivers will be updated for the new kernel design as
> well).
When they release a new Linux kernel, how can they be sure that they haven't
broken some other driver out there that someone wants to compile in with
this new kernel? Or is it impossible to develop a driver by yourself
separate to the Linux kernel?
> OTOH linux does support kernel modules. For example, if you want to
> install, let's say, the ATI binary driver, you don't need to recompile
> the kernel.
Hmm ok, so under Linux you have the choice of either running a driver as a
separate module, or compiled in with the kernel?
So what are the benefits of compiling in the driver with the kernel as
opposed to running it as a module then?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > It's the classical monolithic kernel vs. microkernel war. There are
> > advantages and disadvantages in both methods.
> Ah ok, so on Windows the kernel includes code to call/use any generic driver
> (that is not part of the kernel itself), but on Linux the kernel actually
> includes the drivers. And that means if you want to add/remove drivers from
> your system completely, you need to recompile the kernel under Linux. Is
> that right?
Not really, because the linux kernel supports loadable modules. However,
it does support drivers embedded in the kernel as well.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Not really, because the linux kernel supports loadable modules. However,
> it does support drivers embedded in the kernel as well.
Yeh I figured that out by the end of reading your post, so what are the pros
and cons of loadable modules compared to drivers embedded in the kernel? If
needing to install an embedded driver requires recompiling the kernel, why
not just use a module instead - wouldn't it be much quicker to install?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 10 Dec 2008 16:27:30 -0500, Tom Austin wrote:
>
>> actually now that I've had more time to think about it, I was actually
>> using initramfs which has settings to build and pack with the kernel
>> image. Made it very simple indeed.
>
> Oh, yeah, that definitely would make it simple. :-)
>
> Jim
What wasn't simple was figuring out that there was a problem with the
the baud rate multiplier in my test setup. I still don't understand
the origins of it, but with a patch I got the gibberish turned into
actual text.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>
> Yeh I figured that out by the end of reading your post, so what are the
> pros and cons of loadable modules compared to drivers embedded in the
> kernel? If needing to install an embedded driver requires recompiling
> the kernel, why not just use a module instead - wouldn't it be much
> quicker to install?
>
Yes, it is, Module can also be unloaded and reloaded, which usually
leads to resetting the device itself. Therefore jammed device or driver
(module) won't end by the whole computer needing a reboot.
Basically only pro for built-in drivers instead of modules is that they
are automatically available. If you'll eg. compile your SATA-drivers as
module, you'll need to load them before you can find HD's. While the
modules are on the HD, you'll need to get them to memory before that,
which means you'll need to do initrd (or initramrd oslt, which is easier
today IIUC).
So, the easy but still efficient basics: disk and RAID -drivers
built-in, others as module.
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
