How does one check the existence of the kernel source RPM (or deb) on
every single distribution?.
We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
SuSE, Mandrake and CentOS - how about other RPM based distros? How
about debian based distros?. There doesn't seem to be a a single
conherent naming scheme.
Another thing, can we please start enforcing that people ship kernel
source with the base installation? If distributors are distributing
kernels, then it must be an absolute requirement that they ship kernel
sources in a "configured" state as well. If you're not going to
provide a stable kernel API, then atleast please make this a requirement.
best regards
Dev Mazumdar
4Front Technologies
http://www.opensound.com
On Thu, 25 May 2006, devmazumdar wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
>
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> SuSE, Mandrake and CentOS - how about other RPM based distros? How
> about debian based distros?. There doesn't seem to be a a single
> conherent naming scheme.
Actually it does not on later versions of fedora (4 & 5). The headers are
included, but not the source. If you want to build modules, you must have
kernel-devel installed.
--
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis
On Thu, 2006-05-25 21:19:33 -0000, devmazumdar <[email protected]> wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
You don't. That's the user's task!
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> SuSE, Mandrake and CentOS - how about other RPM based distros? How
> about debian based distros?. There doesn't seem to be a a single
> conherent naming scheme.
Indeed, there isn't. Think about selfmade installations. Just ask the
user to provide you with the correct path. There may even be several
kernel version's source trees installed, with different configuration.
> Another thing, can we please start enforcing that people ship kernel
> source with the base installation? If distributors are distributing
No way.
> kernels, then it must be an absolute requirement that they ship kernel
> sources in a "configured" state as well. If you're not going to
> provide a stable kernel API, then atleast please make this a requirement.
Distros *will* ship kernel's configuration, but that'll never ever be
installed by default.
If you work on drivers (as it seems), please just clean up the code
and post it to the kernel mailing list (or subsystem specific lists.)
Once it meets the standards, it'll just become a part of the tree,
releasing you from the burden to think about its local installation.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Thu, 25 May 2006 21:19:33 -0000, devmazumdar said:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
>
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> SuSE, Mandrake and CentOS - how about other RPM based distros?
There's no kernel-source RPM on recent Fedora. Also, there's another problem...
On my laptop at the moment:
% rpm -q kernel
kernel-2.6.16-1.2215_FC6
% uname -r
2.6.17-rc4-mm3
Did you want the vendor kernel source, or the running kernel source?
Might want to look at the symlink at /lib/modules/`uname -r`/source which
is probably as sane as it gets... (Though admittedly Fedora points it
into the wild blue yonder of /usr/src/kernels/`uname -r` which isn't
where the non-existent kernel-source RPM puts it. Getting the .src.rpm
and working from there leaves it in /usr/src/redhat/BUILD/yadda-yadda....)
Hi,
On 25/05/06, devmazumdar <[email protected]> wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
How about something like this
if [ -f /lib/modules/`uname -r`/build/Makefile ]
then
...
fi
[snip]
> provide a stable kernel API, then atleast please make this a requirement.
>
>
> best regards
>
> Dev Mazumdar
> 4Front Technologies
> http://www.opensound.com
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
On Thu, May 25, 2006 at 05:29:59PM -0400, [email protected] wrote:
> Might want to look at the symlink at /lib/modules/`uname -r`/source which
> is probably as sane as it gets... (Though admittedly Fedora points it
> into the wild blue yonder of /usr/src/kernels/`uname -r` which isn't
> where the non-existent kernel-source RPM puts it. Getting the .src.rpm
> and working from there leaves it in /usr/src/redhat/BUILD/yadda-yadda....)
It's pointing at the files installed by the kernel-devel package.
Dave
--
http://www.codemonkey.org.uk
On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
>
> find / -name libata-scsi.c
Which of the 10 versions showing up is the "right" one?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Thu, May 25, 2006 at 09:19:33PM -0000, devmazumdar wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
>
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
Actually, no it doesn't. The kernel source in RHEL4 & Fedora
is an srpm just like every other source package. Now, if you're
referring to kernel headers to build modules against, it's still
incorrect, that's a package called kernel-devel.
> SuSE, Mandrake and CentOS - how about other RPM based distros? How
> about debian based distros?. There doesn't seem to be a a single
> conherent naming scheme.
Why should there be? When people do things independantly, it's
unlikely they all arrive at the same solutions, and converging
back afterwards is difficult once there are deployments in the field.
(Even within 1 distro, when we moved from the kernel-source package
you referenced, to a .srpm, the fallout went on for *months*[1]).
You seem somewhat surprised at this. It may sound trivial, but
getting agreement on issues like this across distributions is a
long drawn out process. (See the LSB archives for some of the
madness surrounding issues like this).
> Another thing, can we please start enforcing that people ship kernel
> source with the base installation?
So you want to increase the footprint of everyone's minimal install,
even though the vast majority of users will never need it?
This isn't going to fly. Not everyone builds add-on modules.
> If distributors are distributing kernels, then it must be an absolute
> requirement that they ship kernel sources in a "configured" state as well.
On a Fedora system: yum install kernel-devel
As mentioned at length in the release notes.
Perhaps if you explain your problem in a less abrasive way instead of
coming here with demands, maybe something can be done to improve
whatever process you feel is failing.
Dave
[1] Given you seem to have missed this, it could be argued that it's
still ongoing, highlighting just how much of a problem renaming stuff causes.
--
http://www.codemonkey.org.uk
Jan-Benedict Glaw wrote:
> On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
>> find / -name libata-scsi.c
>
> Which of the 10 versions showing up is the "right" one?
If its pulling up my libata core, they are all the "right" one...
Jeff
On Thu, May 25, 2006 at 11:39:52PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
> >
> > find / -name libata-scsi.c
>
> Which of the 10 versions showing up is the "right" one?
For the sake of compiling out-of-tree modules, it's also useless,
as sanitised headers (like Fedora's kernel-devel package) won't have this.
Following /lib/modules/`uname -r`/build is the only way this can work.
(And that should be true on any distro)
Dave
--
http://www.codemonkey.org.uk
On Thu, 2006-05-25 at 23:29 +0200, Jan-Benedict Glaw wrote:
> If you work on drivers (as it seems), please just clean up the code
> and post it to the kernel mailing list (or subsystem specific lists.)
> Once it meets the standards, it'll just become a part of the tree,
> releasing you from the burden to think about its local installation.
I am fairly certain the drivers in question are closed source.
>From http://www.opensound.com:
"OSS is now free for home/personal use and doesn't have any restrictions
other than refreshing the software every 4months."
Lee
Lee Revell wrote:
> On Thu, 2006-05-25 at 23:29 +0200, Jan-Benedict Glaw wrote:
>> If you work on drivers (as it seems), please just clean up the code
>> and post it to the kernel mailing list (or subsystem specific lists.)
>> Once it meets the standards, it'll just become a part of the tree,
>> releasing you from the burden to think about its local installation.
>
> I am fairly certain the drivers in question are closed source.
>
>>From http://www.opensound.com:
>
> "OSS is now free for home/personal use and doesn't have any restrictions
> other than refreshing the software every 4months."
>
> Lee
>
>
Yes we are one and the same Open Sound System guys! :)
It doesn't matter if it's open sound or ALSA!. Lee, why don't you go down the
ALSA user mailing lists and count the number of 0-Compilation bug reports?
The same problems that affect ALSA (Fixed in CVS being the standard answer of
why a sound driver isn't working) affects 4Front's OSS as well.
If you're telling people to compile ALSA downloaded from CVS,
you'd ensure that before they start filing bug reports:
1) people had their kernel source installed
2) kernel sources were "configured" for the running kernel
3) compilers/build utils and other libs would
best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
On Thu, 2006-05-25 at 15:15 -0700, 4Front Technologies wrote:
> It doesn't matter if it's open sound or ALSA!. Lee, why don't you go
> down the ALSA user mailing lists and count the number of 0-Compilation
> bug reports?
I know - I am on all the ALSA lists and read every bug report. And in
fact compilation errors are quite rare. The numbers are misleading
because "0-Compilation error" is the default category in the bug tracker
and lots of users don't set it correctly ;-)
It is unfortunate that users hitting an already-fixed bug have to
compile it themselves, but I think the solution is for the distros to
follow ALSA a bit more closely and apply the critical "no sound" fixes
to their packages rather than waiting for the next release. I know for
a fact that Ubuntu does this.
Lee
On Thu, 2006-05-25 at 21:19 +0000, devmazumdar wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
>
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> SuSE, Mandrake and CentOS - how about other RPM based distros? How
> about debian based distros?. There doesn't seem to be a a single
> conherent naming scheme.
I'd really like to see a distro-agnostic way to retrieve the kernel
configuration. /proc/config.gz has existed for soem time but many
distros inexplicably don't enable it.
Lee
On Thu, May 25, 2006 at 06:25:43PM -0400, Lee Revell wrote:
> It is unfortunate that users hitting an already-fixed bug have to
> compile it themselves, but I think the solution is for the distros to
> follow ALSA a bit more closely and apply the critical "no sound" fixes
> to their packages rather than waiting for the next release. I know for
> a fact that Ubuntu does this.
Now imagine if every subsystem took this attitude ?
We'd end up with distro kernels with *hundreds* of patches
(Which speaking from experience managing such a mess is no fun at all).
Trying to get some developers to look at bugs in distro kernels is
hard enough already. If they're patched to the hilt with every subsystems
patch of the day, the response becomes..
"Hmm, distro kernel crap, try and reproduce on mainline".
Given these bug reports are coming from end-users many of which don't
have a clue how to compile a kernel (nor should they), the bug report
then sits there and festers.
The answer is not "push more patches to distros" the answer is
"subsystems need to push more fixes to -stable when bugs are fixed
instead of sitting on them in private SCMs for 2 months waiting
for the next merge window".
Dave
--
http://www.codemonkey.org.uk
Lee Revell wrote:
> On Thu, 2006-05-25 at 21:19 +0000, devmazumdar wrote:
>> How does one check the existence of the kernel source RPM (or deb) on
>> every single distribution?.
>>
>> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
>> SuSE, Mandrake and CentOS - how about other RPM based distros? How
>> about debian based distros?. There doesn't seem to be a a single
>> conherent naming scheme.
>
> I'd really like to see a distro-agnostic way to retrieve the kernel
> configuration. /proc/config.gz has existed for soem time but many
> distros inexplicably don't enable it.
>
> Lee
>
>
A-men to that!. Basically what really needs to happen is for all the distros to
adopt Fedora's way of shipping kernel headers. If you're not going to ship
source for the kernel, atleast ship kernel headers for the kernel that you are
running.
Anything to get out-of-kernel modules compiling without jumping through 1000
hoops is good.
best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
On Thu, 2006-05-25 at 18:34 -0400, Dave Jones wrote:
> The answer is not "push more patches to distros" the answer is
> "subsystems need to push more fixes to -stable when bugs are fixed
> instead of sitting on them in private SCMs for 2 months waiting
> for the next merge window".
ALSA recently moved from sourceforge CVS to a Mercurial repository which
should make this easier in the future.
Lee
On Thu, May 25, 2006 at 05:44:13PM -0400, Dave Jones wrote:
> Following /lib/modules/`uname -r`/build is the only way this can work.
> (And that should be true on any distro)
On one side it's a reasonably nice way, on the other it makes it hard
to build modules for a different kernel than the running one. I have
a uname version in a corner that allows overriding the -r return with
an environment variable just for that reason, I should probably send
the path upstream.
OG.
On 25/05/06, devmazumdar <[email protected]> wrote:
> How does one check the existence of the kernel source RPM (or deb) on
> every single distribution?.
>
> We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> SuSE, Mandrake and CentOS - how about other RPM based distros? How
> about debian based distros?. There doesn't seem to be a a single
> conherent naming scheme.
>
There *is* no coherent naming scheme.
Also, RPM's and .deb's are not the only package formats out there. You
are forgetting (just to name a few) :
- Slackware Linux's package format
- Stampede Linux's package format
- Arch Linux's package format
and there are more...
Then there are people building custom distros from scratch. And then
there are people like me who's distro does ship a kernel package &&
kernel-source package but who doesn't use them, but instead build &
run custom kernels from kernel.org source tarballs.
Finding a way to detect if people have kernel sources available that
are configured to match the current running kernel that'll work for
everyone is a lost cause - give it up.
Looking in /lib/modules/$(uname -r)/build/ and/or
/lib/modules/$(uname -r)/source/ is probably the best you can do (and
doing that makes sense - at least to me)...
> Another thing, can we please start enforcing that people ship kernel
> source with the base installation? If distributors are distributing
> kernels, then it must be an absolute requirement that they ship kernel
> sources in a "configured" state as well. If you're not going to
> provide a stable kernel API, then atleast please make this a requirement.
>
Ehh, no.
It's not for the kernel developers to mandate what distributions
install. All we can (and should) require is that they obey the GPL and
make source available according to the terms set forth in the license.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
El Thu, 25 May 2006 18:29:22 -0400,
Lee Revell <[email protected]> escribi?:
> I'd really like to see a distro-agnostic way to retrieve the kernel
> configuration. /proc/config.gz has existed for soem time but many
> distros inexplicably don't enable it.
/proc/config.gz takes a bit of memory, and wasting such memory when
you can store the config at /boot/config-`uname -r` is a bit weird.
On 26/05/06, 4Front Technologies <[email protected]> wrote:
>
> Anything to get out-of-kernel modules compiling without jumping through 1000
> hoops is good.
>
hmm, I'd say that anything that encourages people to merge their code
with mainline instead of maintaining out-of-tree modules is good.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
> On 26/05/06, 4Front Technologies <[email protected]> wrote:
>>
>> Anything to get out-of-kernel modules compiling without jumping
>> through 1000
>> hoops is good.
>>
>
> hmm, I'd say that anything that encourages people to merge their code
> with mainline instead of maintaining out-of-tree modules is good.
>
Honestly, if I put Open Sound drivers under GPL would Linus really merge my code
back into the kernel?. Be honest!
If you aren't going to maintain OSS, then give me a way to support my product!.
best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
Jesper Juhl wrote:
>
> Finding a way to detect if people have kernel sources available that
> are configured to match the current running kernel that'll work for
> everyone is a lost cause - give it up.
> Looking in /lib/modules/$(uname -r)/build/ and/or
> /lib/modules/$(uname -r)/source/ is probably the best you can do (and
> doing that makes sense - at least to me)...
>
>
Yeah,
I alway thought that this was the correct way...
And theese links are also found on Mandriva...
Not to mention Ati & nVidia installers that also check for theese links...
--
Regards
Thomas
Dev,
It appears that you might be fairly new to the game of maintaining open
source kernel modules outside of mainline. Having worked for a number
of years providing STREAMS distributions outside of mainline and that
need to be compatible with a wide range of distributions, I spent some
amount of time developing a GNU autoconf/automake based approach that
works with most major distributions.
Even though Linux Fast-STREAMS has proven that STREAMS-based pipes can
outperform Linux SVR 3.2 based pipes under FC4 (see
http://www.openss7.org/streams_perf.html ), and current UDP tests show
that STREAMS easily rivals a sockets-based approach, strong dogmatic
opinions against STREAMS keeps it from being accepted in the mainline
(see http://www.tux.org/#s9-9 ).
You seem to be in a similar circumstance. What the autoconf macros
developed as part of the OpenSS7 Project do are as follows:
- identifies the distribution
- identifies the running or target kernel
- locates configured sources appropriate for build
- identifies other LSB related issues such as init scripts
- builds source and binary RPM packages and source and binary Debian
packages
Several common issues with building outside the kernel tree on
production distributions addressed are as follows:
- provides access to non-exported symbols (note that OpenSS7 is released
under GPLv2 so there are no issues for OpenSS7 packages).
- provides methods for performing all autoconf tests against kernel
headers or source. Often for production distributions testing kernel
version is not sufficient because kernels have been hacked by the
distributor: this provides a means to test the actual kernel rather
than basing tests on kernel versions.
- extracts compilation flags from kernel Makefiles and works with both
2.4 and 2.6 kernel series, as well as distribution-hacked makefiles.
- by identifying the distribution, locates kernel sources and
configuration files in a distribution dependent fashion.
- suitable for use with RPM spec files and Debian build scripts.
If you would like to take a look, download the streams-0.7a.4.tar.bz2
from http://www.openss7.org/download.html and take a look at the
autoconf macros in the m4 subdirectory, the automake makefile fragments
in the am subdirectory, scripts in the scripts subdirectory,
acinclude.m4, the streams.spec.in RPM spec file, and the debian
subdirectory.
If there is sufficient interest, I would entertain separately
maintaining the autoconf/automake fragments.
--brian
On Thu, 25 May 2006, 4Front Technologies wrote:
> Jesper Juhl wrote:
> > On 26/05/06, 4Front Technologies <[email protected]> wrote:
> >>
> >> Anything to get out-of-kernel modules compiling without jumping
> >> through 1000
> >> hoops is good.
> >>
> >
> > hmm, I'd say that anything that encourages people to merge their code
> > with mainline instead of maintaining out-of-tree modules is good.
> >
>
>
> Honestly, if I put Open Sound drivers under GPL would Linus really merge my code
> back into the kernel?. Be honest!
>
>
> If you aren't going to maintain OSS, then give me a way to support my product!.
>
>
>
>
>
> best regards
>
> Dev Mazumdar
> -----------------------------------------------------------
> 4Front Technologies
> 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
> Tel: (310) 202 8530 URL: http://www.opensound.com
> Fax: (310) 202 0496 Email: [email protected]
> -----------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Brian F. G. Bidulock ? The reasonable man adapts himself to the ?
[email protected] ? world; the unreasonable one persists in ?
http://www.openss7.org/ ? trying to adapt the world to himself. ?
? Therefore all progress depends on the ?
? unreasonable man. -- George Bernard Shaw ?
Diego Calleja <[email protected]> writes:
> El Thu, 25 May 2006 18:29:22 -0400,
> Lee Revell <[email protected]> escribi?:
>
>> I'd really like to see a distro-agnostic way to retrieve the kernel
>> configuration. /proc/config.gz has existed for soem time but many
>> distros inexplicably don't enable it.
>
> /proc/config.gz takes a bit of memory, and wasting such memory when
Yes, 9k on my machine.
> you can store the config at /boot/config-`uname -r` is a bit weird.
There's no guaranteeing that file will match the running kernel. Then
again, modules can be changed without /proc/config.gz changing.
--
M?ns Rullg?rd
[email protected]
Hi,
On Fri, May 26, 2006 at 12:52:22AM +0200, Olivier Galibert wrote:
> On Thu, May 25, 2006 at 05:44:13PM -0400, Dave Jones wrote:
> > Following /lib/modules/`uname -r`/build is the only way this can work.
> > (And that should be true on any distro)
>
> On one side it's a reasonably nice way, on the other it makes it hard
> to build modules for a different kernel than the running one. I have
> a uname version in a corner that allows overriding the -r return with
> an environment variable just for that reason, I should probably send
> the path upstream.
I agree with Olivier here.
The trick above should only be a hint to propose to the user what has
been found. If he doesn't know, it's certainly OK. Otherwise, he must
have the ability to use anything else (often needed for packaging or
for cross-building).
Regards,
Willy
On Thu, 2006-05-25 at 18:29 -0400, Lee Revell wrote:
> On Thu, 2006-05-25 at 21:19 +0000, devmazumdar wrote:
> > How does one check the existence of the kernel source RPM (or deb) on
> > every single distribution?.
> >
> > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > about debian based distros?. There doesn't seem to be a a single
> > conherent naming scheme.
>
> I'd really like to see a distro-agnostic way to retrieve the kernel
> configuration. /proc/config.gz has existed for soem time but many
> distros inexplicably don't enable it.
/boot/config-`uname -r`
On Thu, 2006-05-25 17:42:16 -0400, Jeff Garzik <[email protected]> wrote:
> Jan-Benedict Glaw wrote:
> >On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
> >>find / -name libata-scsi.c
> >
> >Which of the 10 versions showing up is the "right" one?
>
> If its pulling up my libata core, they are all the "right" one...
:-)
Unfortunately it's not the case, because these trees are all
configured differently...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Thu, 2006-05-25 17:44:13 -0400, Dave Jones <[email protected]> wrote:
> On Thu, May 25, 2006 at 11:39:52PM +0200, Jan-Benedict Glaw wrote:
> > On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
> > >
> > > find / -name libata-scsi.c
> >
> > Which of the 10 versions showing up is the "right" one?
>
> For the sake of compiling out-of-tree modules, it's also useless,
> as sanitised headers (like Fedora's kernel-devel package) won't have this.
>
> Following /lib/modules/`uname -r`/build is the only way this can work.
> (And that should be true on any distro)
As long as you actually compile the modules on the machine they're
ment to run on...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Fri, 26 May 2006, Jan-Benedict Glaw wrote:
> On Thu, 2006-05-25 17:44:13 -0400, Dave Jones <[email protected]> wrote:
>> On Thu, May 25, 2006 at 11:39:52PM +0200, Jan-Benedict Glaw wrote:
>> > On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
>> >>
>> >> find / -name libata-scsi.c
>> >
>> > Which of the 10 versions showing up is the "right" one?
>>
>> For the sake of compiling out-of-tree modules, it's also useless,
>> as sanitised headers (like Fedora's kernel-devel package) won't have this.
>>
>> Following /lib/modules/`uname -r`/build is the only way this can work.
>> (And that should be true on any distro)
>
> As long as you actually compile the modules on the machine they're
> ment to run on...
>
> MfG, JBG
Distributions really need to have been built on the target system
so that the CONFIG variables are correct and the various dynamic
files have been created. Therefore I suggest that the presence of:
/usr/src/linux-`uname -r`/System.map
... is probably good enough for most everyone.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.73 BogoMips).
New book: http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Arjan,
On Fri, 26 May 2006, Arjan van de Ven wrote:
> On Thu, 2006-05-25 at 18:29 -0400, Lee Revell wrote:
> > On Thu, 2006-05-25 at 21:19 +0000, devmazumdar wrote:
> > > How does one check the existence of the kernel source RPM (or deb) on
> > > every single distribution?.
> > >
> > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > about debian based distros?. There doesn't seem to be a a single
> > > conherent naming scheme.
> >
> > I'd really like to see a distro-agnostic way to retrieve the kernel
> > configuration. /proc/config.gz has existed for soem time but many
> > distros inexplicably don't enable it.
>
> /boot/config-`uname -r`
>
Redhat and SuSE put /boot/config- files of the same name for different
architectures (i386, i586) in the same file. If multiple architecture
kernels of the same verion are installed, there is no guarantee that the
/boot/config-`uname -r` is not for, say, i686 instead of i386. It takes
rpm -q --qf "%{ARCH}" --whatprovides /boot/config-`uname -r`
complared with
uname -m
to see if the mismatch occurs.
Debian (Woody), OTOH strips extra names of their kernels, so 3 or 4
different releases of the same upstream kernel version all install with
the same name and report `uname -r` the same. If multiple of these
kernels and a vanilla kernel are installed, their config files will be
difficult to distinguish. dpkg can be used (similar to above for rpm)
to test the condition.
/boot/config-`uname -r`
works reliability only on Mandrake.
--brian
--
Brian F. G. Bidulock ? The reasonable man adapts himself to the ?
[email protected] ? world; the unreasonable one persists in ?
http://www.openss7.org/ ? trying to adapt the world to himself. ?
? Therefore all progress depends on the ?
? unreasonable man. -- George Bernard Shaw ?
On 26/05/06, linux-os (Dick Johnson) <[email protected]> wrote:
>
> On Fri, 26 May 2006, Jan-Benedict Glaw wrote:
>
> > On Thu, 2006-05-25 17:44:13 -0400, Dave Jones <[email protected]> wrote:
> >> On Thu, May 25, 2006 at 11:39:52PM +0200, Jan-Benedict Glaw wrote:
> >> > On Thu, 2006-05-25 17:34:34 -0400, Jeff Garzik <[email protected]> wrote:
> >> >>
> >> >> find / -name libata-scsi.c
> >> >
> >> > Which of the 10 versions showing up is the "right" one?
> >>
> >> For the sake of compiling out-of-tree modules, it's also useless,
> >> as sanitised headers (like Fedora's kernel-devel package) won't have this.
> >>
> >> Following /lib/modules/`uname -r`/build is the only way this can work.
> >> (And that should be true on any distro)
> >
> > As long as you actually compile the modules on the machine they're
> > ment to run on...
> >
> > MfG, JBG
>
> Distributions really need to have been built on the target system
> so that the CONFIG variables are correct and the various dynamic
> files have been created. Therefore I suggest that the presence of:
>
> /usr/src/linux-`uname -r`/System.map
>
> ... is probably good enough for most everyone.
>
Assuming you build your kernels in /usr/src/ - many people don't, me included.
My kernels are all build in /home/juhl/download/kernel/linux-<version>/
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
> >
>
> Redhat and SuSE put /boot/config- files of the same name for different
> architectures (i386, i586) in the same file. If multiple architecture
> kernels of the same verion are installed, there is no guarantee that the
> /boot/config-`uname -r` is not for, say, i686 instead of i386.
at least on fedora you can't do that parallel installation anyway
On May 26, 2006, at 11:35:30, Brian F. G. Bidulock wrote:
> On Fri, 26 May 2006, Arjan van de Ven wrote:
>> /boot/config-`uname -r`
>
> Debian (Woody), OTOH strips extra names of their kernels, so 3 or 4
> different releases of the same upstream kernel version all install
> with the same name and report `uname -r` the same. If multiple of
> these kernels and a vanilla kernel are installed, their config
> files will be difficult to distinguish. dpkg can be used (similar
> to above for rpm) to test the condition.
Huh? My Debian system here has:
/boot/config-2.6.15-1-powerpc-smp
This corresponds to the config of the currently installed version and
revision ("2.6.15-8") of the "linux-image-2.6.15-1-powerpc-smp"
package. Since you can only have one version of a given package
installed at once, this poses no problems.
If I upgrade to a new one (say "2.6.15-9") that changes the config
slightly or adds a new distro patch, then that config and kernel
image would replace the currently installed one. If I use make-kpkg
to build and install a custom kernel tuned for "host":
make-kpkg [args] --append-to-version -zeus1-1-powerpc-smp --
revision 1 kernel_image
Now I get a package "linux-image-2.6.15-zeus1-1-powerpc-smp" version
"2.6.15-1", with:
/boot/config-2.6.15-zeus1-1-powerpc-smp
I see no potential for confusion or mismatch here.
Cheers,
Kyle Moffett
Arjan,
On Sat, 27 May 2006, Arjan van de Ven wrote:
>
> > >
> >
> > Redhat and SuSE put /boot/config- files of the same name for different
> > architectures (i386, i586) in the same file. If multiple architecture
> > kernels of the same verion are installed, there is no guarantee that the
> > /boot/config-`uname -r` is not for, say, i686 instead of i386.
>
> at least on fedora you can't do that parallel installation anyway
rpm --force
--brian
--
Brian F. G. Bidulock ? The reasonable man adapts himself to the ?
[email protected] ? world; the unreasonable one persists in ?
http://www.openss7.org/ ? trying to adapt the world to himself. ?
? Therefore all progress depends on the ?
? unreasonable man. -- George Bernard Shaw ?
On Sat, 2006-05-27 at 13:52 -0600, Brian F. G. Bidulock wrote:
> Arjan,
>
> On Sat, 27 May 2006, Arjan van de Ven wrote:
>
> >
> > > >
> > >
> > > Redhat and SuSE put /boot/config- files of the same name for different
> > > architectures (i386, i586) in the same file. If multiple architecture
> > > kernels of the same verion are installed, there is no guarantee that the
> > > /boot/config-`uname -r` is not for, say, i686 instead of i386.
> >
> > at least on fedora you can't do that parallel installation anyway
>
> rpm --force
at which point 95% of the files get overwritten including the config
file, which then points to the right place of the 2nd kernel you abuse
onto your system.
Kyle,
On Sat, 27 May 2006, Kyle Moffett wrote:
> On May 26, 2006, at 11:35:30, Brian F. G. Bidulock wrote:
> > On Fri, 26 May 2006, Arjan van de Ven wrote:
> >> /boot/config-`uname -r`
> >
> > Debian (Woody), OTOH strips extra names of their kernels, so 3 or 4
> > different releases of the same upstream kernel version all install
> > with the same name and report `uname -r` the same. If multiple of
> > these kernels and a vanilla kernel are installed, their config
> > files will be difficult to distinguish. dpkg can be used (similar
> > to above for rpm) to test the condition.
>
> Huh? My Debian system here has:
>
> /boot/config-2.6.15-1-powerpc-smp
>
> This corresponds to the config of the currently installed version and
> revision ("2.6.15-8") of the "linux-image-2.6.15-1-powerpc-smp"
> package. Since you can only have one version of a given package
> installed at once, this poses no problems.
>
> If I upgrade to a new one (say "2.6.15-9") that changes the config
> slightly or adds a new distro patch, then that config and kernel
> image would replace the currently installed one. If I use make-kpkg
> to build and install a custom kernel tuned for "host":
>
> make-kpkg [args] --append-to-version -zeus1-1-powerpc-smp --
> revision 1 kernel_image
>
> Now I get a package "linux-image-2.6.15-zeus1-1-powerpc-smp" version
> "2.6.15-1", with:
>
> /boot/config-2.6.15-zeus1-1-powerpc-smp
>
> I see no potential for confusion or mismatch here.
Woody, ... I said Woody, not Sarge.
2.4 kernel distributions under Woody had this problem.
--brian
--
Brian F. G. Bidulock ? The reasonable man adapts himself to the ?
[email protected] ? world; the unreasonable one persists in ?
http://www.openss7.org/ ? trying to adapt the world to himself. ?
? Therefore all progress depends on the ?
? unreasonable man. -- George Bernard Shaw ?
Arjan,
On Sat, 27 May 2006, Arjan van de Ven wrote:
> On Sat, 2006-05-27 at 13:52 -0600, Brian F. G. Bidulock wrote:
> > Arjan,
> >
> > On Sat, 27 May 2006, Arjan van de Ven wrote:
> >
> > >
> > > > >
> > > >
> > > > Redhat and SuSE put /boot/config- files of the same name for different
> > > > architectures (i386, i586) in the same file. If multiple architecture
> > > > kernels of the same verion are installed, there is no guarantee that the
> > > > /boot/config-`uname -r` is not for, say, i686 instead of i386.
> > >
> > > at least on fedora you can't do that parallel installation anyway
> >
> > rpm --force
>
> at which point 95% of the files get overwritten including the config
> file, which then points to the right place of the 2nd kernel you abuse
> onto your system.
But not the right place for the running kernel. /boot/config-`uname -r` will
be of the wrong architecture for the running kernel.
--brian
--
Brian F. G. Bidulock ? The reasonable man adapts himself to the ?
[email protected] ? world; the unreasonable one persists in ?
http://www.openss7.org/ ? trying to adapt the world to himself. ?
? Therefore all progress depends on the ?
? unreasonable man. -- George Bernard Shaw ?
> But not the right place for the running kernel. /boot/config-`uname -r` will
> be of the wrong architecture for the running kernel.
so yes you can use --force to cause it to overwrite a file. DUH.
Big yawn as will since this file isn't needed for anything but for a
human to build his own kernel; if that human first does the really silly
--force thing (which is a great way to hose your system) then he knows
there might not be an exact match. Big Yawn(tm) :)
Arjan,
On Sun, 28 May 2006, Arjan van de Ven wrote:
>
> > But not the right place for the running kernel. /boot/config-`uname -r` will
> > be of the wrong architecture for the running kernel.
>
> so yes you can use --force to cause it to overwrite a file. DUH.
> Big yawn as will since this file isn't needed for anything but for a
> human to build his own kernel; if that human first does the really silly
> --force thing (which is a great way to hose your system) then he knows
> there might not be an exact match. Big Yawn(tm) :)
>
Well, Mandriva doesn't have even this problem because the architecture is
part of the kernel name.
For others its worth sanity checking
rpm -q --qf "%{ARCH}\n" --what-provides /boot/config-`uname -r`
against
uname -m
to ensure that the architecture matches.
--brian
> > > How does one check the existence of the kernel source RPM (or deb) on
> > > every single distribution?.
> > >
> > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > about debian based distros?. There doesn't seem to be a a single
> > > conherent naming scheme.
> >
> > I'd really like to see a distro-agnostic way to retrieve the kernel
> > configuration. /proc/config.gz has existed for soem time but many
> > distros inexplicably don't enable it.
>
> /boot/config-`uname -r`
What's the reason for distros to disable /proc/config.gz?
On Sun, 2006-05-28 15:03:20 +0200, Heiko Carstens <[email protected]> wrote:
> > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > configuration. /proc/config.gz has existed for soem time but many
> > > distros inexplicably don't enable it.
> >
> > /boot/config-`uname -r`
>
> What's the reason for distros to disable /proc/config.gz?
To save memory? The config can be placed as a plain file, so why
waste non-swappable kernel memory for a task that can easily be done
with a simple file?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
> > > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > > configuration. /proc/config.gz has existed for soem time but many
> > > > distros inexplicably don't enable it.
> > >
> > > /boot/config-`uname -r`
> >
> > What's the reason for distros to disable /proc/config.gz?
>
> To save memory? The config can be placed as a plain file, so why
> waste non-swappable kernel memory for a task that can easily be done
> with a simple file?
As long as you know which of the config files to pick, no problem.
At least for me /proc/config.gz is the much more comfortable way. Anyway,
thanks for clarification!
On Sun, 2006-05-28 at 15:03 +0200, Heiko Carstens wrote:
> > > > How does one check the existence of the kernel source RPM (or deb) on
> > > > every single distribution?.
> > > >
> > > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > > about debian based distros?. There doesn't seem to be a a single
> > > > conherent naming scheme.
> > >
> > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > configuration. /proc/config.gz has existed for soem time but many
> > > distros inexplicably don't enable it.
> >
> > /boot/config-`uname -r`
>
> What's the reason for distros to disable /proc/config.gz?
what would be a reason to ENable it???
it's double functionality that does take memory away...
On Sun, 2006-05-28 at 19:03 +0200, Arjan van de Ven wrote:
> On Sun, 2006-05-28 at 15:03 +0200, Heiko Carstens wrote:
> > > > > How does one check the existence of the kernel source RPM (or deb) on
> > > > > every single distribution?.
> > > > >
> > > > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > > > about debian based distros?. There doesn't seem to be a a single
> > > > > conherent naming scheme.
> > > >
> > > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > > configuration. /proc/config.gz has existed for soem time but many
> > > > distros inexplicably don't enable it.
> > >
> > > /boot/config-`uname -r`
> >
> > What's the reason for distros to disable /proc/config.gz?
>
> what would be a reason to ENable it???
> it's double functionality that does take memory away...
>
It sounds like there is in fact no distro agnostic way to retrieve the
kernel config (the solutions posted involve using rpm for "sanity
checking" etc).
Why was /proc/config.gz merged then? If no distro uses it shouldn't it
be removed?
Lee
On Sun, 2006-05-28 at 13:52 -0400, Lee Revell wrote:
> On Sun, 2006-05-28 at 19:03 +0200, Arjan van de Ven wrote:
> > On Sun, 2006-05-28 at 15:03 +0200, Heiko Carstens wrote:
> > > > > > How does one check the existence of the kernel source RPM (or deb) on
> > > > > > every single distribution?.
> > > > > >
> > > > > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > > > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > > > > about debian based distros?. There doesn't seem to be a a single
> > > > > > conherent naming scheme.
> > > > >
> > > > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > > > configuration. /proc/config.gz has existed for soem time but many
> > > > > distros inexplicably don't enable it.
> > > >
> > > > /boot/config-`uname -r`
> > >
> > > What's the reason for distros to disable /proc/config.gz?
> >
> > what would be a reason to ENable it???
> > it's double functionality that does take memory away...
> >
>
> It sounds like there is in fact no distro agnostic way to retrieve the
> kernel config
/boot/config-`uname -r` goes a long way, and yes I'm ignoring the "but
users CAN clobber the file if they use enough violence against their
packaging system" argument entirely. That's just a bogus one.
Also... why would there really be a need for such a way? Not for
building anything for sure.... it's for the human. And the human seems
to just find it already (and again the boot file works well in practice
it seems)
On Sun, 28 May 2006 20:12:44 +0200 Arjan van de Ven wrote:
> On Sun, 2006-05-28 at 13:52 -0400, Lee Revell wrote:
> > On Sun, 2006-05-28 at 19:03 +0200, Arjan van de Ven wrote:
> > > On Sun, 2006-05-28 at 15:03 +0200, Heiko Carstens wrote:
> > > > > > > How does one check the existence of the kernel source RPM (or deb) on
> > > > > > > every single distribution?.
> > > > > > >
> > > > > > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > > > > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > > > > > about debian based distros?. There doesn't seem to be a a single
> > > > > > > conherent naming scheme.
> > > > > >
> > > > > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > > > > configuration. /proc/config.gz has existed for soem time but many
> > > > > > distros inexplicably don't enable it.
> > > > >
> > > > > /boot/config-`uname -r`
> > > >
> > > > What's the reason for distros to disable /proc/config.gz?
> > >
> > > what would be a reason to ENable it???
> > > it's double functionality that does take memory away...
> > >
> >
> > It sounds like there is in fact no distro agnostic way to retrieve the
> > kernel config
>
> /boot/config-`uname -r` goes a long way, and yes I'm ignoring the "but
> users CAN clobber the file if they use enough violence against their
> packaging system" argument entirely. That's just a bogus one.
>
> Also... why would there really be a need for such a way? Not for
> building anything for sure.... it's for the human. And the human seems
> to just find it already (and again the boot file works well in practice
> it seems)
You may be correct now but a few years ago when /proc/config.gz
was developed, there were lots of distros that did not provide
/boot/config* files.
---
~Randy
On Sun, May 28, 2006 at 08:12:44PM +0200, Arjan van de Ven wrote:
> On Sun, 2006-05-28 at 13:52 -0400, Lee Revell wrote:
> > On Sun, 2006-05-28 at 19:03 +0200, Arjan van de Ven wrote:
> > > On Sun, 2006-05-28 at 15:03 +0200, Heiko Carstens wrote:
> > > > > > > How does one check the existence of the kernel source RPM (or deb) on
> > > > > > > every single distribution?.
> > > > > > >
> > > > > > > We know that rpm -qa | grep kernel-source works on Redhat, Fedora,
> > > > > > > SuSE, Mandrake and CentOS - how about other RPM based distros? How
> > > > > > > about debian based distros?. There doesn't seem to be a a single
> > > > > > > conherent naming scheme.
> > > > > >
> > > > > > I'd really like to see a distro-agnostic way to retrieve the kernel
> > > > > > configuration. /proc/config.gz has existed for soem time but many
> > > > > > distros inexplicably don't enable it.
> > > > >
> > > > > /boot/config-`uname -r`
> > > >
> > > > What's the reason for distros to disable /proc/config.gz?
> > >
> > > what would be a reason to ENable it???
> > > it's double functionality that does take memory away...
> > >
> >
> > It sounds like there is in fact no distro agnostic way to retrieve the
> > kernel config
>
> /boot/config-`uname -r` goes a long way, and yes I'm ignoring the "but
> users CAN clobber the file if they use enough violence against their
> packaging system" argument entirely. That's just a bogus one.
>
> Also... why would there really be a need for such a way? Not for
> building anything for sure.... it's for the human. And the human seems
> to just find it already (and again the boot file works well in practice
> it seems)
Well, /boot/config-`uname -r` would not work right here, as well as on
a number of people's systems that I know, simply because a solution to
avoid the awful mess in /boot is to mkdir /boot/$(uname -r) and put
your System.map, .config and bzImage there (BTW, I also put modules
there since my /lib/modules is a symlink to /boot). This way, there
is only *ONE* rm -rf to do to remove an old unused kernel. So in this
case, it would be /boot/$(uname -r)/.config.
On another subject, I find /proc/config.gz useful when debugging kernels
because this is the only *safe* way to know what was put in a given kernel
that I have booted in the middle of others. However, I agree that this
does not bring much usefulness on distro kernels.
Cheers,
Willy
On Sun, 2006-05-28 at 20:12 +0200, Arjan van de Ven wrote:
> Also... why would there really be a need for such a way? Not for
> building anything for sure.... it's for the human. And the human seems
> to just find it already (and again the boot file works well in practice
> it seems)
>
Debugging. When a new Linux user files a "no sound" ALSA bug report I
need to find out whether they have any known broken options enabled,
like USB bandwidth checking or the OSS USB midi/audio drivers. If we
have to go back and forth figuring out which distro they have and where
the config is they are that much more likely to give up and go back to
Windows.
Lee
On 28/05/06, Arjan van de Ven <[email protected]> wrote:
>
> /boot/config-`uname -r` goes a long way, and yes I'm ignoring the "but
> users CAN clobber the file if they use enough violence against their
> packaging system" argument entirely. That's just a bogus one.
>
You are also ignoring the fact that not all distros store configs
there (and/or under that name).
> Also... why would there really be a need for such a way? Not for
> building anything for sure.... it's for the human. And the human seems
> to just find it already (and again the boot file works well in practice
> it seems)
>
My personal favorite is /proc/config.gz . It has the very nice
property that even if I misplace my config file (or rebuild my tree
several times with different configs and don't save the one for my
running kernel) then I can always get the config for any of the
kernels I have installed, simply by booting it (or extracting it from
the kernel image).
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Sun, 2006-05-28 15:55:29 -0400, Lee Revell <[email protected]> wrote:
> On Sun, 2006-05-28 at 20:12 +0200, Arjan van de Ven wrote:
> > Also... why would there really be a need for such a way? Not for
> > building anything for sure.... it's for the human. And the human seems
> > to just find it already (and again the boot file works well in practice
> > it seems)
>
> Debugging. When a new Linux user files a "no sound" ALSA bug report I
> need to find out whether they have any known broken options enabled,
> like USB bandwidth checking or the OSS USB midi/audio drivers. If we
> have to go back and forth figuring out which distro they have and where
> the config is they are that much more likely to give up and go back to
> Windows.
...which isn't always the worst solution to the problem. If some guy
doesn't want to jump through the loops to figure out what's actually
broken, Windows may be a good solution for them. "World domination"
also means "dominated by the world's problems," so I tend to go a step
back from time to time:-)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Sun, 2006-05-28 at 22:45 +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-05-28 15:55:29 -0400, Lee Revell <[email protected]> wrote:
> > On Sun, 2006-05-28 at 20:12 +0200, Arjan van de Ven wrote:
> > > Also... why would there really be a need for such a way? Not for
> > > building anything for sure.... it's for the human. And the human seems
> > > to just find it already (and again the boot file works well in practice
> > > it seems)
> >
> > Debugging. When a new Linux user files a "no sound" ALSA bug report I
> > need to find out whether they have any known broken options enabled,
> > like USB bandwidth checking or the OSS USB midi/audio drivers. If we
> > have to go back and forth figuring out which distro they have and where
> > the config is they are that much more likely to give up and go back to
> > Windows.
>
> ...which isn't always the worst solution to the problem. If some guy
> doesn't want to jump through the loops to figure out what's actually
> broken, Windows may be a good solution for them. "World domination"
> also means "dominated by the world's problems," so I tend to go a step
> back from time to time:-)
Yes, if it were a perfect world and we had access to all the hardware
specs like Microsoft does, we would not need these users' help. But the
users have access to a lot more hardware than the developers do and
trial and error is often the only solution.
If they give up and go back to Windows we may never support their
hardware correctly.
Lee
On Sun, 2006-05-28 17:27:39 -0400, Lee Revell <[email protected]> wrote:
> On Sun, 2006-05-28 at 22:45 +0200, Jan-Benedict Glaw wrote:
> > ...which isn't always the worst solution to the problem. If some guy
> > doesn't want to jump through the loops to figure out what's actually
> > broken, Windows may be a good solution for them. "World domination"
> > also means "dominated by the world's problems," so I tend to go a step
> > back from time to time:-)
>
> Yes, if it were a perfect world and we had access to all the hardware
> specs like Microsoft does, we would not need these users' help. But the
> users have access to a lot more hardware than the developers do and
> trial and error is often the only solution.
But this isn't a perfect world.
> If they give up and go back to Windows we may never support their
> hardware correctly.
No user for that given hardware, then there's no sense in supporting
it. If there's a user that *really* wants that hardware supported,
then they will put effort into getting it to work, either by helping
debugging, hacking or by paying some expert to reverse-engineer an
existing driver.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Sun, 2006-05-28 at 23:55 +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-05-28 17:27:39 -0400, Lee Revell <[email protected]> wrote:
> > On Sun, 2006-05-28 at 22:45 +0200, Jan-Benedict Glaw wrote:
> > > ...which isn't always the worst solution to the problem. If some guy
> > > doesn't want to jump through the loops to figure out what's actually
> > > broken, Windows may be a good solution for them. "World domination"
> > > also means "dominated by the world's problems," so I tend to go a step
> > > back from time to time:-)
> >
> > Yes, if it were a perfect world and we had access to all the hardware
> > specs like Microsoft does, we would not need these users' help. But the
> > users have access to a lot more hardware than the developers do and
> > trial and error is often the only solution.
>
> But this isn't a perfect world.
>
Uhmmm... that was my point. Please re-read my post.
> > If they give up and go back to Windows we may never support their
> > hardware correctly.
>
> No user for that given hardware, then there's no sense in supporting
> it.
Chicken and egg problem. Users have hardware and they want to run Linux
on it. It's not always feasible for them to verify Linux compatibility
before they buy. And some vendors like BenQ even ship a Linux CD with
their laptops even though the sound doesn't work on any BenQ system -
they obviously did not even try it. So we have a large population of
users who would love to run Linux but can't until we support their
hardware.
> If there's a user that *really* wants that hardware supported,
> then they will put effort into getting it to work, either by helping
> debugging, hacking or by paying some expert to reverse-engineer an
> existing driver.
There are many users who *really* want their hardware supported but
don't have the funds or the know-how to do any of these. Like all of
these users:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1134
Lee
On Sun, 2006-05-28 18:02:53 -0400, Lee Revell <[email protected]> wrote:
> On Sun, 2006-05-28 at 23:55 +0200, Jan-Benedict Glaw wrote:
> Chicken and egg problem. Users have hardware and they want to run Linux
> on it. It's not always feasible for them to verify Linux compatibility
> before they buy. And some vendors like BenQ even ship a Linux CD with
> their laptops even though the sound doesn't work on any BenQ system -
> they obviously did not even try it. So we have a large population of
> users who would love to run Linux but can't until we support their
> hardware.
In my world, "we" also contains the user. If a user doesn't want to
eg. re-test with upstream kernels or consider to put other efforts
(like paying developers or learning to code), then re doesn't *really*
want it supported.
> > If there's a user that *really* wants that hardware supported,
> > then they will put effort into getting it to work, either by helping
> > debugging, hacking or by paying some expert to reverse-engineer an
> > existing driver.
>
> There are many users who *really* want their hardware supported but
> don't have the funds or the know-how to do any of these. Like all of
> these users:
>
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1134
I accept the no-money argument, but not the no-knowledge one. Anybody
can learn, can't they?
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Lee,
On Sun, 28 May 2006, Lee Revell wrote:
>
> Debugging. When a new Linux user files a "no sound" ALSA bug report I
> need to find out whether they have any known broken options enabled,
> like USB bandwidth checking or the OSS USB midi/audio drivers. If we
> have to go back and forth figuring out which distro they have and where
> the config is they are that much more likely to give up and go back to
> Windows.
>
Bug reports is another advantage that I found with the autoconf
approach to building kernel modules (previous cited): automatic
generation of bug reports containing full configuration information
using a send-pr script generated by the 'configure' script.
--brian
On Sun, 2006-05-28 at 22:44 -0600, Brian F. G. Bidulock wrote:
> Lee,
>
> On Sun, 28 May 2006, Lee Revell wrote:
>
> >
> > Debugging. When a new Linux user files a "no sound" ALSA bug report I
> > need to find out whether they have any known broken options enabled,
> > like USB bandwidth checking or the OSS USB midi/audio drivers. If we
> > have to go back and forth figuring out which distro they have and where
> > the config is they are that much more likely to give up and go back to
> > Windows.
> >
>
> Bug reports is another advantage that I found with the autoconf
> approach to building kernel modules (previous cited): automatic
> generation of bug reports containing full configuration information
> using a send-pr script generated by the 'configure' script.
autoconf compiles stuff. In that case you can just use the config.h file
and test the appropriate defines for the exact case you're compiling the
module for. That HAS to be more reliable than grepping some .config
file...
BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I think
distros shouldn't be given an option to turn it off if its a good thing to have.
Are there any good reasons why REGPARM is turned off?.
------------------
Yet one more reason to have something like kernel-config (similar to gtk-config
or xmms-config) where you can get the package's cflags, ldflags, other info.
for example
kernel-config --cflags should say -DUSE_REGPARM -I/lib/modules/blah/blah
kernel-config --libdir should say where the lib/modules/blah/blah
kernel-config --srcdir should say where the kernel sources are installed or not
installed.
kernel-config --configsrc should configure the kernel source with the running
kernel's configuration.
kernel-config --installsrc should automatically download the RIGHT source from
the net. Right now if you go on Ubuntu or Mandrake and you try to install kernel
source - you get the option of stripped source, kernel-headers, kernel-2.6.blah
which may not be installed.
Any comments?
best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
From: 4Front Technologies <[email protected]>
Date: Sun, 28 May 2006 22:35:56 -0700
> BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I
> think distros shouldn't be given an option to turn it off if its a
> good thing to have. Are there any good reasons why REGPARM is
> turned off?.
Each distribution has different demands and timing regarding the
relase of their compiler relative to the release of the kernel source
they decide to use.
It may have been prudent to fix a REGPARM miscompilation of the kernel
by just disabling it for their release.
On Sun, 28 May 2006 22:35:56 PDT, 4Front Technologies said:
> Yet one more reason to have something like kernel-config (similar to gtk-config
> or xmms-config) where you can get the package's cflags, ldflags, other info.
>
> for example
>
> kernel-config --cflags should say -DUSE_REGPARM -I/lib/modules/blah/blah
The problem is that there's *hundreds* of *lines* of config data, rather than
just the half-dozen or so entries that the average pkgconfig produces, and some
of the config lines influence the actual compile parameters and some don't.
I happen to have a kernel build going - here's what the compile lines looks:
25616 pts/2 S+ 0:00 /bin/sh -c set -e; ? echo ' CC net/ipv4/udp.o'; gcc -m32 -Wp,-MD,net/ipv4/.udp.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Wcomment -Wendif-labels -Wshadow -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -ffreestanding -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(udp)" -D"KBUILD_MODNAME=KBUILD_STR(udp)" -c -o net/ipv4/udp.o net/ipv4/udp.c; scripts/basic/fixdep net/ipv4/.udp.o.d net/ipv4/udp.o 'gcc -m32 -Wp,-MD,net/ipv4/.udp.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -W!
strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Wcomment -Wendif-labels -Wshadow -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -ffreestanding -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=\#s" -D"KBUILD_BASENAME=KBUILD_STR(udp)" -D"KBUILD_MODNAME=KBUILD_STR(udp)" -c -o net/ipv4/udp.o net/ipv4/udp.c' > net/ipv4/.udp.o.tmp; rm -f net/ipv4/.udp.o.d; mv -f net/ipv4/.udp.o.tmp net/ipv4/.udp.o.cmd
25617 pts/2 S+ 0:00 gcc -m32 -Wp,-MD,net/ipv4/.udp.o.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Wcomment -Wendif-labels -Wshadow -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -ffreestanding -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(udp) -DKBUILD_MODNAME=KBUILD_STR(udp) -c -o net/ipv4/udp.o net/ipv4/udp.c
25618 pts/2 R+ 0:01 /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -quiet -nostdinc -Iinclude -Iinclude/asm-i386/mach-default -D__KERNEL__ -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(udp) -DKBUILD_MODNAME=KBUILD_STR(udp) -isystem /usr/lib/gcc/i386-redhat-linux/4.1.1/include -include include/linux/autoconf.h -MD net/ipv4/.udp.o.d net/ipv4/udp.c -quiet -dumpbase udp.c -m32 -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -mregparm=3 -auxbase-strip net/ipv4/udp.o -Os -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Wcomment -Wendif-labels -Wshadow -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-aliasing -fno-common -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -ffreestanding -o -
The reason we have the whole kbuild thing than pkgconfig is because it's
a bit more complicated to build than what pkgconfig can easily express (for
instance, the exact parameters are different for module versus built-in,
and on some architectures it may even matter if a module is under fs/ or
drivers/, and so on....)
On Sun, 2006-05-28 at 22:35 -0700, 4Front Technologies wrote:
> BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I think
> distros shouldn't be given an option to turn it off if its a good thing to have.
why not? It's not like it's a dramatic change of API after all... (and
even if it were...)
external modules shouldn't care, they really really should inherit the
cflags from the kernel's makefiles at which point.. the thing is moot.
On Sun, May 28, 2006 at 10:35:56PM -0700, 4Front Technologies wrote:
> BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I think
> distros shouldn't be given an option to turn it off if its a good thing
> to have.
>
> Are there any good reasons why REGPARM is turned off?.
>
> ------------------
>
>
> Yet one more reason to have something like kernel-config (similar to
> gtk-config or xmms-config) where you can get the package's cflags,
> ldflags, other info.
>
> for example
>
> kernel-config --cflags should say -DUSE_REGPARM -I/lib/modules/blah/blah
>
> kernel-config --libdir should say where the lib/modules/blah/blah
>
> kernel-config --srcdir should say where the kernel sources are installed
> or not installed.
>
> kernel-config --configsrc should configure the kernel source with the
> running
> kernel's configuration.
>
> kernel-config --installsrc should automatically download the RIGHT source
> from the net. Right now if you go on Ubuntu or Mandrake and you try to
> install kernel source - you get the option of stripped source,
> kernel-headers, kernel-2.6.blah which may not be installed.
>
> Any comments?
This is a wrong thing to do IMHO, because it is incompatible with
cross-compilation, and the more the projects will use this method,
the more a nightmare it will become for distro maintainers. At
least when you rely on either a config file or something like this,
it's always possible to make it point to your target system's. But
when you *execute* commands on the build system, chances are that
you will not get the expected result. pcre-config, glib-config and
such are already in this case.
> best regards
> Dev Mazumdar
> -----------------------------------------------------------
> 4Front Technologies
> 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
> Tel: (310) 202 8530 URL: http://www.opensound.com
> Fax: (310) 202 0496 Email: [email protected]
> -----------------------------------------------------------
Regards,
Willy
Arjan,
On Mon, 29 May 2006, Arjan van de Ven wrote:
> external modules shouldn't care, they really really should inherit the
> cflags from the kernel's makefiles at which point.. the thing is moot.
Yes, and ultimately the kernel's makefile (if present) are the best
place to get CFLAGS from. However, the task of ensuring that the
correct Makefile is present and that the correct configuration
information is feeding it (back to .config) is distribution specific
and not always straightforward.
--brian
On Mon, 2006-05-29 at 00:57 -0600, Brian F. G. Bidulock wrote:
> Arjan,
>
> On Mon, 29 May 2006, Arjan van de Ven wrote:
> > external modules shouldn't care, they really really should inherit the
> > cflags from the kernel's makefiles at which point.. the thing is moot.
>
> Yes, and ultimately the kernel's makefile (if present) are the best
> place to get CFLAGS from. However, the task of ensuring that the
> correct Makefile is present and that the correct configuration
> information is feeding it (back to .config) is distribution specific
> and not always straightforward.
eh dude what are you thinking? Documentation/kbuild very much gives you
a FULLY standardized way of doing this. On all distributions.
The only tricky part is finding the build tree, for the current kernel
that is
/lib/modules/`uname -r`/build
(as per Linus' decree from like 4 to 5 years ago)
for non-current kernels that's a bit more complex, so just ask the user.
Once you have that the rest comes for free.
Brian F. G. Bidulock wrote:
> Arjan,
>
> On Mon, 29 May 2006, Arjan van de Ven wrote:
>> external modules shouldn't care, they really really should inherit the
>> cflags from the kernel's makefiles at which point.. the thing is moot.
>
> Yes, and ultimately the kernel's makefile (if present) are the best
> place to get CFLAGS from. However, the task of ensuring that the
> correct Makefile is present and that the correct configuration
> information is feeding it (back to .config) is distribution specific
> and not always straightforward.
>
> --brian
>
>
How about external modules that have a kernel dependant part and kernel
independant part?. Kernel independant part could live in a separate tree and
has its own makefiles.
But regparm requires that ALL parts linked into the module need to have regparm
defined. So it's another headache to write makefiles for the kernel independant
part to figure out if the distro support regparm or not.
regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530 URL: http://www.opensound.com
Fax: (310) 202 0496 Email: [email protected]
-----------------------------------------------------------
4Front,
On Mon, 29 May 2006, 4Front Technologies wrote:
>
> How about external modules that have a kernel dependant part and kernel
> independant part?. Kernel independant part could live in a separate tree and
> has its own makefiles.
>
> But regparm requires that ALL parts linked into the module need to have
> regparm defined. So it's another headache to write makefiles for the kernel
> independant part to figure out if the distro support regparm or not.
They way I approached it was to get CFLAGS for compiling both the kernel
dependent part and kernel independent part.
The interface exported from the kernel dependent part to the indepdent part
have the regparms attribute explicity pinned on exported symbols (e.g. on
supporting architectures either to __attribute__((__regparm__(3))) or
__attribute__((__regparm(0)))). LiS uses regparm(0) for binary compatible
(kernel independent) STREAMS modules for historical reasons. Linux
Fast-STREAMS uses regparm(3).
Taking a similar approach, make all your kernel dependent part exported
function (and function pointer) symbols "fastcall" and then forget about the
compiler flag. If you access regular kernel symbols, you, of course, do not
have this choice.
It would have been nice if the kernel would set the regparms on all exported
symbols, but external modules was really just an afterthought.
The autoconf approach that I take does not use kbuild, primarily because of
the inherent separation between kernel depedent part and independent part
for STREAMS (STREAMS subsystem is kernel dependent, STREAMS modules attempt
to be somewhat kernel independent and use an SVR4.2 ABI).
The autoconf/automake makefiles handle the building of both. And, of course,
they nicely handle building all the othter GNU/Linux things like user space
programs built on the same definitions, manual pages, etc.
--brian
Arjan,
On Mon, 29 May 2006, Arjan van de Ven wrote:
> eh dude what are you thinking? Documentation/kbuild very much gives you
> a FULLY standardized way of doing this. On all distributions.
> The only tricky part is finding the build tree, for the current kernel
> that is
> /lib/modules/`uname -r`/build
> (as per Linus' decree from like 4 to 5 years ago)
> for non-current kernels that's a bit more complex, so just ask the user.
> Once you have that the rest comes for free.
kbuild is fine for small isolated kernel modules that export no symbols
(esp. little ones that nobody supports any more or were recently kicked
out of a kernel), but for building large subsystems of kernel modules
and multiple interdependent packages that export symbols and headers it
is rather lacking.
An, of course, if you want to build kernel modules for 2.4 and 2.6 as
well, kbuild does not help you.
Also, while checking for kernel version on the fine kernel.org kernels
is quite sufficient, it is next to useless on hacked production distro
kernels. Therefore, one has to locate configured sources and headers
to perform checks to adapt to them.
--brian
On Mon, 29 May 2006 00:05:12 PDT, 4Front Technologies said:
> But regparm requires that ALL parts linked into the module need to have regparm
> defined. So it's another headache to write makefiles for the kernel independant
> part to figure out if the distro support regparm or not.
Not true at all.. Or at least not for the most infamous module out there:
% grep NV_API_CALL *.h | head
nv.h:#if !defined(NV_API_CALL)
nv.h:#define NV_API_CALL __attribute__((regparm(0)))
nv.h:#define NV_API_CALL
nv.h:void* NV_API_CALL nv_dma_to_mmap_token (nv_state_t *, NvU64);
nv.h:void* NV_API_CALL nv_alloc_kernel_mapping (nv_state_t *, NvU64, U032, void **);
nv.h:S032 NV_API_CALL nv_free_kernel_mapping (nv_state_t *, void *, void *);
nv.h:NvU64 NV_API_CALL nv_get_kern_phys_address (NvU64);
nv.h:NvU64 NV_API_CALL nv_get_user_phys_address (NvU64);
nv.h:void* NV_API_CALL nv_get_adapter_state (U016, U016);
nv.h:void NV_API_CALL nv_lock_rm (nv_state_t *);
So there's routines facing the rest of the kernel - those *do* need to have a
regparm that matches the kernel. But internal to the module, you can have some
other regparm value - the requirement is only that the prototype needs to have
the same regparm as the function body is actually compiled with.
I seem to remember that parts of the *mainline* kernel use 'asmlinkage'
for similar reasons.... ;)
On Mon, 2006-05-29 at 00:38 +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-05-28 18:02:53 -0400, Lee Revell <[email protected]> wrote:
> > On Sun, 2006-05-28 at 23:55 +0200, Jan-Benedict Glaw wrote:
> > Chicken and egg problem. Users have hardware and they want to run Linux
> > on it. It's not always feasible for them to verify Linux compatibility
> > before they buy. And some vendors like BenQ even ship a Linux CD with
> > their laptops even though the sound doesn't work on any BenQ system -
> > they obviously did not even try it. So we have a large population of
> > users who would love to run Linux but can't until we support their
> > hardware.
>
> In my world, "we" also contains the user. If a user doesn't want to
> eg. re-test with upstream kernels or consider to put other efforts
> (like paying developers or learning to code), then re doesn't *really*
> want it supported.
I guess your argument is the old "Linux is user friendly, it's just
picky about its users". Today, I don't buy it. Linux is becoming much
more user friendly, more so with non developers. I'm starting to see
that if I want to keep being paid for kernel development, more and more
non-developer users are needed to exist.
Yes, there are several non-developers that are great and bend over
backwards to help us solve problems (Mark Knetch, a guitar player,
constantly does this to help us on -rt). But they are few and far
between. Some are just too intimidated by what goes on in their
computer, and might give up and say: "this Linux stuff is just too hard,
and is not worth it" before they realize it would be.
Basically, anything that makes it easier for users to help us solve bugs
in hardware is important. If I know there's a bug on something that I
don't own, I would want it fixed with the help of the first user that
discovers it, than saying "oh well, he gave up, I'll just wait for the
next one". That would drive me crazy.
>
> > > If there's a user that *really* wants that hardware supported,
> > > then they will put effort into getting it to work, either by helping
> > > debugging, hacking or by paying some expert to reverse-engineer an
> > > existing driver.
> >
> > There are many users who *really* want their hardware supported but
> > don't have the funds or the know-how to do any of these. Like all of
> > these users:
> >
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1134
>
> I accept the no-money argument, but not the no-knowledge one. Anybody
> can learn, can't they?
I know people who call themselves programmers that still don't "get it".
So, really, the answer is "No", people can't always learn, and a lot
don't want to. Programming and debugging is a talent. No matter how
hard I try to sing, I still wont be good enough to survive living in a
subway.
-- Steve
On Mon, 2006-05-29 at 00:05 -0700, 4Front Technologies wrote:
> Brian F. G. Bidulock wrote:
> > Arjan,
> >
> > On Mon, 29 May 2006, Arjan van de Ven wrote:
> >> external modules shouldn't care, they really really should inherit the
> >> cflags from the kernel's makefiles at which point.. the thing is moot.
> >
> > Yes, and ultimately the kernel's makefile (if present) are the best
> > place to get CFLAGS from. However, the task of ensuring that the
> > correct Makefile is present and that the correct configuration
> > information is feeding it (back to .config) is distribution specific
> > and not always straightforward.
> >
> > --brian
> >
> >
>
>
> How about external modules that have a kernel dependant part and kernel
> independant part?.
tough luck :)
> Kernel independant part could live in a separate tree and
> has its own makefiles.
as long as those makefiles inherit the proper CFLAGs it's no big deal.
If not then you need to glue them together properly, but thankfully the
GPL gives you the freedom to tinker with the sources you get so you can
do that.
> But regparm requires that ALL parts linked into the module need to have regparm
> defined. So it's another headache to write makefiles for the kernel independant
> part to figure out if the distro support regparm or not.
just inherit the cflags. You need to have matching cflags and compiler
anyway for many other reasons; this one is no exception.
On Mon, 2006-05-29 at 08:11 -0400, Steven Rostedt wrote:
> I guess your argument is the old "Linux is user friendly, it's just
> picky about its users".
Damn, I can't even get the saying right! That was suppose to be:
"Linux is user friendly, it's just picky about its _friends_".
I guess I'll go have my first cup of coffee today.
-- Steve
Arjan van de Ven wrote:
> On Sun, 2006-05-28 at 22:35 -0700, 4Front Technologies wrote:
>
>>BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I think
>>distros shouldn't be given an option to turn it off if its a good thing to have.
> why not? It's not like it's a dramatic change of API after all... (and
> even if it were...)
>
> external modules shouldn't care, they really really should inherit the
> cflags from the kernel's makefiles at which point.. the thing is moot.
Speaking from personal experience...there are a LOT of 3rd party drivers
out there that do not build their modules properly. It gets especially
interesting when they want to have a single package support 2.4 and 2.6,
and also link the result against an included binary blob.
Chris
On Mon, 2006-05-29 at 09:52 -0600, Christopher Friesen wrote:
> Arjan van de Ven wrote:
> > On Sun, 2006-05-28 at 22:35 -0700, 4Front Technologies wrote:
> >
> >>BTW, why is Mandriva the only distro to turn OFF REGPARM?. Again, I think
> >>distros shouldn't be given an option to turn it off if its a good thing to have.
>
> > why not? It's not like it's a dramatic change of API after all... (and
> > even if it were...)
> >
> > external modules shouldn't care, they really really should inherit the
> > cflags from the kernel's makefiles at which point.. the thing is moot.
>
> Speaking from personal experience...there are a LOT of 3rd party drivers
> out there that do not build their modules properly.
yup there are. sad but true ;(
> It gets especially
> interesting when they want to have a single package support 2.4 and 2.6,
> and also link the result against an included binary blob.
well if a binary blob is involved you've lost already in many ways.