Hi > [Greg KH <greg@xxxxxxxxx>] > > > but I don't think driver/staging is good place for non driver code. > > > The problem is, any patch must be reviewed by stakeholder, not maintenar only. > > > then, the patch should post lkml and subsystem mailing list at first. > > > > > > I like reviewed code than unreviewed code. > > > > Heh, so do I. > > > > And this is an odd "driver", I do know that. > > > > But it solves a real problem that can't be solved any other way > > currently, which is needed for a real system that is shipping. So, if > > it can't be solved any other way, do you have a way this kind of thing > > could be more "correct"? I agree this patch address correct requirement. > I think a lot of the confusion here comes from Arve's earlier (very > terse) remark: "I never expected it to be merged. I wrote it to allow > us to ship a product." > > At the risk of putting words in his mouth, I believe this should be > parsed as "we wrote this to solve problems necessary to ship products > and did not expect it to be merged to mainline as-is". ok. I believe you. I also hope that I'm working with various background guys. thanks. > We'd love to get support for low memory process killing that works for > our app model into the mainline. > > If that's by reworking this driver > until it's acceptable or by implementing the same functionality a > different way, making use of some other subsystem, or whatever, we're > not particularly picky. Our goal is, eventually, to maintain as few > patches outside of the kernel as possible so things can build "out of > the box." -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
