[Nix-dev] Re: [Nix-commits] SVN commit: nix - 18468 - NicolasPierron - nixpkgs/branches/stdenv-updates/pkgs/lib

[Ludovic Courtès]

Hi,

Nicolas Pierron
<nicolas.b.pierron at gmail.com> writes:

> On Thu, Nov 19, 2009 at 23:29, Ludovic Courtès <ludo at gnu.org> wrote:
>> Hello,
>>
>> Nicolas Pierron
>> <nicolas.b.pierron at gmail.com> writes:
>>
>>> The system is represented by an attribute set which contains the cpu
>>> type, the architecture (pc, apple, ...) and the kernel.
>>
>> What are the “PC” and “Apple” architectures these days?
>
> Ask a MAC user ...

The only difference I can think of is the boot time process (do x86 macs
use OpenFirmware or something like that?).

>>> The architecture does not contains much information yet.  The kernel
>>> contains the type of the executable format like ELF, PE, ... .
>>
>> It’s the dynamic linker that deals with executable file formats.
>
> Except if you are downloading a pre-compiled version.

It’s the dynamic linker that actually parses the ELF file, etc., not the
kernel.  See ld.so(1) on a GNU system, for instance.

>>> Such details give you more control compared to the usual strings.  As
>>> example "i686-cygwin", is converted to the following set: (with the
>>> function mkSystemFromString)
>>>
>>> { cpu = cpuTypes.i686;
>>>   arch = architectures.pc;
>>>   kernel = kernels.cygwin;
>>> }
>>
>> How is the ‘arch’ bit inferred from “i686-cygwin”?
>
> Unfortunately it is not.  This is just a guess because (in general)
> the string is not expressive enough to infer such thing.

So what’s the point?

>> Overall, I feel that it’s nice to have more than just strings like
>> “i686-cygwin”, but I’m also slightly afraid of overdesign: building an
>> exceedingly complex model that’s too hard to keep close to reality.
>
> Could you develop what you are afraid of?

As can be seen from the examples above, the attribute set you’re
proposing is very detailed, but its actual meaning is ill-defined.

In addition, in a pure NixOS setup, all programs need to know are the
architecture and the kernel (as in “i686-linux”), because these are the
only elements not part of the dependency graph.  Every missing piece of
information is inferred from there: glibc provides <endian.h>, cpp
defines macros such as ‘__x86_64’, etc.

Now, hardware in general is not part of the dependency graph, and some
programs need more info about the hardware than just the CPU type, and
info that’s not provided through a kernel interface such as uname(2).
The only type of programs that fall into this category are boot loaders,
AFAICT (actually GRUB 2 seems to be happy with whatever ‘config.guess’
tells it, so we’re really talking about U-Boot.)

This would mean that the main (only?) purpose of this API you’re
designing is to build U-Boot.  That’s what I call “overdesign”.

Thanks,
Ludo’.