Re: [PATCH] Mark i2o config broken on 64-bit platforms.

[Miquel van Smoorenburg]

In article <xs4all.20080709044743.0dd15a3f.akpm@xxxxxxxxxxxxxxxxxxxx> you write:
>On Wed, 09 Jul 2008 12:35:47 +0100 David Howells <dhowells@xxxxxxxxxx> wrote:
>
>> Mark i2o config broken on 64-bit platforms as it generates these:
>> 
>> In file included from drivers/message/i2o/config-osm.c:39:
>> drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru':
>> drivers/message/i2o/i2o_config.c:889: warning: cast to pointer from
>integer of different size
>> drivers/message/i2o/i2o_config.c:945: warning: cast to pointer from
>integer of different size
>> 
>> which are apparently non-trivial to fix (eg: inserting a cast through unsigned
>> long is not correct according to Linus).  This would be due to struct
>> sg_simple_element only having a 32-bit addr_bus value.
>> 
>Sigh.  I've been staring at that warning for so long.
>Is it actually known to be broken on 64-bit, or does it happen to work?

The i2o driver works on 64 bit, though my experiences are less
than stellar (which is why I submitted the dpt_i2o 64 bit update
for 2.6.26).

However this warning doesn't have much to do with the functioning
of the driver. It is the Adaptec DPT API for the management interface,
and that API is currently 32 bits. The i2o layer and the dpt_i2o driver
have have the same issues here.

The adaptec management application ("raidutils") is also not 64-bit clean
(read the code .. it puts pointers into ints etc etc), and fixing
that is not trivial, _but_ the 32 bit version works on a 64 bit kernel.

Marking the whole i2o layer broken because the adaptec management API
hasn't been updated to 64 bits (but does work in 32 bit compatibility
mode) is going a bit to far I think.

First, if you want to mark something broken, it would be
CONFIG_I2O_EXT_ADAPTEC .. second, compiling it gives warnings,
but it works, and I bet people are using it.

Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/