1 |
Frank Peters posted on Sat, 08 Jan 2011 18:11:27 -0500 as excerpted: |
2 |
|
3 |
>> Curious: why aren't you using udev? |
4 |
>> |
5 |
>> |
6 |
> I've been using Linux since 1998 and I like most the opportunity |
7 |
> for control that Linux allows. To suit my minimalist needs, I have |
8 |
> customized my system to a great extent. For example, I have completely |
9 |
> eliminated the complex and cumbersome initialization scripts that |
10 |
> are found in /etc/init.d, /etc/conf.d, and other locations. In their |
11 |
> place I wrote my own very simple initialization script that |
12 |
> automatically boots into console (no login). From there I can go to X |
13 |
> (my usual action) or just use the console for configuration, |
14 |
> troubleshooting, or other tasks. |
15 |
|
16 |
> I have also eliminated udev as part of this simplification. I know |
17 |
> what's on my machine and what has to be done to enable it. I would |
18 |
> rather not have actions performed "automagically" for me whenever I plug |
19 |
> in a USB printer of storage device. Part of the reason is philosophical |
20 |
> and part is just a desire to understand the OS better. |
21 |
|
22 |
Wow. I understand exactly why you do it, because I'm the same way, only |
23 |
the Gentoo initscripts are reasonable enough for me and I've enjoyed |
24 |
watching openrc/baselayout2 develop -- in fact, since I actually /grok/ |
25 |
bash scripting at a reasonable level, its the one area I can quite |
26 |
frequently not only submit bug reports, but trace the code and suggest |
27 |
patches, which I've done on a number of occasions. (In one case, once I |
28 |
started hitting an error and traced it, it was quite apparent the error |
29 |
path/case had never been tested at all, as the logic was apparent but the |
30 |
code simply didn't and couldn't work as intended. By the time the |
31 |
original bug was fixed I think I'd had patches for two others taken and |
32 |
helped work on a third, in addition to the one for the original triggering |
33 |
bug.) |
34 |
|
35 |
Also, I remember static dev and highly prefer a dynamic dev, since that |
36 |
makes it that way, it's a simple binary-case (1) device there, the kernel |
37 |
detects the hardware and created a device, any problem must be above that |
38 |
level, (0) device not there, kernel/module/detection problem, that you |
39 |
don't get if the device node always exists regardless of whether the |
40 |
kernel knows what to do with the device or not, since it's a static file. |
41 |
But I definitely understand the appeal and simplicity of doing it the |
42 |
other way, avoiding all the layers on layers of "automagic". |
43 |
|
44 |
But it seems I often have at least one and sometimes two or three |
45 |
initscripts that I've highly modified, either to cover "advanced" |
46 |
functionality the script doesn't offer on its own (back when md-raid first |
47 |
got partitioning support, my version of the script handled that way before |
48 |
Gentoo's did, and I had a bug open for some time on it before Gentoo |
49 |
finally added that feature based on my work and that of another user, as |
50 |
well as the md-raid initscript maintainer; I'm doing similar now with |
51 |
additional file-specific bind-mounts into the bind/named chroot), or to |
52 |
delete complexity I don't need, sometimes both (I simplify the script, |
53 |
cutting out what I don't need, to better undestand it before adding my own |
54 |
advanced functionality). |
55 |
|
56 |
> Linux allows many possibilities for customization and, IMO, that is half |
57 |
> the fun of using it. Most distributions, including Gentoo, adhere to |
58 |
> the standard methods. But if one has the inclination for exploration |
59 |
> then there is much that can be done to go well beyond the standard |
60 |
> methods. |
61 |
|
62 |
And of course, Gentoo makes maintaining customization much easier than |
63 |
many distributions. =:^) I pretty much learned bash, at least the |
64 |
scripting side, by rewriting the Mandrake rc.sysinit script, modularizing |
65 |
it, etc. Then I upgraded to the next version, and had to do it again... |
66 |
Then I upgraded again, and shortly thereafter, started running cooker |
67 |
(rolling "testing" version), at which point I gave up. Gentoo's rolling |
68 |
updates and configuration update management tools make it relatively easy |
69 |
to avoid having a custom config broken. |
70 |
|
71 |
.... |
72 |
|
73 |
Meanwhile, I see you've fixed the problem, but it's worth noting that lspci |
74 |
lists devices based on generic pci-bus device queries, not what the kernel |
75 |
has drivers for. Just because lspci lists it doesn't mean the kernel can |
76 |
handle that device, only that the device returned certain information when |
77 |
the kernel queried for devices on that bus. |
78 |
|
79 |
Unless you use the -k switch, enabled by default with -v, that is (and |
80 |
only on 2.6 kernels, which we're dealing with of course, but...). -k |
81 |
shows kernel drivers handling and/or that can handle a device. In that |
82 |
case, you get that information too if the kernel can handle the device, |
83 |
but devices that the kernel knows not how to handle will still be listed, |
84 |
just without any assigned kernel driver. |
85 |
|
86 |
Maybe you meant that lspci -v (or -k) was saying it had assigned a driver |
87 |
to it, but that's not what you said, you said lspci wouldn't show the |
88 |
sound card as there if the module wasn't loaded, and that's not correct, |
89 |
as it'd still be a device on the bus and would respond to queries (with |
90 |
the results printed) as such. |
91 |
|
92 |
This is an important distinction, because lspci can thus be used to see |
93 |
devices that the kernel does NOT have drivers for (or doesn't have them |
94 |
built and available). Using lspci to see what hardware a machine has |
95 |
(once Linux boots on it at all), so one can google for support status and |
96 |
what driver to use, especially on second-hand equipment where a manual |
97 |
isn't available, and/or where it's easier to run lspci than to crack open |
98 |
the box to look, is a very important usage case for it. If lspci didn't |
99 |
list devices the kernel wasn't configured with drivers for, that wouldn't |
100 |
work, so I'm very glad it DOES list them. =:^) |
101 |
|
102 |
alsa-info.sh, OTOH, I don't know. You may be correct about it. |
103 |
|
104 |
-- |
105 |
Duncan - List replies preferred. No HTML msgs. |
106 |
"Every nonfree program has a lord, a master -- |
107 |
and if you use the program, he is your master." Richard Stallman |