search for: uuid_b

...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 sem...

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

...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 rea...

...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 i...

...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...

...MAL_MAXIMUM_UUID; j++) { - u8 uuid[16]; + uuid_le u; - acpi_str_to_uuid(int3400_thermal_uuids[j], uuid); - if (!strncmp(uuid, objb->buffer.pointer, 16)) { + uuid_le_to_bin(int3400_thermal_uuids[j], &u); + if (!uuid_le_cmp(*(uuid_le *)objb->buffer.pointer), u) { priv->uuid_bitmap |= (1 << j); break; } diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index a15ec71d0423..6b5284ec76df 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -56,7 +56,7 @@ struct dwc3_pci { struct platform_device *dwc3; struct p...