Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Mounting /dev/sdaX on boot does not work
Date: Wed, 30 Jan 2008 23:28:36
Message-Id: 200801310126.23084.alan.mckinnon@gmail.com
In Reply to: Re: [gentoo-user] Mounting /dev/sdaX on boot does not work by Mateusz Mierzwinski
1 On Thursday 31 January 2008, Mateusz Mierzwinski wrote:
2 > Talking about modularize kernel i think this is an gentoo mailing
3 > list so every user know's his hardware - if not there is always
4 > GOOGLE, Gentoo HowTo and Hardware Manual. Most drivers in kernel are
5 > universal for one vendor family what makes more suitable to different
6 > types of chipsets (revisions A, B etc...). There is also true that
7 > maybee kernel modules are good for people with binary distro's but
8 > Gentoo is source based distribution - thank god - and every user
9 > should compile kernel for his hardware - modules not needed.
10
11 Rubbish. Let's say tomorrow I plug in a USB sound card, joystick and
12 HSDPA modem. Today I do not have this hardware.
13
14 Should I rebuild my kernel just to use a hotplug device that I borrowed
15 for a few hours? No, thanks, I'm going to use modrobe.
16
17 To get my sound card to work, I need a parameter "dell=m42". How should
18 I easily pass this argument without modules? Should I have a webcam
19 driver permanently loaded in kernel space just for the odd case where I
20 decide to use it?
21
22 1995 called, they say they want their hardware back.
23
24 > Cheap
25 > code modules are also bad rule of cheap programmers, which don't know
26 > system and kernel structures. Afterwords thats how making usage of
27 > NDISWRAPPER is fundamental on Windows drivers hardware.
28
29 <sigh>
30
31 If a crap programmer writes a module, it will be crap and do $BAD_STUFF.
32 How does this change if the crap programmer is forced to not write
33 modules? Does he suddenly get enlightened and know what K&R have been
34 telling him for years?
35
36 CRAP PROGRAMMERS WRITE CRAP CODE. MODULES ARE COMPLETELY IRRELEVANT TO
37 THIS.
38
39
40 > If we speak about realtime preemption model i think that You are
41 > mistaken saying that PC and realtime kernels (software) is not good
42 > choice. My licentiate work on University of Silesia (Poland,
43 > Katowice) is about usage of realtime services in computer LAN/WAN
44 > networks. I digging some materials about RTOS and realtime preemption
45 > model, realtime schedule algorithm and realtime applications critical
46 > points programming. I don't know if PC + Realtime preemption model is
47 > something wrong. When You need critical services for network such as
48 > multiplexed SDH traffic control and violation prevention You must
49 > have great power computer with RTOS, that can monitor min. 166MB/s
50 > traffic full duplex. Now-days computers have enough power to stand
51 > with RISC (Reduced Instruction Set Computing) machines - thats why
52 > Sun Solaris has arrived on PC's. Another big step is RTLinux with
53 > dual core - realtime core and Linux kernel working together.
54
55 That type of usage is not my area of expertise, but I can tell that it's
56 a niche market. If monolithicality is the correct design paradigm
57 there, then the designer has the option of building a monolithic
58 kernel. If you can coerce it to work on Intel cpus, well that's fine
59 and dandy and attests to the power and adaptibility of Linux.
60
61 But how does this support your assertion that modules are a bad idea?
62 You have the choice to do it a better way in those circumstances.
63 Meanwhile, the vast majority of server nd desktop deployments out there
64 that truly do need kernel modules (including Gentoo) cna and should
65 continue to use them.
66
67
68 --
69 Alan McKinnon
70 alan dot mckinnon at gmail dot com
71 --
72 gentoo-user@l.g.o mailing list

Replies

Subject Author
Re: [gentoo-user] Mounting /dev/sdaX on boot does not work Mateusz Mierzwinski <mateuszmierzwinski@××.pl>
Re: [gentoo-user] Mounting /dev/sdaX on boot does not work Etaoin Shrdlu <shrdlu@×××××××××××××.org>