On 15/03/18 06:21, Andreas Dilger wrote: > On Mar 14, 2018, at 11:21 AM, Boaz Harrosh <boazh@xxxxxxxxxx> wrote: >> >> On 13/03/18 22:16, Andreas Dilger wrote: >> <> >>>> + */ >>>> +#define ZUFS_MINORS_PER_MAJOR 1024 >>>> +#define ZUFS_MAJOR_VERSION 1 >>>> +#define ZUFS_MINOR_VERSION 0 >>> >>> I haven't really been following this development, but my recommendation >>> would be to use feature flags (e.g. at least __u64 compat, __u64 incompat) >>> for the API and separately for the disk format, rather than using version >>> numbers. This makes it clear what "version" relates to a specific feature, >>> and also allows *removal* of features if they turn out to be a bad idea. >>> With version numbers you can only ever *add* features, and have to keep >>> support for every old feature added. >>> >>> Also, having separate feature flags allows independent development of new >>> features, and doesn't require that feature X has to be in version N or it >>> will break for anyone using/testing that feature outside of the main tree. >>> >>> This has worked for 25 years for ext2/3/4 and 15 years for Lustre. ZFS >>> has a slightly more complex feature flags, distinguishing between features >>> that _could_ be used (i.e. enabled at format time or by the administrator), >>> and features that _are_ used (with a refcount). That avoids gratuitous >>> incompatibility if some feature is enabled, but not actually used (e.g. >>> ext4 files over 2TB), and also allows removing that incompatibility if the >>> feature is no longer used (e.g. all > 2TB files are deleted). >>> >> >> Yes thank you. As you can see at this RFC stage I have not even put any >> code to enforce the ABI/API versioning yet. Exactly because I don't like >> it as you explained. I will think about your suggestion and see. This is >> not on disk stuff. This is more the communication channel between >> ZUF<=>ZUS. Though there are a couple on disk stuff. >> (The on disk things are all hidden from here inside the usermode FS plugin) >> >> The thing is that I want to work a system with the distro's that the >> ZUF<=>ZUS ABI can freely change, by forcing the zusd package be dependent >> on the kernel package. And it be signed by the Kernel's make key. Meaning >> it will only run against the kernel it was compiled against. > > That is a major pain, and even the distros are doing things like weak module > symbol versions so that external kernel modules do not need to be rebuilt > for every minor kernel update. > OK I get it. So yes let me think about it. we have two structures and then all these IOCTL definitions. For the two structures: struct multi_device and struct zus_inode we can have the above version as an indicator of compatibility, And with the IOCTLs each time any structure change we can define a new IOCTL constant and/or operation number. Or put the sizeof at the header. I'll see what's simple enough to do Boaz >> And keep the stable ABI with feature and versioning between the >> ZUSD<=>zusFS-plugin(s) >> We'll have to see >> >> Thanks >> Boaz > > Cheers, Andreas > > > > >
