[PATCH 0/2] image: Add system field.

Done

Details

7 participants

Danny Milosavljevic
Efraim Flashner
Ludovic Courtès
Mathieu Othacehe
Maxim Cournoyer
Mathieu Othacehe
zimoun

Owner: unassigned

Submitted by: Mathieu Othacehe

Severity: normal

Merged with

Mathieu Othacehe wrote on 3 Dec 2020 11:53

Recipients:(address . guix-patches@gnu.org)

Message-ID:20201203105353.149482-1-othacehe@gnu.org

Hello,

Here's a small patchset to improve the creation of disk-images on non-Intel

systems. Currently, when selecting "arm32-raw" or "arm64-raw" image types,

"guix system" will try to cross-compile to the relevant architectures,

regardless of the current system architecture.

This adds a "system" field to the image definition that indicates the

appropriate system. Then, if we are already running on this system,

"system-image" will build the image natively instead of using

cross-compilation. The image type "raw" is also renamed to "efi-raw" which is

more accurate.

Finally, as discussed with Danny on IRC, it could make sense to change the

default image type depending on the current system: efi-raw on x86_64-linux

and i686-linux, arm32-raw on armhf-linux and so on.

WDYT?

Thanks,

Mathieu

Mathieu Othacehe (2):

image: Add system field.

image: Rename "raw" image-type to "efi-raw".

doc/guix.texi | 10 +++++-----

gnu/image.scm | 3 +++

gnu/system/image.scm | 18 ++++++++++++++----

guix/scripts/system.scm | 2 +-

4 files changed, 23 insertions(+), 10 deletions(-)

2.29.2

Mathieu Othacehe wrote on 3 Dec 2020 11:58

control message for bug #45021

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87mtyvyx41.fsf@cervin.i-did-not-set--mail-host-address--so-tickle-me

merge 45021 45020

quit

Mathieu Othacehe wrote on 3 Dec 2020 11:58

control message for bug #45022

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87lfefyx3q.fsf@cervin.i-did-not-set--mail-host-address--so-tickle-me

merge 45022 45020

quit

zimoun wrote on 3 Dec 2020 14:11

Re: [bug#45020] [PATCH 0/2] image: Add system field.

Recipients:

Message-ID:86eek7yqyy.fsf@gmail.com

Hi Mathieu,

On Thu, 03 Dec 2020 at 11:53, Mathieu Othacehe <othacehe@gnu.org> wrote:

Toggle quote (4 lines)

> Finally, as discussed with Danny on IRC, it could make sense to change the

> default image type depending on the current system: efi-raw on x86_64-linux

> and i686-linux, arm32-raw on armhf-linux and so on.

The “less astonishment” default sounds good to me. :-)

Cheers,

simon

Efraim Flashner wrote on 9 Dec 2020 09:25

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:X9CKFDuePL1msoo1@E5400

On Thu, Dec 03, 2020 at 11:53:51AM +0100, Mathieu Othacehe wrote:

Toggle quote (19 lines)> Hello,
> 
> Here's a small patchset to improve the creation of disk-images on non-Intel
> systems. Currently, when selecting "arm32-raw" or "arm64-raw" image types,
> "guix system" will try to cross-compile to the relevant architectures,
> regardless of the current system architecture.
> 
> This adds a "system" field to the image definition that indicates the
> appropriate system. Then, if we are already running on this system,
> "system-image" will build the image natively instead of using
> cross-compilation. The image type "raw" is also renamed to "efi-raw" which is
> more accurate.
> 
> Finally, as discussed with Danny on IRC, it could make sense to change the
> default image type depending on the current system: efi-raw on x86_64-linux
> and i686-linux, arm32-raw on armhf-linux and so on.
> 
> WDYT?

I'm not sure about i686-linux being an efi-raw type. I always assumed

they were all not EFI.

