I'd like to get some short but, however, fully descriptive statements about how
you do your module development. I mean, what your way of doing coding,
insmod-ing, rmmod-ing, ... And what about code, that cannot be <M>, just [*] or
must-be-built-in.
Hm, actually there's nothing more to say. Except that I'm tired of rebooting. ;)
I tried kexec() but somehow I dont have all IDE devices sometimes on 'kexec -e'.
So this just not a solution for me... :)
Marc
On 02/11/06 04:42:06PM +0100, Marc Koschewski wrote:
> I'd like to get some short but, however, fully descriptive statements about how
> you do your module development. I mean, what your way of doing coding,
> insmod-ing, rmmod-ing, ... And what about code, that cannot be <M>, just [*] or
> must-be-built-in.
>
> Hm, actually there's nothing more to say. Except that I'm tired of rebooting. ;)
> I tried kexec() but somehow I dont have all IDE devices sometimes on 'kexec -e'.
> So this just not a solution for me... :)
>
> Marc
Depending on what part of the kernel you're working on you could look
at using a VM to test in, as long as you don't need direct access to
a specific piece of hardware in your machine you should be able to use
qemu, UML, VMWare, etc to boot your new kernel.
Jim.