On Tue, May 9, 2017 at 12:18 PM, Richard Weinberger <richard@xxxxxx> wrote: > Am 09.05.2017 um 11:02 schrieb Christoph Hellwig: >> On Fri, May 05, 2017 at 01:20:11PM +0300, Amir Goldstein wrote: >> >>> There is no reason to wait for the common uuid code to settle down before >>> fixing something as trivial as this and it makes very little sense IMO to use >>> uuid_be_gen() for sb->s_uuid as it is now. >> >> There is. generate_random_uuid needs to die, and adding more callers >> isn't the way to go. That's Christoph's opinion and its fine. I stated my opinion above. It's up to tmpfs/vfs maintainers to make the call about my patch. >>Same for ubifs btw. Same in what regard? ubifs has generate_random_uuid() since 2008. When the cleanup patch to generate_random_uuid() will be ready, it will fixup ubifs as well. > > I agree. Right now UBIFS uses generate_random_uuid() in both kernel and mkfs.ubifs. > Before we expose it to ->s_uuid, UBIFS should use the correct UUID generation functions. Richard, this makes no sense at all. You have deployed filesystems whose UUID has already been set using generate_random_uuid(). You are not going to reformat those filesystems when generate_random_uuid() dies in the kernel, so how is this even related to exporting the filesystem's UUID to s_uuid? The changes that Christoph promotes to the kernel uuid common functions are important because we have too many home brewed implementations of uuid handling in the kernel. But making the code cleaner and more reusable isn't going to change the on-disk uuid representation and for filesystems, it probably won't even change the cpu uuid representation (i.e. in super block structs). Seriously, it's not my battle to fight. I don't stand to loose anything if Oleksij's patch gets held hostage for the uuid cleanups, but I don't get the UBIFS maintainer POV on the matter at hand. Amir.