Toggle quote (21 lines)> Thanks,
> 
> Mathieu
> 
> Mathieu Othacehe (2):
>   image: Add system field.
>   image: Rename "raw" image-type to "efi-raw".
> 
>  doc/guix.texi           | 10 +++++-----
>  gnu/image.scm           |  3 +++
>  gnu/system/image.scm    | 18 ++++++++++++++----
>  guix/scripts/system.scm |  2 +-
>  4 files changed, 23 insertions(+), 10 deletions(-)
> 
> -- 
> 2.29.2
> 
> 
> 
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Mathieu Othacehe wrote on 9 Dec 2020 11:15

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:87tusvz3nf.fsf@gnu.org

Hello Efraim,

Toggle quote (3 lines)

> I'm not sure about i686-linux being an efi-raw type. I always assumed

> they were all not EFI.

The "efi-raw" image type is actually an hybrid image type supporting EFI

and BIOS legacy boot methods.

Maybe we should then rename "raw" to "bios-efi-raw" or

"bios-efi-hybrid-raw", what do you think?

Thanks,

Mathieu

Efraim Flashner wrote on 9 Dec 2020 11:27

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:X9CmncYV5Kcegakt@E5400

On Wed, Dec 09, 2020 at 11:15:32AM +0100, Mathieu Othacehe wrote:

Toggle quote (12 lines)> 
> Hello Efraim,
> 
> > I'm not sure about i686-linux being an efi-raw type. I always assumed
> > they were all not EFI.
> 
> The "efi-raw" image type is actually an hybrid image type supporting EFI
> and BIOS legacy boot methods.
> 
> Maybe we should then rename "raw" to "bios-efi-raw" or
> "bios-efi-hybrid-raw", what do you think?

My hope is to eventually produce an image for mips64el again, which

would need an ext2 formatted /boot partition. I'm hoping to make it not

too hard to hack that in in the future :)

Perhaps it makes sense to name them according to the architecture more?

we have arm32-raw and aarch64-raw, how about i686-raw and x86_64-raw?

Make it clear exactly what architecures they target. Then we can

continue with the hybrid bios/efi images anyway.

Toggle quote (4 lines)

> Thanks,

> Mathieu

-- 
Efraim Flashner   <efraim@flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Ludovic Courtès wrote on 11 Dec 2020 17:50

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:87eejw5lsn.fsf@gnu.org

Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (15 lines)> Here's a small patchset to improve the creation of disk-images on non-Intel
> systems. Currently, when selecting "arm32-raw" or "arm64-raw" image types,
> "guix system" will try to cross-compile to the relevant architectures,
> regardless of the current system architecture.
>
> This adds a "system" field to the image definition that indicates the
> appropriate system. Then, if we are already running on this system,
> "system-image" will build the image natively instead of using
> cross-compilation. The image type "raw" is also renamed to "efi-raw" which is
> more accurate.
>
> Finally, as discussed with Danny on IRC, it could make sense to change the
> default image type depending on the current system: efi-raw on x86_64-linux
> and i686-linux, arm32-raw on armhf-linux and so on.

I understand the need for an easier way to create images. However, I

feel like <image> is the wrong place for ‘system’ and ‘target’: the

image format, conceptually, has nothing to do with whether we’re

cross-compiling, compiling for a specific system, etc.

It also seems wrong to me that ‘--image-type’ would, in some cases (but

not all?), override ‘-s’ and ‘--target’.

I feel like we’re missing an abstraction that would build on top of

images, but I’m not sure what that would look like.

Thoughts?

Ludo’.

Mathieu Othacehe wrote on 12 Dec 2020 09:30

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87h7orpgsh.fsf@gnu.org

Hey,

Toggle quote (5 lines)

> I understand the need for an easier way to create images. However, I

> feel like <image> is the wrong place for ‘system’ and ‘target’: the

> image format, conceptually, has nothing to do with whether we’re

> cross-compiling, compiling for a specific system, etc.

On the one hand, I agree that adding "system" and "target" to <image>,

so that they can override the corresponding arguments doesn't feel

nice. On the other hand, I think that dealing with system/target is too

low level for most users.

When using Yocto, Buildroot or even OpenWrt, you say "build me an image

for that board/machine" and not, "build me an image for that board by

cross-compiling to this mysterious triplet".

If the user selects the image type "pine64" or "novena", it's obvious

that the image has to be built for ARM, so I think it makes sense to

