Hi Christoph, On Mon, Sep 02, 2019 at 08:19:10AM -0700, Christoph Hellwig wrote: > On Mon, Sep 02, 2019 at 10:43:04PM +0800, Gao Xiang wrote: > > Hi Christoph, > > > > ... > > > > 24 __le32 features; /* (aka. feature_compat) */ > > > > ... > > > > 38 __le32 requirements; /* (aka. feature_incompat) */ > > > > ... > > > > 41 }; > > > > > > This is only cosmetic, why not stick to feature_compat and > > > feature_incompat? > > > > Okay, will fix. (however, in my mind, I'm some confused why > > "features" could be incompatible...) > > The feature is incompatible if it requires changes to the driver. > An easy to understand historic example is that ext3 originally did not > have the file types in the directory entry. Adding them means old > file system drivers can not read a file system with this new feature, > so an incompat flag has to be added. Got it. > > > > > > > + memcpy(&sb->s_uuid, layout->uuid, sizeof(layout->uuid)); > > > > > > + memcpy(sbi->volume_name, layout->volume_name, > > > > > > + sizeof(layout->volume_name)); > > > > > > > > > > s_uuid should preferably be a uuid_t (assuming it is a real BE uuid, > > > > > if it is le it should be a guid_t). > > > > > > > > For this case, I have no idea how to deal with... > > > > I have little knowledge about this uuid stuff, so I just copied > > > > from f2fs... (Could be no urgent of this field...) > > > > > > Who fills out this field in the on-disk format and how? > > > > mkfs.erofs, but this field leaves 0 for now. Is that reasonable? > > (using libuuid can generate it easily...) > > If the filed is always zero for now please don't fill it out. If you > decide it is worth adding the uuid eventually please add a compat > feature flag that you have a valid uuid and only fill out the field > if the file system actualy has a valid uuid. Okay. Will do that then (as a note here). Thanks, Gao Xiang _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
