Hi Ludo,
>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 ?
Right now config.scm could have:
(file-systems (cons* (file-system
(device "1234-5678-....")
(title 'uuid)
(mount-point "/")
(type "ext4")
(needed-for-boot? #t))
Which kind of UUID is it then? Should string->uuid try to be clever about it?
Or a new function string->uuid-like ?
find-partition-by-uuid right now uses read-partition-uuid and then uses
bytevector=?.
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.
String lengths:
- FAT32 UUID-string: 3 Byte to 9 Byte (variable-length numerals. Is that
actually how Linux writes them? I misplaced my USB stick... where is it?
*mumbles*)
- ISO9660 UUID-string: 16 Byte (fixed-length numerals). That's the same length
as the ISO9660 bytevector since it's actually the same content
- Real UUID-string: 36 Byte
Bytevector lengths (right now):
- FAT32 UUID: 4 Byte
- ISO9660 UUID: 16 Byte (oops...)
- Real UUID: 16 Byte
