Re: status grub2 port of grub-legasy map command

[Javier Martín]

El dom, 10-05-2009 a las 13:47 +0200, Vladimir 'phcoder' Serbinenko
escribió:

>         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
According to the last C standard, section 6.2.5.19, "The void type
comprises an empty set of values; it is an incomplete type that cannot
be completed." Thus, declaring a variable as "extern void" is perfectly
legal C, just like this program is perfectly legal:

        extern struct s b;

        int main(int argc, char** argv) {
                return 0;
        }

Notice that the declaration of "struct s" is absent, and so it is an
incomplete type, but still the declaration of a variable as "extern
struct s" is legal (using "b", however, would not, since the compiler
does not know the fields of "struct s"). Thus, declaring an extern
variable as the incomplete type "void" is legal too, and the only
operation that can be performed on it is taking its address with &. We
can try to get third opinions if you want, though.

> 
>         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 
For me, the possibility of creating an inconsistent situation in which
hd0 is "erased" through drivemap and hd1 disappears along with it is
enough. However, I think we could settle on making it a switch of the
drivemap command (like "--force" or SLT). Nevertheless, this would
change the meaning of the drivemap arguments from "the BIOS drive that
is represented in GRUB by hdN" to "the Nth BIOS hard drive", which might
be confusing.


-- 
-- Lazy, Oblivious, Recurrent Disaster -- Habbit

signature.asc
Description: Esto es una parte de mensaje firmado digitalmente