Re: GuixSD bootable ISO-9669 image

[Ludovic Courtès]

Hi,

Danny Milosavljevic <address@hidden> skribis:

>>I’d prefer to add a special ‘iso-9660-uuid’ form similar to ‘uuid’ in (gnu 
>>system file-systems).
>> That way we could detect that we get a valid UUID at macro-expansion
>> time or system-instantiation time, rather than end up with an error at
>> boot time.
>
> Hmm, I've never seen that macro before.  Should it be used in config.scm ?

Yes, see <https://gnu.org/software/guix/manual/html_node/File-Systems.html>.

> Right now config.scm could have:
>
>   (file-systems (cons* (file-system
>                         (device "1234-5678-....")
                                  ^^
This is wrong, should be (uuid "1234-…").

> Which kind of UUID is it then?  Should string->uuid try to be clever about 
> it?  Or a new function string->uuid-like ?

‘uuid’ and ‘string->uuid’ are for DCE UUIDs, see (gnu build
file-systems).  I think it should remain this way: ‘string->uuid’
shouldn’t try to guess what kind of UUID it’s given; doing that could
lead to hard-to-debug problems.

> find-partition-by-uuid right now uses read-partition-uuid and then uses 
> bytevector=?.

Right, file system UUIDs are represented as bytevectors internally in
(gnu build file-systems).

> So all these forms should continue to be bytevectors.  Then it would work 
> fine without lots of changes.
>
> So something like this?
>
> - Add "string->uuid-like" and use it in canonical-title (instead of using 
> "string->uuid").
> - string->uuid-like would have a case analysis by some weird markers, then 
> parse the uuid using the right parser into a bytevector with length 
> typical-for-this-filesystem-but-not-unique.
> - Modify uuid->string to have a case analysis by the bytevector length, then 
> print the uuid using the right printer into a string 
> typical-for-this-filesystem.  This will fail to detect ISO9660 correctly 
> because these are the same length as real uuids (Linux uses 16 bytes of the 
> 17-byte iso9660-uuid)
> - Leave the uuid macro as-is since it should already do the right thing then?
> - Add a new macro fat32-uuid, and a new macro iso9660-uuid.

I don’t like the idea of a polymorphical ‘string->uuid-like’.  I would
prefer to have:

  fat32-uuid->string (already exists)
  string->fat32-uuid
  fat32-uuid macro

  iso9660-uuid->string
  string->iso9660-uuid
  iso9660-uuid macro

Then users should pick the right one, usually the macro, and get an
error when they pass an invalid UUID.

WDYT?

Thanks,
Ludo’.