>> [...] So, as far as I
>> can tell, these initializations of fb_info.node are just wasting
>> CPU cycles and confusing developers.
>>
>> Can anyone identify a place that uses the initialized value
>> of fb_info.node prior to fb_info.node being set by register_framebuffer?
>Your question here shows that you did not check.
>There are failure paths in register_framebuffer by which an
>uninitialized value may be displayed by a printk, if you delete the
>.node = NODEV initialization. So, your patch breaks things.
> Jeff
I looked before and did not notice any such case. I looked
again now at register_framebuffer and did not notice any such case.
It is something that can be missed and I don't know why you phrased
your response as if it would not be easy to miss ("Your question here
shows that you did not check"). Attempts at proof by intimidation
can produce bad decisions, in this case it may produce slightly
slower and bigger code.
How about pointing out where this occurs in
register_framebuffer? Then we can see if it is something where printing
out this initialized value actually records information that it not
otherwise clear from the printk (e.g., perhaps it is a printk that
is never called after the "node" field has been set to something
sensible).
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/