Changing functions/code on running target - Embedded
This is a discussion on Changing functions/code on running target - Embedded ; Hi,
I'm running 2.4 on an Intel IXP425, and I'm not happy with my
development efficiency:
- I modify code in the kernel, kernel modules, and applications.
- Compilation of the image takes 3 minutes, which I find annoying.
- ...
-
Changing functions/code on running target
Hi,
I'm running 2.4 on an Intel IXP425, and I'm not happy with my
development efficiency:
- I modify code in the kernel, kernel modules, and applications.
- Compilation of the image takes 3 minutes, which I find annoying.
- A reboot takes 30 seconds and destroys all state.
- Some kernel modules cannot be reloaded, so a full compile and reboot
is necessary.
The simplest way to solve all these problems would be the ability to
change functions on the running target. It should not matter if the
code is in the kernel or in an application. Is there anything like
this?
Thanks,
Daniel
-
Re: Changing functions/code on running target
In article <1156324874.511569.74560@m73g2000cwd.googlegroups.c om>,
"Daniel" writes:
> Hi,
>
> I'm running 2.4 on an Intel IXP425, and I'm not happy with my
> development efficiency:
>
> - I modify code in the kernel, kernel modules, and applications.
> - Compilation of the image takes 3 minutes, which I find annoying.
> - A reboot takes 30 seconds and destroys all state.
> - Some kernel modules cannot be reloaded, so a full compile and reboot
> is necessary.
>
> The simplest way to solve all these problems would be the ability to
> change functions on the running target. It should not matter if the
> code is in the kernel or in an application. Is there anything like
> this?
Well, if the code is in the kernel, and if it is not a module, then
you can not avoid a reboot, thereby loosing all state. If it *is* a
module, it should be possible to compile it seperate from the kernel and
unload/reload it in a running system. However, you said above that
"Some kernel modules cannot be reloaded". Care to explain why?
IMHO the ideal setup for quick development turnaround times is
an NFSroot system: Keep the root file system on the development
host and let the target mount it via NFS. That way, you can rebuild
any files on the development host and just load them on the target.
We do that all the time.
Rob
--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com
-
Re: Changing functions/code on running target
> However, you said above that "Some kernel modules cannot be
> reloaded". Care to explain why?
We are using the Intel Ethernet driver module ixp425_eth.c, which
complains about "locked resources" or so.
> IMHO the ideal setup for quick development turnaround times is
> an NFSroot system: Keep the root file system on the development
> host and let the target mount it via NFS. That way, you can rebuild
> any files on the development host and just load them on the target.
> We do that all the time.
We use a commercial Linux distribution (not sure if I'm allowed to
name it), which officially doesn't support NFS root file systems.
Maybe there is a simple way of making this work?
-- Daniel
-
Re: Changing functions/code on running target
Daniel wrote:
[snip]
> We use a commercial Linux distribution (not sure if I'm allowed to
> name it), which officially doesn't support NFS root file systems.
> Maybe there is a simple way of making this work?
Check Documentation/nfs-root.txt in the kernel source directory.
--
:wq
^X^Cy^K^X^C^C^C^C
-
Re: Changing functions/code on running target
In article <1156428950.313510.143760@i3g2000cwc.googlegroups.c om>,
"Daniel" writes:
>> However, you said above that "Some kernel modules cannot be
>> reloaded". Care to explain why?
>
> We are using the Intel Ethernet driver module ixp425_eth.c, which
> complains about "locked resources" or so.
Hmm, that could be a bug in the driver. Anyway, if you build an
NFSroot system, you don't want to unload the NIC driver as that
is your link to the root file system. Typically, you would link
it into the kernel statically.
>
>> IMHO the ideal setup for quick development turnaround times is
>> an NFSroot system: Keep the root file system on the development
>> host and let the target mount it via NFS. That way, you can rebuild
>> any files on the development host and just load them on the target.
>> We do that all the time.
>
> We use a commercial Linux distribution (not sure if I'm allowed to
> name it), which officially doesn't support NFS root file systems.
There is an embedded Linux distribution available that comes with
a number of preconfigured configurations, NFSroot being one of them.
(Hint: see my .sig)
> Maybe there is a simple way of making this work?
As another poster has suggested: read Documentation/nfs-root.txt
Good Luck
Rob
--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com