On 2017/4/7 上午2:14, Jes Sorensen wrote: > On 04/06/2017 02:10 PM, Coly Li wrote: >> On 2017/4/6 下午11:31, Jes Sorensen wrote: >>> Neil, >>> >>> I see, thanks for explaining. >>> >>> The goal is to eventually get out of the ioctl() business and get to a >>> state where we can do everything via sysfs/configfs. Right now we have a >>> big mix between ioctl and sysfs where neither interface does everything. >>> The recent issues with PPL (I think it was) showed that we had to add >>> more ioctl support because the interfaces needed to do it for sysfs >>> weren't quite there. My long term goal is to get that situation improved >>> so we can avoid adding anymore ioctl interfaces and eventually allow for >>> distros to build mdadm with ioctl support disabled. We had a discussion >>> at LSF/MM in Boston about this (Hannes, Shaohua, Song, and myself). >>> >>> Reading the code I found it confusing that it was so tied to the patch >>> level, but didn't do anything with the version numbers. At least >>> intuitively if I bumped the version number, I would reset the patchlevel >>> which would break things. >>> >>> I think it's fair to draw a line in the sand and say that mdadm-4.1+ >>> will not support kernels older than 2.6.15. I am open to the kernel >>> version we pick here, but I would like to start deprecating some of the >>> really old code. I have patches that does this in my tree, but I need to >>> add a check for kernel version > 2.6.15. I am not aware what SuSE's >>> enterprise kernel versions look like, but checking RHEL/CentOS RHEL5 was >>> 2.6.18, while RHEL4 was 2.6.9 - and RHEL4 has been unsupported for quite >>> a while. At least for RHEL/CentOS 2.6.15 as the line in the sand seems >>> fine. >>> >>> For the kernel to expose features to userland in the future, I would >>> prefer to go with a feature-flag style interface exposed via sysfs. That >>> way a distro could enable one feature, but not the other in their kernel >>> without having to worry about actual version numbers. >> >> BTW, I'd like to take on the kernel side stuffs. >> IMHO, it would be better that we also set a timeline, after the >> timeline, we should add new interface via configfs, and keep all legancy >> ioctl implementation before this timeline. >> >> Coly > > A volunteer! A volunteer! > > I don't think we need to set a firm timeline for removing code from the > kernel at this point. What we can do is implement the new interfaces via > sysfs/configfs, and then make ioctl support a config option. Down the > line it will be evident if/when we can rip out the old code, but I see > that being years away. Not removing code, just after a timeline, new patch which adding new interface should go into configfs. I start to look into this now, hope to compose a first version patch set for comments in not too long time. Coly -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
