Displaying 6 results from an estimated 6 matches for "uuid_be".
2017 May 05
2
[PATCH v1] ACPI: Switch to use generic UUID API
...atisfy
> the filesystems use case.
>
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
>
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
>
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.
> I think with this sema...
2017 May 05
2
[PATCH v1] ACPI: Switch to use generic UUID API
On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The
2017 May 05
0
[PATCH v1] ACPI: Switch to use generic UUID API
...ing to be posted soon or wasn't going to satisfy
the filesystems use case.
My opinion now, is that your suggestion is probably much closer to the real deal
than mine.
IMO, you should acknowledge that the common use case for filesystems is
to handle an opaque char[16] which most likely holds a uuid_be and you
should provide 'neutral' helpers to satisfy this use case.
The simplest would be to typedef uuid_t to struct uuid_be and to name 'neutral'
helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my proposal.
I think with this semantic change, our proposals can reac...
2017 May 05
1
[PATCH v1] ACPI: Switch to use generic UUID API
...e cases enough to comment on that.
>
> We may go this way. But I wouldn't prevent current users of uuid_le to
> continue using it without conversion (it may be done case by case after
> we settle an API)
>
> So, summarize what Christoph said it will look like
>
> typedef uuid_be uuid_t;
> typedef uuid_le guid_t
>
> uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
> guid_cmp() / guid_copy() / guid_to_bin() / etc
>
> Correct? Christoph?
>
That looks right to me.
To complete the picture for folks not cc'ed on my patches,
xfs use case suggests there is...
2012 Oct 29
5
Re: [PATCH 2/9] uuid: use random32_get_bytes()
...ate,
well, non-unique UUID''s, the results can range anywhere from
confusion, to file system corruption and data loss.
Fortunately, there is only one user of lib/uuid.c, and that''s the
btrfs file system.
Chris and the Btrfs folks --- my recommendation would be to ditch the
use of uuid_be_gen, "git rm lib/uuid.c" with extreme prejudice, and
use generate_random_uuid() which was coded over a decade ago in
drivers/char/random.c. Not only does this properly use the kernel
random number generator, but it also creates a UUID with the correct
format. (It''s not enough t...
2017 May 04
12
[PATCH v1] ACPI: Switch to use generic UUID API
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use uuid_le type. At the same time we
convert current users.
acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.
The conversion fixes a potential bug in int340x_thermal as well since
we have to use memcmp() on binary data.
Cc: Rafael J. Wysocki <rjw