Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 06:22:56AM -0700, Matthew Wilcox wrote: > Perhaps you should try being less of an arsehole if you don't want to > get yelled at? I don't mind when you're an arsehole towards me, but I > do mind when you're an arsehole towards newcomers. How are we supposed > to attract and retain new maintainers when you're so rude? *plonk* The only one I'm seeing being extremely rude here is you. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 03:03:09PM +0200, Christoph Hellwig wrote: > On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote: > > On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote: > > > this series tries to actually turn vm_fault_t into a type that can be > > > typechecked and checks the fallout instead of sprinkling random > > > annotations without context. > > > > Yes, why should we have small tasks that newcomers can do when the mighty > > Christoph Hellwig can swoop in and take over from them? Seriously, > > can't your talents find a better use than this? > > I've spent less time on this than trying to argue to you and Souptick > that these changes are only to get ignored and yelled at as an > "asshole maintainer". So yes, I could have done more productive things > if you hadn't forced this escalation. Perhaps you should try being less of an arsehole if you don't want to get yelled at? I don't mind when you're an arsehole towards me, but I do mind when you're an arsehole towards newcomers. How are we supposed to attract and retain new maintainers when you're so rude? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote: > On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote: > > this series tries to actually turn vm_fault_t into a type that can be > > typechecked and checks the fallout instead of sprinkling random > > annotations without context. > > Yes, why should we have small tasks that newcomers can do when the mighty > Christoph Hellwig can swoop in and take over from them? Seriously, > can't your talents find a better use than this? I've spent less time on this than trying to argue to you and Souptick that these changes are only to get ignored and yelled at as an "asshole maintainer". So yes, I could have done more productive things if you hadn't forced this escalation. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote: > this series tries to actually turn vm_fault_t into a type that can be > typechecked and checks the fallout instead of sprinkling random > annotations without context. Yes, why should we have small tasks that newcomers can do when the mighty Christoph Hellwig can swoop in and take over from them? Seriously, can't your talents find a better use than this? > The first one fixes a real bug in orangefs, the second and third fix > mismatched existing vm_fault_t annotations on the same function, the > fourth removes an unused export that was in the chain. The remainder > until the last one do some not quite trivial conversions, and the last > one does the trivial mass annotation and flips vm_fault_t to a __bitwise > unsigned int - the unsigned means we also get plain compiler type > checking for the new ->fault signature even without sparse. Yes, that was (part of) the eventual goal. Well done. Would you like a biscuit? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
vm_fault_t conversion, for real
Hi all, this series tries to actually turn vm_fault_t into a type that can be typechecked and checks the fallout instead of sprinkling random annotations without context. The first one fixes a real bug in orangefs, the second and third fix mismatched existing vm_fault_t annotations on the same function, the fourth removes an unused export that was in the chain. The remainder until the last one do some not quite trivial conversions, and the last one does the trivial mass annotation and flips vm_fault_t to a __bitwise unsigned int - the unsigned means we also get plain compiler type checking for the new ->fault signature even without sparse. This has survived an x86 allyesconfig build, and got a SUCCESS from the buildbot that I don't really trust - I'm pretty sure there are bits and pieces hiding in other architectures that it hasn't caught up to. The sparse annotations are manuall verified for the core MM code and a few other interesting bits (e.g. DAX and the x86 fault code) The series is against linux-next as of 2018/05/15 to make sure any annotations in subsystem trees are picked up. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