hardcode it somewhere. The <image> record might not be the right

location for that information but I cannot think of another one.

Maybe someone else?

Thanks,

Mathieu

zimoun wrote on 12 Dec 2020 13:34

Recipients:(address . 45020@debbugs.gnu.org)

Message-ID:86im97fbjt.fsf@gmail.com

Hi,

On Sat, 12 Dec 2020 at 09:30, Mathieu Othacehe <othacehe@gnu.org> wrote:

Toggle quote (4 lines)

> When using Yocto, Buildroot or even OpenWrt, you say "build me an image

> for that board/machine" and not, "build me an image for that board by

> cross-compiling to this mysterious triplet".

I confirm that the triplet is still mysterious to me. Since I do not do

that often, each time I am trying, I need to browse the doc, when I am

not asking again and again on IRC.

Therefore, I do not know if the record is the correct abstraction but

somehow a mapping helper is welcome. :-) Maybe via a command-line option

displaying the “board“ and the “triplet”.

All the best,

simon

Ludovic Courtès wrote on 12 Dec 2020 18:51

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:87czze3obq.fsf@gnu.org

Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (14 lines)>> I understand the need for an easier way to create images.  However, I
>> feel like <image> is the wrong place for ‘system’ and ‘target’: the
>> image format, conceptually, has nothing to do with whether we’re
>> cross-compiling, compiling for a specific system, etc.
>
> On the one hand, I agree that adding "system" and "target" to <image>,
> so that they can override the corresponding arguments doesn't feel
> nice. On the other hand, I think that dealing with system/target is too
> low level for most users.
>
> When using Yocto, Buildroot or even OpenWrt, you say "build me an image
> for that board/machine" and not, "build me an image for that board by
> cross-compiling to this mysterious triplet".

Agreed; I understand that this is a desirable level of abstraction.

Toggle quote (5 lines)

> If the user selects the image type "pine64" or "novena", it's obvious

> that the image has to be built for ARM, so I think it makes sense to

> hardcode it somewhere. The <image> record might not be the right

> location for that information but I cannot think of another one.

OTOH, I might want to cross-build a Novena image from x86_64, or I might

want to build it natively. Perhaps what could be said is that a Novena

image can either be built natively on armhf-linux, or cross-built to

arm-linux-gnueabihf. Perhaps we should encode this constraint rather

than a specific ‘system’ or ‘target’? (I’m thinking out loud…)

Regarding ARM boards, do you think some additional abstraction is needed

to encode cross-cutting concerns that affect not just the partition

layout and choice of a bootloader, but also kernel build options, and

maybe options for some userland packages (are there examples of that,

though?)?

Maybe the best course of action is to add all this info to <image> until

we have a better idea, after all.

I guess I’m contributing more questions that answers. :-)

Thanks,

Ludo’.

Ludovic Courtès wrote on 13 Dec 2020 15:15

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:87pn3dzt9m.fsf@gnu.org

Hi!

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (10 lines)> On Sat, 12 Dec 2020 at 09:30, Mathieu Othacehe <othacehe@gnu.org> wrote:
>
>> When using Yocto, Buildroot or even OpenWrt, you say "build me an image
>> for that board/machine" and not, "build me an image for that board by
>> cross-compiling to this mysterious triplet".
>
> I confirm that the triplet is still mysterious to me.  Since I do not do
> that often, each time I am trying, I need to browse the doc, when I am
> not asking again and again on IRC.

The triplet is a stringy DSL to designate a CPU architecture, hardware

vendor, and operating system; nowadays people often piggy-back

information to distinguish “OS” from “kernel”, to specify the ABI, etc.

(info "(autoconf) Specifying Target Triplets").

It was designed at a time where things were quite different (nowadays

the “vendor” part is almost always useless), and it’s primarily for

userland software. It’s well-documented though, no mystery. ;-)

Now, a triplet does not capture all the things we’re interested in, like

details of the boot-up sequence of the ARM board, preferred bootloader,

Binutils tweaks, etc.

From a Guix System viewpoint, we could define an abstract

architecture/platform/target as something that embodies the info

