Messages in this thread |  | | From | Keith Owens <> | | Subject | Re: Where did vm_operations_struct->unmap in 2.4.0 go? | | Date | Thu, 11 Jan 2001 23:12:05 +1100 |
| |
On Thu, 11 Jan 2001 11:42:24 +0000, David Woodhouse <dwmw2@infradead.org> wrote: >Taking away get_module_symbol() and providing a replacement which has link >order problems wasn't really very sensible. > >It's too late to do the sensible thing and deprecate the old version rather >than having a 'flag day'. But can we at least fix the link order crap? > >struct static_inter_module_entry { > const char *im_name; > const void *userdata; >}; > >#define inter_module_register_static(x,y) \ > static struct static_inter_module_entry __ime_##x \ > __attribute__((unused,__section__(".intermodule")) \ > = { #x, y }; > >.. and the obvious for looking in that table in inter_module_get().
If object X registers data for object Y to use then X _must_ initialise before Y. It does not matter whether the registration method is static or dynamic, the initialisation order must be observed.
Q. With your suggested static method, what happens when Y initialises before X, calls inter_module_get, retrieves X's static data and starts to use it before X has initialised? A. Oops!
The whole point of registration methods is that the owner of the data decides when they are ready to provide the service. Ensuring that code is initialised in the correct order, with providers starting before consumers, is a fact of life.
I dislike the method that the kernel uses to control initialisation order, but that is an entirely separate problem from inter_module_xxx. What we really want at startup is a correct initialisation order. What we have is the order that objects are selected in a Makefile which maps to the link order of objects in vmlinux which maps to the listed order of init routines in section .init.text which maps to initialisation order. The mechanism is three layers away from the problem and it is difficult to understand for many people.
It would be much nicer to define ordering sets. Code in driver foo needs the code in driver bar to initialise first. cfi_probe cannot initialise until cfi_cmdset_0001 and cfi_cmdset_0002 have initialised. Declare it that way so it is clear what is going on and why, instead of being implied by the Makefile order via three layers of indirection. Then let the kernel build system do whatever it takes to honour the documented initialisation order.
The problem is, Linus likes the current method.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |