Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37
Date: Sun, 09 Jan 2011 06:10:04
Message-Id: pan.2011.01.09.06.06.24@cox.net
In Reply to: Re: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37 by Frank Peters
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