On 07.06.19 10:16, Philipp Kern wrote: Hi,
> This would not be the case here. But crippling the performance would be> > indeed an option, even though this would make Debian much less relevant> for ZFS deployments and people would just go and use Ubuntu instead. Is it really necessary to to have some competition w/ Ubuntu on who's got the larger user base ? In which way is that relevant for the progress on Debian ? For me, personally, when working on FOSS, it never mattered how many users are out there - don't need to "sell" anything. > I personally wonder why a kernel which provides a module interface does > not provide a way to save FPU state, but alas, they made their decision. Because that's really low-level, arch specific stuff. I don't even recall any platform driver that ever cares about such things. From a kernel hacker/maintainer pov, the idea of having an arch specific filesystem driver, sounds really weird. This function IIRC just was a workaround for kvm, which always had been suboptimal and was replaced by a better solution. Since nobody used it anymore for quite some time, it got removed. And regarding LTS, I don't recall that Greg ever made any committment on not removing obsolete and used stuff (he's just reluctant of putting too much extra work into that for his lts trees). Of course, as users of kernel-internal APIs, only the in-tree stuff matters - this has always been the policy in Linux development (at least as far as I remember). IIRC the whole things is actually about crypto stuff. Why don't zfs folks just use the standard linux crypto api (potentially introduce a new algo if the existing ones aren't sufficient) ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287