Re: freeing a static after one use only?

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Sat Feb 19 2000 - 05:28:28 EST


"A month of sundays ago Tim Magill wrote:"
> On Sat, Feb 19, 2000 at 12:50:29AM +0100, Peter T. Breuer wrote:
> > "A month of sundays ago Tim Magill wrote:"
> > > On Thu, Feb 17, 2000 at 11:54:46PM +0100, Peter T. Breuer wrote:
> > > > use it once and then throw it away
> > > Would it be possible to define the static data in its own loadable
> > > module, that your driver could insmod and then rmmod?
> > It's been suggested. I gave it a try just now, but got oopses.
> > Possibly address space and/or unwanted optimization issues.

> It seems to me that data depending on function could have worked,
> but how did you resolve the data addresses in the function module when
> the function module is loaded before the data? Or is this what caused
> the oops?

Don't worry about that. The fuction module knows about its data
structures, which are all set up but empty-ish. The data module
loads, sees the existing data structures, says aha! and modifies
them according to a big table it has built in. It then goes away.

> Logically, the function module needs to depend on the data module,

This analysis "turns out not to be the case". The function module
must work on its own, as it will be left alone in the kernel when
the big data module goes away.

> module. Then the module can be cleaned normally. Second, there may
> be a way to manually insmod/rmmod the data module as if you were in
> userland. That way there is no dependency between either of them.

This is the intended scenario (but dependency of the data module
on the function module is both harmless and necessary).

Bouncing a file content data into the module via explicit reads or other
mechanisms is possible, but I don't like it for several reasons.

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:23 EST