On Mer, 2003-04-23 at 12:27, Richard Zidlicky wrote:
> It seems that Geert´ idea would fit neatly into the current IDE
> system. Endianness of on disk data and drive control data are
> clearly different things. A while ago Andre suggested to switch
> the transport based on opcode to make it work, it might be even
> more straightforward to set some flag when the handler is selected
> or take a distinct handler altogether (ide_cmd_type_parser or
> ide_handler_parser).
Thats over complicating stuff I think.
> Otoh trying to solve that with loopback would mean new kernels
> wouldn´t even see the partition table of old installed harddisks
> on some machines.
Which is a real pain. I think its the right 2.5 answer. I'm not happy
about breaking that (even if its only for the m68k userbase in 2.4)
either.
I don't think command parsing is the right place. Turn your IDE layer
"right endian" and most stuff begins to look a lot saner already.
The "fixing" needs to be happening at the top of the IDE layer not
in the driver itself. For 2.5 that ought to be loopback or similar
for 2.4 it makes sense I think to effectively implement an endian
switcher without loopback for compatibility.
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:36 EST