| 1 |
On 2013-01-25, Rich Freeman wrote: |
| 2 |
|
| 3 |
> On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva <nunojsilva@×××××××.pt> wrote: |
| 4 |
>> Is there any syntax to check if something is either disabled or built as |
| 5 |
>> a module? |
| 6 |
> |
| 7 |
> Very problematic. What is built in for the currently running kernel |
| 8 |
> can be fairly reliably determined by grepping /proc/config.gz - IF |
| 9 |
> support for that was enabled in the kernel. But, there is no |
| 10 |
> guarantee that this kernel will be running on the next boot. |
| 11 |
> Determining what is build as a module really requires interpreting the |
| 12 |
> contents of /lib/modules - a module could have been built after the |
| 13 |
> kernel was built, in which case /proc/config.gz might indicate no |
| 14 |
> support even though it is supported. I don't think DEVTMPFS can be |
| 15 |
> made a module, however (not sure on that). |
| 16 |
|
| 17 |
Sorry, what's the difference between cheching =y and =m? I thought those |
| 18 |
were both part of the kernel config... |
| 19 |
|
| 20 |
> You can also check /usr/src/linux/.config, but the sources might not |
| 21 |
> correspond to the running kernel, or the kernel on the next reboot, or |
| 22 |
> whatever. |
| 23 |
|
| 24 |
Ok, what do these checks do right now? I thought that they were checking |
| 25 |
.config... |
| 26 |
|
| 27 |
So you're saying that it's perfectly OK to check for =y or =n, but that |
| 28 |
it's somehow more difficult to check for =m? |
| 29 |
|
| 30 |
> It really is a touchy situation, hence all the emails in the thread. |
| 31 |
> You can build something that will work OK 80% of the time though by |
| 32 |
> checking the source tree. |
| 33 |
|
| 34 |
I am not taking about introducing a different way to check, just asking |
| 35 |
if there is a way to make the broadcom-sta check a bit more realistic. |
| 36 |
|
| 37 |
> Part of me wonders if we should just ship a binary kernel/initramfs as |
| 38 |
> an option. Then again, users could just use genkernel and get |
| 39 |
> something like that anyway. My main issue with genkernel is that its |
| 40 |
> default options are focused more on the install CD than ordinary use - |
| 41 |
> things like tuners/multimedia/lirc and the like tend to not be |
| 42 |
> enabled. I would think a typical desktop-oriented distro is going to |
| 43 |
> enable as a module anything that doesn't cause breakage. |
| 44 |
|
| 45 |
This won't even solve the issue, even if some people may actually prefer |
| 46 |
a pre-built kernel. |
| 47 |
|
| 48 |
It would be a bit more realistic to perform checks against *all* the |
| 49 |
kernels under /usr/src/linux, in a non-fatal way, of course. This would |
| 50 |
still generate lots of noise, but would produce a more useful output, |
| 51 |
like: |
| 52 |
|
| 53 |
| net-wireless/broadcom-sta - The following issues were found: |
| 54 |
| |
| 55 |
| Option CONFIG_B43 cannot be built-in, but was found to be built-in in |
| 56 |
| the following kernels : |
| 57 |
| |
| 58 |
| - linux-2.6.30-gentoo-r5 |
| 59 |
| - linux-2.6.34-gentoo-r6 |
| 60 |
| - linux-3.2.1-gentoo-r2 |
| 61 |
|
| 62 |
|
| 63 |
Or maybe have a dedicated directory to store .config's portage should |
| 64 |
check against, and check only against these. |
| 65 |
|
| 66 |
But, definitely, fatal checks should not be a default, there are way too |
| 67 |
many scenarios. |
| 68 |
|
| 69 |
-- |
| 70 |
Nuno Silva (aka njsg) |
| 71 |
http://njsg.sdf-eu.org/ |
Archives