Hello. Sorry for the delay, I was kept busy by making grub2 compile with apples compiler. It already works just needs some testing and cleanup and then I'll post a patch
> 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 > > -- Regards Vladimir 'phcoder' Serbinenko
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
