On 04/06/2017 02:10 PM, Coly Li wrote:

On 2017/4/6 下午11:31, Jes Sorensen wrote:

quoted

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.

Cheers,
Jes