I don't see the advantage, particularly taking into account that the
current code is very happy to treat it as a black box that is taken from
the IVT and not touch it. However, if you insist, I'll change it.
No, it was more a suggestion
I guess you were trying to say that the casts are _not_ needed if I
declared it as such. What I'm trying to say is that in its only _direct_
use (in memcpy), its "const void" signature is perfectly fine for the
callee. All other uses are hidden within a nasty macro "INT13_OFFSET",
which would still be used with your proposed change. Thus, nothing is
gained, but a way to modify the int13h handler code on memory opens,
without requiring a cast. Thus, I think such a change would be for the
worse.
I see your reasoning. I personally prefer char[] and considering grub2 works with different compilers I prefer to avoid constructs which might be absent in some C dialects. I think we need a third opinion on this
AfaIr, most operating systems only implement very basic support for BIOS
disks (because they switch to their own drivers as soon as possible).
Many, among them Linux iIrc, just probe them sequentially and stop when
they find the first non-existant drive, while others probe hd0 thru hd7
and ignore the rest of them. In the first kind of OSes, mapping hd0=hd6
when you have no hd6 will make hd1 disappear along with hd0, which may
be very confusing to the user. Also, making a BIOS disk disappear will
not banish it from being detected by the OS normal drivers, so the
utility of this is pretty much restricted to DOS-like systems.
Of course it's not much additional benefit however I don't see any real reason not to let the user do it
Well, I don't like to put things like this, but then biosdisk and ata
should be fixed to avoid these kind of bugs.
It's more difficult then this. The bugs can be in BIOS. Again I think we need a third opinion