> > It's not really about the lines of code. It adds a new userland > > visible interface. As for the "long" list of commands, it depends on > > how you write it but even if it's textually long it's still very > > simple in terms of actual complexity. > > Sure, but its place is not the kernel. > > As to implementing the ioctl, it's all but trivial. For one thing, you > have to make the block device ioctl op take a "struct file". I have > been asking Al Viro about it for 6 months and I haven't got any answer yet.
Just do it - if Al cared he'd have replied about it. > I proposed a way to implement the ultimately flexible solution (BPF) and > you shot it down because it was too complex. Alan is showing you with > multiple examples of why the flexibility would be useful (perhaps nobody > would use it, but the use cases _are_ there), and you are mostly > ignoring them. My feeling too - It feels to me like Tejun is trying to railroad a broken non-solution into the system without regards for anyone else and by simply dismissing any other input. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
