guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GuixSD bootable ISO-9669 image


From: Ludovic Courtès
Subject: Re: GuixSD bootable ISO-9669 image
Date: Tue, 16 May 2017 10:31:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hi Danny,

Danny Milosavljevic <address@hidden> skribis:

> On Fri, 12 May 2017 17:33:21 +0200
> address@hidden (Ludovic Courtès) wrote:
>> Then users should pick the right one, usually the macro, and get an
>> error when they pass an invalid UUID.
>
> Note that the directory /dev/disk/by-uuid doesn't contain any marker about 
> what kind of uuid it is. So it would make things complicated for the user.
>
> I wouldn't expect anyone that isn't a programmer to know that fat32 uuids are 
> different from btrfs uuids.
>
> If we have different uuid macros, we should have *-uuid macros for *every* 
> possible filesystem type, whether the uuids differ or not - at least then 
> there's a pattern for the user to learn.  Not like 3 macros and 14 filesystem 
> types so you'd have to have a mapping function in your head.
>
> But really, I myself use uuids only for file-system entries to be bus 
> independent so I can plug known disks on whatever slot I want and they'll be 
> mounted at the same place regardless.  I guess another use case is for the 
> Guix LiveCD to find itself - for the same reason.  Not sure what the 
> complication of bytevectors, multiple macros etcetc buys us.  The user is 
> probably copy&pasting the uuid from /dev/disk/by-uuid anyway.  It's not like 
> you type in uuids (ever).

The user interface (the ‘uuid’ macro for instance) and the internal
representation (bytevectors) are two different things.

The internal representation is fine, we don’t want to represent
something that’s literally a “byte vector” as a Unicode string, and have
parsing errors that could happen anywhere.

As for the user interface, I get your point.  We certainly don’t want to
make the user’s life unnecessarily difficult.

Honestly, I was under the assumptions that DCE UUIDs was all that
mattered: it works for ext2 and btrfs, right?  I would think that people
would rarely add FAT32 or ISO9660 UUIDs to the OS config.  That’s why I
though that having a separate macro for these two “special UUID types”
is okay.

What the macro buys us is expansion-time or system-instantiation-time
checks.  When someone uses /dev/disk/by-uuid/something-obviously-wrong
on another GNU/Linux system, they don’t get an error until they try to
boot the thing.  Here we have an opportunity to do that check before the
system is instantiated.

WDYT?

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]