Re: Broken common.rmk change

[Robert Millan]

On Sun, Dec 06, 2009 at 01:21:46AM -0800, David Miller wrote:
> 
> Robert, the set of objects used to build grub-mkdevicemap on
> sparc64-ieee1275 is not the same as those used on other architectures.
> So this change was not correct:
> 
> 2009-11-26  Robert Millan  <address@hidden>
> 
>       * conf/common.rmk (sbin_UTILITIES): Add `grub-mkdevicemap'.
>  ...
>       * conf/i386-coreboot.rmk (sbin_UTILITIES): Remove `grub-mkdevicemap'.
>       (grub_mkdevicemap_SOURCES): Remove.
>  ...
>       * conf/sparc64-ieee1275.rmk: Likewise.
> 
> In particular, we use a special implementation devicemap.c on
> sparc64-ieee1275 so that openfirmware device nodes are emitted instead
> of "hd0" et al.
> 
> So when you moved the build rule into common.rmk you broke this.
> 
> This is probably the primary reason that the current tree works for
> nobody on sparc64 :-)
> 
> Before I found this problem, I tested with an existing devicemap and
> config file on a Niagara LDOM Linux guest and current trunk worked as
> well as it did when I was last active several months ago and I was
> able to boot Linux kernels with it.

We're actually in the process of getting rid of device.map;  in fact the
"hd0" names you see have no real effect on i386-pc, they're just ignored.

We now have more robust code that doesn't hardcode drive names.  grub-setup
now accepts plain system devices as arguments, even if they're not listed in
device.map.  grub-mkconfig generates a grub.cfg that relies on UUIDs instead
of hardcoding, etc.

But I might have missed some detail.  Is there a peculiarity of
sparc64-ieee1275 that makes this approach unpractical?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."