I understand that you specifically do not *wish* to have this implemented.
No, completely wrong. My point is that if I support a component, I better have the specs available, and I better have the hardware available for testing. None of the two is given.
What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?
Again . Jens Schönfeld is very likely able to provide you all the spec information needed, and there is source code available from all the mentioned projects about how this is implemented.
Thus, you can do the following:
a) ask Elbox to update their software.
b) ask Elbox to send me their specs and their hardware to get it supported,
c) organize hardware and specifications, and send them
I don't get exactly why this focus on ElBox? This was never their invention, they are just one of many implementers, among them, also Jens Schönfeldt -
http://wiki.icomp.de/wiki/IDE-fix (and now I understand that EB is "Elaborate Bytes")
There *is* no component going into the kickstart, especially into a component we cannot update by software, that is untested by any means. I don't want to end with the situation that we have some half-working component without at least having the chance to get it tested, and having verified that it does what it is supposed to do.
One could argue that the current scsi.device is "half working" as one could really support exactly twice as many devices on the bus
There is no need to put it in kickstart - it would be easy to allow the (drumroll) __*** U S E R ***___ to explicitly load a dedicated variant of scsi.device with such support that officially is considered "an experiemental hack".
