linuxconsole-dev

Re: init functions

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

On 29 Jun 01 at 13:17, Paul Mundt wrote:

> #ifdef MODULE
> module_init(myfb_init);
> #endif
> module_exit(myfb_exit);

...
 
>     for (i = 0; i < NUM_FB_DRIVERS; i++)
>         if (fb_drivers[i].init)
>             fb_drivers[i].init();
> 
> Now this is cute and all, but it's about as practical as using a bulldozer
> to hunt down small furry creatures.

And after applying your hack we either (a) call some initialization
twice or (b) cannot reorder framebuffers. If you do not know
what I'm talking about, try booting your kernel with

video=vga16: video=matrox:

and then

video=matrox: video=vga16:

and look at completely different behavior (of course if you have
at least matrox alone in the box; you can replace matrox/vga16 with
framebuffer drivers you use). As long as there is no
global kernel service to reorder device scanning (such as my kernel
has for PCI), it is unavoidable to have this hack. With SCSI you can
say that your main disk is /dev/sdq, but with framebuffers it is
really fatal if something wents wrong and you even do not see what
went wrong because of console is now on some videocard without attached
monitor, or on vfb...
                                        Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

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...
                                                        

Re: init functions

[Paul M. <pm...@mv...>]

On Fri, Jun 29, 2001 at 10:33:40PM +0000, Petr Vandrovec wrote:
> And after applying your hack we either (a) call some initialization
> twice or (b) cannot reorder framebuffers. If you do not know
> what I'm talking about, try booting your kernel with
>=20
> video=3Dvga16: video=3Dmatrox:
>=20
> and then
>=20
> video=3Dmatrox: video=3Dvga16:
>=20
> and look at completely different behavior (of course if you have
> at least matrox alone in the box; you can replace matrox/vga16 with
> framebuffer drivers you use). As long as there is no
> global kernel service to reorder device scanning (such as my kernel
> has for PCI), it is unavoidable to have this hack. With SCSI you can
> say that your main disk is /dev/sdq, but with framebuffers it is
> really fatal if something wents wrong and you even do not see what
> went wrong because of console is now on some videocard without attached
> monitor, or on vfb...
>                                                =20
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:

video=3Dmatrox: video=3Dvga16:

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 prioritiz=
ed
cards, and the primary one where register_framebuffer() appends to.

If we had a matrox, a vga16, and a tdfx card and the matrox and tdfx wanted
to be initialized first, then the matrox would be removed from the primary
list and inserted as the head of the prioritized list, the tdfx would then =
be
appended to it, and so on and so on. Once we ran out of video=3D options, t=
he
remainder of the primary list could be appended to the prioritized list, or
the prioritized list inserted at the head of the primary list.

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.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.