On 01/02/17 05:10 AM, Emil Velikov wrote: > You can keep it roughly as-is if you're ~reasonably certain one won't > change it in the future. I've made the change anyway. I think it's better now. > Some teams frown upon adding new IOCTL(s) where existing ones can be > made backward/forward compatible. > I'm not fully aware of the general direction/consensus on the topic, > so it might be a minority. Sure, I just don't know what might be needed in the future so it's hard to add a version or flags ioctl now. > On the other hand, reading through sysfs for module version in order > to use IOCTL A or B sounds quite hacky. Do you have an example where > this is used or pointed out as good approach ? I don't know of anything doing it that way now. But it sure would be easy and make a bit of sense. (We'd actually use the module version for something useful.) Either way, it would really depend on if and how things change in the future. The point is there are options to expand if needed. > Afaict the idea is to not ship/bundle/release userspace until kernel > parts are in. > The "do not commit the changes" is implied as [very rarely] distros > package from "random" git checkouts. Leading to all sorts of fun when > it is mismatched wrt the kernel parts. Likelihood of doing that here > is virtually none here, so this is a JFYI inspired by some past > experiences. Understood. > Glad to hear. Then again you already had most of the things nicely done, imho. Great, thanks. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
