16 Feb
2009
16 Feb
'09
5:19 p.m.
lwn.net has a very interesting interview with thomas gleixner and ingo
molnar about the future of the realtime preeemption tree.
this is a free link to content that is normally subscribers only:
http://lwn.net/SubscriberLink/319544/7cdf603c88f8dbd0/
i hope it's ok to post such a link in a public place.
the whole lwn issue will become freely available in a week or so. lwn is
a great resource and interesting reading, and if you've got a few
dollars to spare, consider subscribing to keep them going.
best,
jörn
16 Feb
16 Feb
5:30 p.m.
Thanks for being so on top of this Jörn .
I had checked LWN a couple of hours ago and am busy with too many other things to check
back there till this evening.
It's nice to have these extra resources when I'm busy, and I also encourage
people to subscriber to LWN!
I'll try to read it soon.
26 Feb
26 Feb
10:24 a.m.
hi everyone!
Jörn Nettingsmeier wrote:
lwn.net has a very interesting interview with thomas
gleixner and ingo
molnar about the future of the realtime preeemption tree.
this is a free link to content that is normally subscribers only:
http://lwn.net/SubscriberLink/319544/7cdf603c88f8dbd0/
i hope it's ok to post such a link in a public place.
the whole lwn issue will become freely available in a week or so. lwn is
a great resource and interesting reading, and if you've got a few
dollars to spare, consider subscribing to keep them going.
just fyi, 2.6.29-rc6-rt2 is out.
the release announcement is here: http://lwn.net/Articles/320348/
for those who haven't seen it, the rt wiki is a great resource:
http://rt.wiki.kernel.org/index.php/Main_Page
let's all jump on this and give it a good beating, to prevent a future
rt hiatus like the one we've just had...
greetings,
jörn
11:48 a.m.
Regarding building kernels ...
The number of drivers is ever increasing, which is probably a good
thing. The downside is that it takes forever to compile it all, and at
the end of the day, any one of us only needs a fraction for the target
machine.
Is there a neat around trick that takes something like lsmod (from a
working machine) as input and produces a config based on that?
/j
On Thu, 2009-02-26 at 15:24 +0100, Jörn Nettingsmeier wrote:
hi everyone!
Jörn Nettingsmeier wrote:
lwn.net has a very interesting interview with
thomas gleixner and ingo
molnar about the future of the realtime preeemption tree.
this is a free link to content that is normally subscribers only:
http://lwn.net/SubscriberLink/319544/7cdf603c88f8dbd0/
i hope it's ok to post such a link in a public place.
the whole lwn issue will become freely available in a week or so. lwn is
a great resource and interesting reading, and if you've got a few
dollars to spare, consider subscribing to keep them going.
just fyi, 2.6.29-rc6-rt2 is out.
the release announcement is here: http://lwn.net/Articles/320348/
for those who haven't seen it, the rt wiki is a great resource:
http://rt.wiki.kernel.org/index.php/Main_Page
let's all jump on this and give it a good beating, to prevent a future
rt hiatus like the one we've just had...
greetings,
jörn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev 
12:17 p.m.
Is there a neat around trick that takes something like
lsmod (from a
working machine) as input and produces a config based on that?
There is a procedure outlined in chapter 7 of LKN, but I am not sure
about how scriptable it is.
http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch07.pdf
It would certainly be a neat thing.
L
12:58 p.m.
Luis Garrido wrote:
First, identify the kernel .config to be migrated to the new kernel, and get
it into the new kernel source directory as '.config'.
Eg ...
zcat /proc/config.gz > .config or
cp /boot/config-2.6.28-xyz .config or
cp ~/my_brave_rt/2.6.28-rt11.config.good .config
Run 'make oldconfig'. That will stop when it encounters a new option that needs
an answer, so it's scriptable but not entirely automatic.
Then build && install new kernel.
cheers, Cal
Is there a
neat around trick that takes something like lsmod (from a
working machine) as input and produces a config based on that?
There is a procedure outlined in chapter 7 of LKN, but I am not sure
about how scriptable it is.
http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch07.pdf
It would certainly be a neat thing.
1:46 p.m.
Run 'make oldconfig'. That will stop when it
encounters a new option that
Certainly, but that assumes that you have already done the job of
pruning the kernel tree to the needs of your machine, so you don't
have to build the whole behemoth.
I think Jens was hinting at automating that step too, making use of
the module detection facilities of a running stock kernel.
L
2:27 p.m.
On Thu, Feb 26, 2009 at 12:46 PM, Luis Garrido <
luisgarrido(a)users.sourceforge.net> wrote:
the output of lshal could conceivably be rather useful for this.
Run 'make
oldconfig'. That will stop when it encounters a new option that
Certainly, but that assumes that you have already done the job of
pruning the kernel tree to the needs of your machine, so you don't
have to build the whole behemoth.
I think Jens was hinting at automating that step too, making use of
the module detection facilities of a running stock kernel. 
27 Feb
27 Feb
3:32 a.m.
On Thu, 26 Feb 2009 18:46:32 +0100, Luis Garrido
<luisgarrido(a)users.sourceforge.net> wrote:
> Run 'make oldconfig'. That will stop when
it encounters a new option
that
Certainly, but that assumes that you have already done the job of
pruning the kernel tree to the needs of your machine, so you don't
have to build the whole behemoth.
I think Jens was hinting at automating that step too, making use of
the module detection facilities of a running stock kernel.
I do not know about automating it, but doing it by hand is certainly good
for one's culture, and you only have to do it once since you can migrate
you .config file from one tree to a new one.
I've been using the same config file for years. Eventually, I sometimes
have to take a look at new options/drivers to add (or remove).
-- Marc-Olivier Barre --
--- MarcO'Chapeau ----
- www.marcochapeau.org -
5:04 a.m.
Allrighty then, by hand is the way to go. With 50+ modules loaded on the
running machine, that should take no more than a week to identify what
they are, what they do (if anything?) and correct possible mistakes ...
Or just leave it the way it is and do the laundry, take a nap, visit
friends and watch some television :-D
/j
On Fri, 2009-02-27 at 08:32 +0100, MarcO'Chapeau wrote:
On Thu, 26 Feb 2009 18:46:32 +0100, Luis Garrido
<luisgarrido(a)users.sourceforge.net> wrote:
> Run 'make oldconfig'. That will stop
when it encounters a new option
that
Certainly, but that assumes that you have already done the job of
pruning the kernel tree to the needs of your machine, so you don't
have to build the whole behemoth.
I think Jens was hinting at automating that step too, making use of
the module detection facilities of a running stock kernel.
I do not know about automating it, but doing it by hand is certainly good
for one's culture, and you only have to do it once since you can migrate
you .config file from one tree to a new one.
I've been using the same config file for years. Eventually, I sometimes
have to take a look at new options/drivers to add (or remove).
-- Marc-Olivier Barre --
--- MarcO'Chapeau ----
- www.marcochapeau.org -
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev 
9:12 a.m.
An interesting/important question though is how many of these 50+
modules actually contains hw specific adaptions. As an example, for
audio apps you typically rely on a number of sound ("snd-*") related
modules of which a fair amount is hardware independent. It is only the
modules that implement hardware specific adaptions that needs to go
through the "tedious" identification process.
I guess that the BIOS will leave most hardware components in a state
where they do not generate "interrupts" unless some kernel or userland
code explicitly turns this on. If this is true you should probably be
able to have a working system with a minimum set of modules. Anyone
that have some experience in creating a system with a minimum set of
hardware adaption modules? If so, what are the minimum set of hardware
adaption modules required?
/Lars
2009/2/27 Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
Allrighty then, by hand is the way to go. With 50+
modules loaded on the
running machine, that should take no more than a week to identify what
they are, what they do (if anything?) and correct possible mistakes ...
Or just leave it the way it is and do the laundry, take a nap, visit
friends and watch some television :-D
/j
On Fri, 2009-02-27 at 08:32 +0100, MarcO'Chapeau wrote:
On Thu, 26 Feb 2009 18:46:32 +0100, Luis Garrido
<luisgarrido(a)users.sourceforge.net> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> Run 'make oldconfig'. That will stop
when it encounters a new option
that
Certainly, but that assumes that you have already done the job of
pruning the kernel tree to the needs of your machine, so you don't
have to build the whole behemoth.
I think Jens was hinting at automating that step too, making use of
the module detection facilities of a running stock kernel.
I do not know about automating it, but doing it by hand is certainly good
for one's culture, and you only have to do it once since you can migrate
you .config file from one tree to a new one.
I've been using the same config file for years. Eventually, I sometimes
have to take a look at new options/drivers to add (or remove).
-- Marc-Olivier Barre --
--- MarcO'Chapeau ----
- www.marcochapeau.org -
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev 
11:24 a.m.
Lars-Erik Helander wrote:
An interesting/important question though is how many
of these 50+
modules actually contains hw specific adaptions. As an example, for
audio apps you typically rely on a number of sound ("snd-*") related
modules of which a fair amount is hardware independent. It is only the
modules that implement hardware specific adaptions that needs to go
through the "tedious" identification process.
I guess that the BIOS will leave most hardware components in a state
where they do not generate "interrupts" unless some kernel or userland
code explicitly turns this on. If this is true you should probably be
able to have a working system with a minimum set of modules. Anyone
that have some experience in creating a system with a minimum set of
hardware adaption modules? If so, what are the minimum set of hardware
adaption modules required?
/Lars
Always ALWAYS make sure you have your hard disk and root file system.
(This may seem obvious but going from a distribution's .config to a
hand-rolled kernel with make oldconfig can backfire if you don't also
make an initrd.)
Keyboard and Video also come to mind. Once you have that, you can
recover from a forgotten module by recompiling and rebooting. Obviously
a known-good kernel is good too.
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
12:04 p.m.
On Fri, 2009-02-27 at 08:24 -0700, Hans Fugal wrote:
Lars-Erik Helander wrote:
> An interesting/important question though is how many of these 50+
> modules actually contains hw specific adaptions. As an example, for
> audio apps you typically rely on a number of sound ("snd-*") related
> modules of which a fair amount is hardware independent. It is only the
> modules that implement hardware specific adaptions that needs to go
> through the "tedious" identification process.
>
Mmm ... No. Even those modules that I don't know what is has to be
compiled for init (as defined now) eventually to work without errors.
Getting up to init level 2 or 3 is one thing, but then there is no
obvious mapping between the names of "modules not found" and what driver
options should be enabled to get things back to normal.
BTW: I have some 1600 files in modules/drivers! :-D
12:38 p.m.
To be more specific I know that you still have to compile these
modules, unless you decide to make them part of the kernel. If you
build an RT kernel to be used for audio there is really no reason (or
?) why you should make modules of things like snd-seq, snd-pcm, etc,
i.e. "modules" not depending on specific hardware, just make them part
of the kernel.
The tedious process is to find out what hardware dependent modules to
use, in order to make them part of the "solution". The non-hardware
dependent modules to include should be determined once, and when first
entered into the config you should be done :)
With a scheme like this the process to adapt to different target
hardwares would be smoother.
I have not tried this scheme. but think I might do that some time
/Lars
2009/2/27 Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
On Fri, 2009-02-27 at 08:24 -0700, Hans Fugal wrote:
Lars-Erik Helander wrote:
> An interesting/important question though is how many of these 50+
> modules actually contains hw specific adaptions. As an example, for
> audio apps you typically rely on a number of sound ("snd-*") related
> modules of which a fair amount is hardware independent. It is only the
> modules that implement hardware specific adaptions that needs to go
> through the "tedious" identification process.
>
Mmm ... No. Even those modules that I don't know what is has to be
compiled for init (as defined now) eventually to work without errors.
Getting up to init level 2 or 3 is one thing, but then there is no
obvious mapping between the names of "modules not found" and what driver
options should be enabled to get things back to normal.
BTW: I have some 1600 files in modules/drivers! :-D
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
2 Mar
2 Mar
6:09 p.m.
On Fri, 2009-02-27 at 10:04 +0100, Jens M Andreasen wrote:
Allrighty then, by hand is the way to go. With 50+
modules loaded on the
running machine, that should take no more than a week to identify what
they are, what they do (if anything?) and correct possible mistakes ...
Or, y'know, just go through the config menu and pick the things you
have :P
-dr
6:17 p.m.
On Mon, 02 Mar 2009 17:09:37 -0500, David Robillard <dave(a)drobilla.net>
wrote:
On Fri, 2009-02-27 at 10:04 +0100, Jens M Andreasen
wrote:
C'mon Dave, that would be too obvious.
I would write a jython script that would analyze the output of lsmod,
redirect the output to a perl script which would then generate a .config
file. Of course, all this would be done using a weird character encoding.
--
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
Allrighty then, by hand is the way to go. With
50+ modules loaded on the
running machine, that should take no more than a week to identify what
they are, what they do (if anything?) and correct possible mistakes ...
Or, y'know, just go through the config menu and pick the things you
have :P
-dr 
6:26 p.m.
On Mon, March 2, 2009 4:17 pm, MarcO'Chapeau wrote:
C'mon Dave, that would be too obvious.
I would write a jython script that would analyze the output of lsmod,
redirect the output to a perl script which would then generate a .config
file. Of course, all this would be done using a weird character encoding.
I don't see it working without XML, though.
--
G a b r i e l M B e d d i n g f i e l d
5702
days inactive
5716
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
11 participants
participants (11)
-
cal -
David Robillard -
Gabriel M. Beddingfield -
Hans Fugal -
Jens M Andreasen -
Jörn Nettingsmeier -
Lars-Erik Helander -
Luis Garrido -
MarcO'Chapeau -
Paul Davis -
Tracey Hytry