Amir, Am 09.05.2017 um 11:54 schrieb Amir Goldstein: >>> 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? Well, maybe we need a new feature flag in UBIFS that the UUID is now usable. Sure, in the best case we just expose the existing UUID to ->s_uuid and everything is fine. > 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. My POV is easy, I'm nervous about all this changes and the rush behind them. And when Christoph raises concerns, I'm especially careful. That's why I'm taking the UBIFS ->s_uuid patch for 4.13 after I had enough time to verify and think. And finally that's also why I asked Oleksij to follow the discussion. If he can explain in detail why UBIFS does the right thing I have a much better feeling. If I have to figure myself it takes time which I don't have right now. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html