Re: Preventing module->init from being freed

2008-08-28 Thread Greg KH
On Thu, Aug 28, 2008 at 07:17:25PM -0500, Asim wrote: > Well - I wanted to re-initalized the device to its old state by > clearing the .bss, copying the old .data, calling the init function > followed by replaying the device history on it. I was not getting the > .init function by calling the modul

Re: Preventing module->init from being freed

2008-08-28 Thread Asim
Well - I'm working on something that performs online recovery as a subsytem of my project. There has been many past work which does this or uses such approach. Some famous examples are :- 1.www.cs.washington.edu/homes/levy/shadowdrivers.pdf 2. www.cs.virginia.edu/~nrp3d/wips/usenix04-abstract.pdf

Re: Preventing module->init from being freed

2008-08-28 Thread Asim
> At a glance it seems nosense, but I'd guess he would like to reuse a > block of code from the initialization code [which should fall back to > the straightforward solution where he might extract that block and > create another function]. Yes - but then that would be very driver specific or wor

Re: Preventing module->init from being freed

2008-08-28 Thread Asim
Well - I wanted to re-initalized the device to its old state by clearing the .bss, copying the old .data, calling the init function followed by replaying the device history on it. I was not getting the .init function by calling the module->init() as it is deleted by sys_init_module on a successful

Re: Preventing module->init from being freed

2008-08-28 Thread Greg KH
On Thu, Aug 28, 2008 at 07:06:59PM -0500, Asim wrote: > Well - I'm working on something that performs online recovery as a > subsytem of my project. There has been many past work which does this > or uses such approach. > > Some famous examples are :- > 1.www.cs.washington.edu/homes/levy/shadowdr

Re: Preventing module->init from being freed

2008-08-28 Thread Ribamar Santarosa de Sousa
On Thu, Aug 28, 2008 at 6:35 PM, Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Aug 28, 2008 at 11:09:26AM -0500, Asim wrote: >> Recovery without reload/disappearing the device. > > recovery from what? The module init code should have nothing to do with > this if you have a properly written driver.

Re: Preventing module->init from being freed

2008-08-28 Thread Greg KH
On Thu, Aug 28, 2008 at 11:09:26AM -0500, Asim wrote: > Recovery without reload/disappearing the device. recovery from what? The module init code should have nothing to do with this if you have a properly written driver. Do you have a pointer to your code which shows this need? What type of dev

Re: Preventing module->init from being freed

2008-08-28 Thread Asim
Recovery without reload/disappearing the device. -Asim On 8/27/08, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Aug 27, 2008 at 04:04:30PM -0500, Asim wrote: >> Hi, >> >> Linux has this feature where module->init() is freed for some drivers >> once insmod modprobe finishes. I want to prevent this

Re: Preventing module->init from being freed

2008-08-27 Thread Greg KH
On Wed, Aug 27, 2008 at 04:04:30PM -0500, Asim wrote: > Hi, > > Linux has this feature where module->init() is freed for some drivers > once insmod modprobe finishes. I want to prevent this from happening. Why? What do you want to do with that call after the code is loaded? thanks, greg k-h -

Re: Preventing module->init from being freed

2008-08-27 Thread Asim
Hi, I could fix this I just had to move unwind_remove_table(mod->unwind_info, 1); out of the loop. There also some problem with my MODULE_IS_MINE(). Thanks! Asim On 8/27/08, Asim <[EMAIL PROTECTED]> wrote: > Hi, > > Linux has this feature where module->init() is freed for some drivers > once ins

Preventing module->init from being freed

2008-08-27 Thread Asim
Hi, Linux has this feature where module->init() is freed for some drivers once insmod modprobe finishes. I want to prevent this from happening. For this I ifed out the following lines from the code for my particular module from module.c:- if !(MODULE_IS_MINE()) { unwind_remove_tab