contained in triplets and more, say:

Toggle snippet (13 lines);; Description of a platform supported by the GNU system.
(define-record-type* <platform> platform make-platform
  platform?
  (triplet            platform-triplet)            ;"x86_64-linux-gnu"
  (system-type        platform-system-type)        ;"x86_64-linux"
  (linux-architecture platform-linux-architecture) ;"amd64"
  (kernel             platform-kernel)             ;<package>
  (ld.so              platform-ld.so)              ;"ld-linux-x86-64.so.2"
  (gcc                platform-gcc)                ;<package>
  (binutils           platform-binutils)           ;<package>
  (libc               platform-transform-libc))    ;<package>

Currently that info is scattered in various pieces in Guix: in base.scm,

cross-base.scm, linux.scm, bootstrap.scm, etc. Having all that in a

single place would be an improvement.

Of course this is going beyond what was originally discussed in this

thread and I’m not claiming this is the solution to work on right now.

It might be a general direction to follow longer-term, though.

Thoughts?

Ludo’.

Danny Milosavljevic wrote on 13 Dec 2020 15:59

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:20201213155913.7022f5ee@scratchpost.org

Hi,

I want to note that there's a difference between cross-compiling things

and natively compiling things (even if only qemu transparent emulation).

The resulting images between cross vs non-cross could be (and probably are)

different.

So I think there should be a command line parameter to the image script that

specifies whether to cross-compile or not--there's no way around it that I can

see.

Also, this image generation thing is mostly for bootstrapping Guix, so it is

fine if that only supports configurations we actually tested.

Ludo said:

Toggle quote (5 lines)

> > However, I

> > feel like <image> is the wrong place for ‘system’ and ‘target’: the

> > image format, conceptually, has nothing to do with whether we’re

> > cross-compiling, compiling for a specific system, etc.

It depends on what you mean. How the word "image format" is colloquially used

in the VM world, it very much has to with what guest system (and even which

emulator) this image is for, and that's not at all variable.

But I agree that there are other things that could be variable per image target

system, like the kernel version that actually works, the u-boot that actually

works, the partition layout that actually works, the initrd modules, weird

system packages and/or activation scripts that are required for booting etc.

See buildroot.

Mathieu said:

Toggle quote (5 lines)

> On the one hand, I agree that adding "system" and "target" to <image>,

> so that they can override the corresponding arguments doesn't feel

> nice. On the other hand, I think that dealing with system/target is too

> low level for most users.

I agree.  Also, I want to stress that if we do this kind of image generation,
it has to be for Guix images we actually tested.  So the general case with
specifying a random system and target we never saw before cannot be supported
anyway (and will likely not work), especially since bootloaders are anything
but portable in general.

Toggle quote (4 lines)

> When using Yocto, Buildroot or even OpenWrt, you say "build me an image

> for that board/machine" and not, "build me an image for that board by

> cross-compiling to this mysterious triplet".

I agree that we should not ask the user to specify a triplet to build a guix

system image. It's obvious what the triplet is per image, since we tested

it anyway (riiiight?).

Toggle quote (4 lines)

> If the user selects the image type "pine64" or "novena", it's obvious

> that the image has to be built for ARM, so I think it makes sense to

> hardcode it somewhere.

I agree.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/WLEEACgkQ5xo1VCww

uqUZcwgAgWuEsiJ7Q6B8D+em4JqUIHOU6/SWwdfURrPhlDIS1cO3SbEIYfUUn9bJ

XXZlEZ2JgCs2YA1NXK/y9xqz3MUJ2Vz54Yhg+1+r0w9tjLbZDtLIobIARodaherU

bx3fweuwc9QpedTUDexQDS86qGamOulJkCBgVqVjo+hfHDQ9xADYr8ksk/ifK7le

/8JfW1BCm6H8XPkIplpJRxi5T4HlZaLoo+0l93siLmeak/cw1h5wESKqyx/vy1hM

J52bl6eegMBUqLRyRo2c8ANx89b+SSO5RT1EjTphq9LooXcJ3FuoGkrWH/DOGP3z

IaEdGaKEMxWEp1Rk5GACNfCBXViG5w==

