public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: PATCH 2.5.2.9: fbdev kdev_t build fixes
@ 2002-01-06 23:46 Adam J. Richter
  0 siblings, 0 replies; 3+ messages in thread
From: Adam J. Richter @ 2002-01-06 23:46 UTC (permalink / raw)
  To: linux-kernel

Jeff Garzik writes:
>This patch fixes the build for the rest of fbdev in 2.5.2-pre9...

        I submitted a patch two days ago that fixed drivers/video
compilation.  The difference between my patch and yours is that
while I deleted the initializations of the form "fb_info.node = -1;",
you replaced them with "fb_info.node = NODEV;".

        -1 is all ones, NODEV is currently encoded as all zeroes.
I see no change in your patch that modifies any test for the
value of the "node" field, so, if there was any test that relied
on this value, it is now broken.

        However, I believe that there is no test that relies on the
initial value of fb_info.node before any call to register_framebuffer
(which sets fb_info.node to something meaningful).  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?

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

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: PATCH 2.5.2.9: fbdev kdev_t build fixes
@ 2002-01-06 23:47 Adam J. Richter
  0 siblings, 0 replies; 3+ messages in thread
From: Adam J. Richter @ 2002-01-06 23:47 UTC (permalink / raw)
  To: linux-kernel

Jeff Garzik wrote:
>"Adam J. Richter" wrote:

>> [...] 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."

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-01-06 23:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.05.10107021127040.23703-100000@callisto.of.borg>
2002-01-06 22:30 ` PATCH 2.5.2.9: fbdev kdev_t build fixes Jeff Garzik
2002-01-06 23:46 Adam J. Richter
  -- strict thread matches above, loose matches on Subject: below --
2002-01-06 23:47 Adam J. Richter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox