Re: init functions

[Petr V. <VAN...@vc...>]

On 29 Jun 01 at 14:05, Paul Mundt wrote:

> This shouldn't really be that big of a deal.. if we use a linked list
> that devices insert themselves into via register_framebuffer(), it wouldn't
> be much more difficult to move nodes around the list in the order of which
> they were passed. For example:

What you are talking about? If you want to use kernel init functions
(no #ifdef MODULE in drivers), devices are initialized in link order
and there is no way to change it. It is way too long to do anything
after register_framebuffer() is invoked.

> video=matrox: video=vga16:
> 
> We obviously want the matrox to be initialized _prior_ to the vga16.. the
> matrox gets inserted at the head of the list and the vga16 after it. The
> quickest way to do this would be to have two lists.. one list for prioritized
> cards, and the primary one where register_framebuffer() appends to.

> This might seem kind of hackish, but it should be able to be done fairly
> cleanly.. and it'd be a better solution then the current hacks, IMO.

I'm lost. Either you want to remove code completely from fbmem.c - and
in that case you have nothing to reorder, as you have no control on fbdev
initialization order (so current possibility of reordering is lost)
and you even do not know init function addresses (so again no reordering),
or you still want fbmem control ordering - in that case I do not understand
what you are trying to do. Maybe real patch which changes at least one
device to use your scheme would help me, but one you sent in original
message was at least incomplete, as it initialized matroxfb twice
if someone did 'video=matrox:' on kernel commandline, and it did not
reduce namespace pollution, as fbmem still needed that symbol. So?
                                                Thanks,
                                                        Petr Vandrovec
                                                        van...@vc...