=cLyo

-----END PGP SIGNATURE-----

Mathieu Othacehe wrote on 15 Dec 2020 10:58

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87czzbfl0k.fsf@gnu.org

Hey,

Toggle quote (6 lines)

> OTOH, I might want to cross-build a Novena image from x86_64, or I might

> want to build it natively. Perhaps what could be said is that a Novena

> image can either be built natively on armhf-linux, or cross-built to

> arm-linux-gnueabihf. Perhaps we should encode this constraint rather

> than a specific ‘system’ or ‘target’? (I’m thinking out loud…)

Maybe the next step would be to define a <machine> record that encodes

the "system" and "target" constraints for a specific board/machine. The

kernel build options and userland packages options you are mentioning

above could also be part of this record.

As Danny is proposing, we could also have a "--native" argument to "guix

system" that would force native build instead of cross-compiling.

Toggle quote (9 lines)

> Regarding ARM boards, do you think some additional abstraction is needed

> to encode cross-cutting concerns that affect not just the partition

> layout and choice of a bootloader, but also kernel build options, and

> maybe options for some userland packages (are there examples of that,

> though?)?

> Maybe the best course of action is to add all this info to <image> until

> we have a better idea, after all.

Sure, I agree.

Toggle quote (2 lines)

> I guess I’m contributing more questions that answers. :-)

It helps a lot anyway :)

Thanks,

Mathieu

zimoun wrote on 15 Dec 2020 15:11

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:86r1nrma5m.fsf@gmail.com

Hi,

On Sun, 13 Dec 2020 at 15:15, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (4 lines)

> It was designed at a time where things were quite different (nowadays

> the “vendor” part is almost always useless), and it’s primarily for

> userland software. It’s well-documented though, no mystery. ;-)

It is not because it is well-documented that I do not feel confused or

it puzzles me or how difficult it is to understand or know about,

especially when the definition appears now a bit awkward. Ah it is the

meaning from the dictionary of mystery. ;-)

Kidding aside, thanks for the explanations. I have bookmarked them.

Toggle quote (14 lines)> --8<---------------cut here---------------start------------->8---
> ;; Description of a platform supported by the GNU system.
> (define-record-type* <platform> platform make-platform
>   platform?
>   (triplet            platform-triplet)            ;"x86_64-linux-gnu"    
>   (system-type        platform-system-type)        ;"x86_64-linux"        
>   (linux-architecture platform-linux-architecture) ;"amd64"               
>   (kernel             platform-kernel)             ;<package>             
>   (ld.so              platform-ld.so)              ;"ld-linux-x86-64.so.2"
>   (gcc                platform-gcc)                ;<package>
>   (binutils           platform-binutils)           ;<package>
>   (libc               platform-transform-libc))    ;<package>   
> --8<---------------cut here---------------end--------------->8---

Naively and what confuse me is the redundancy of the information. For

example, is it possible to do something else than “gnu”? Or when one

thing is fixed, other parameters are also fixed, for instance does it

make sense

"x86_64-linux-gnu"

"i686-hurd"

"arm"

"ld-hurd-arm.so.2"

Obviously, the plumbing where it is not a “mystery” for some user is

necessary. But for user like me, the interface should be simple.

Toggle quote (4 lines)

> Currently that info is scattered in various pieces in Guix: in base.scm,

> cross-base.scm, linux.scm, bootstrap.scm, etc. Having all that in a

> single place would be an improvement.

Yes.

Toggle quote (4 lines)

> Of course this is going beyond what was originally discussed in this

> thread and I’m not claiming this is the solution to work on right now.

> It might be a general direction to follow longer-term, though.

I agree. Aside my usual drift. ;-)

All the best,

simon

