NeilBrown <neilb@xxxxxxxx> writes: > On Thu, Apr 06 2017, 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). > > Sounds like a good goal, if approached cautiously (and it does sound > like you are showing proper caution). > And I don't think we need the "/configfs" bit. Configfs is just for > people who don't understand sysfs ;-) Glad to hear we're in agreement on this. I definitely want to be cautious about this. While change is good, we have a responsibility towards existing users. This isn't a desktop environment after all :) I am not really tied to sysfs/configfs on this, whoever does that part of the work gets to show us what he/she works best and explain why. >> 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. > > With my SUSE hat on, I'm happy for new mdadm to not support kernels > older than 3.0. Probably even 3.12. I just pushed the first set of changes into git for this. We no longer support kernels older than 2.6.15. If it breaks something else, I am ready to take public blame! If it ends up biting another distro for a slightly older kernel, we can look at fixing that up. >> 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. > > I think there are usually better ways than feature flags. > If the new feature requires a new file in sysfs, then the existence of > the file signals the presence of the feature. That is pretty much how I see feature flags. Next question since I am wearing my 'what is this old stuff doing' hat. mdassemble? Does anything still use this? The reason is a lot of the newer features are explicitly included, and switching to sysfs is effectively going to kill it, unless it gets a major upgrade. Cheers, Jes -- 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