Ludovic Courtès wrote on 15 Dec 2020 22:56

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:87eejqlon4.fsf@gnu.org

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (26 lines)>> --8<---------------cut here---------------start------------->8---
>> ;; Description of a platform supported by the GNU system.
>> (define-record-type* <platform> platform make-platform
>>   platform?
>>   (triplet            platform-triplet)            ;"x86_64-linux-gnu"    
>>   (system-type        platform-system-type)        ;"x86_64-linux"        
>>   (linux-architecture platform-linux-architecture) ;"amd64"               
>>   (kernel             platform-kernel)             ;<package>             
>>   (ld.so              platform-ld.so)              ;"ld-linux-x86-64.so.2"
>>   (gcc                platform-gcc)                ;<package>
>>   (binutils           platform-binutils)           ;<package>
>>   (libc               platform-transform-libc))    ;<package>   
>> --8<---------------cut here---------------end--------------->8---
>
> Naively and what confuse me is the redundancy of the information.  For
> example, is it possible to do something else than “gnu”?  Or when one
> thing is fixed, other parameters are also fixed, for instance does it
> make sense
>
>         "x86_64-linux-gnu"    
>         "i686-hurd"        
>         "arm"               
>         "ld-hurd-arm.so.2"
>
> ?

For a given platform, say “GNU/Hurd on i586”, all the parameters are

fixed, with some degrees of liberty on the toolchain, though.

However, currently that information is scattered across different

places, so the goal here would be to gather it all in one place, which

should facilitate porting to new platforms.

Ludo’.

Maxim Cournoyer wrote on 16 Jul 2021 04:04

Re: bug#45020: [PATCH 0/2] image: Add system field.

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:87o8b3m2tk.fsf_-_@gmail.com

Hello,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (31 lines)> Hey,
>
>> OTOH, I might want to cross-build a Novena image from x86_64, or I might
>> want to build it natively.  Perhaps what could be said is that a Novena
>> image can either be built natively on armhf-linux, or cross-built to
>> arm-linux-gnueabihf.  Perhaps we should encode this constraint rather
>> than a specific ‘system’ or ‘target’?  (I’m thinking out loud…)
>
> Maybe the next step would be to define a <machine> record that encodes
> the "system" and "target" constraints for a specific board/machine. The
> kernel build options and userland packages options you are mentioning
> above could also be part of this record.
>
> As Danny is proposing, we could also have a "--native" argument to "guix
> system" that would force native build instead of cross-compiling.
>
>> Regarding ARM boards, do you think some additional abstraction is needed
>> to encode cross-cutting concerns that affect not just the partition
>> layout and choice of a bootloader, but also kernel build options, and
>> maybe options for some userland packages (are there examples of that,
>> though?)?
>>
>> Maybe the best course of action is to add all this info to <image> until
>> we have a better idea, after all.
>
> Sure, I agree.
>
>> I guess I’m contributing more questions that answers.  :-)
>
> It helps a lot anyway :)

I see this hasn't landed to the repo yet. Are you still refining it, or

has it fallen into cracks?

Just checking :-).

Thank you,

Maxim

Mathieu Othacehe wrote on 30 Aug 2021 18:24

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87czpuaojo.fsf_-_@gnu.org

Hey,

Here's a patchset based on Ludo suggestion of introduction a platform

record. It is for now limited to system, target, and linux-architecture

fields but we could extend it to add the kernel, gcc, ... fields when

needed.

WDYT?

Thanks,

Mathieu

Attachment: 0001-gnu-Add-platform-support.patch

Attachment: 0002-image-Add-platform-field.patch

Mathieu Othacehe wrote on 5 Oct 2021 10:26

Recipients:(address . 45020@debbugs.gnu.org)

Message-ID:87mtnnev2g.fsf_-_@gnu.org

Hey,

Toggle quote (5 lines)

> * gnu/platform.scm: New file.

> * gnu/platforms/arm.scm: Ditto.

> * gnu/platforms/hurd.scm: Ditto.

> * gnu/local.mk (GNU_SYSTEM_MODULES): Add them.

I plan to push that one in the next few days.

Thanks,

Mathieu

Mathieu Othacehe wrote on 11 Oct 2021 14:06

Recipients:(address . 45020-done@debbugs.gnu.org)

Message-ID:87sfx722bm.fsf_-_@gnu.org

Hey,

Toggle quote (2 lines)

> I plan to push that one in the next few days.

Pushed, thanks,

Mathieu

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 45020@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 45020

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date