On Tue, Oct 22, 2013 at 11:19:30AM -0700, Bin Gao wrote: > On Tue, Oct 22, 2013 at 06:44:06AM +0100, Greg Kroah-Hartman wrote: > > So, just because userspace is "hard" you want to add stuff to the kernel > > instead. > > > Well, there are other reasons - "hard" is just one of them. > For instance, on some platforms with runtime pm enabled, access to registers > of a device which is in low power state will cause problems(syste reboot, > etc.). > You can only wake it up to running state by runtime API from kernel space.
Then write a UIO pci driver, that should work, right? > > Sorry, but for over the past decade, we have been doing just the > > opposite, if things can be done in userspace, then they should be done > > there. So for us to go in the opposite direction, like these patches > > show, would be a major change. > > > Agree, but as mentioned above, for some situation we can't do it from > user space. > > > You can already do this today for PCI with the UIO framework, right? > > Why duplicate that functionality here with another userapce API that we > > will then have to maintain for the next 40+ years? > > > No, UIO is not appropriate for my requirement. I don't know what your "requirements" are. > The thing I need is to dump any registers just by 2 simple commands. I find it hard to believe that your "requirement" dictates the exact method of _how_ you get access to this hardware. > > Have you run these proposed changes by any of the Intel kernel > > developers? What did they say to them? > > > > If not, why haven't you, isn't that a resource you should be using for > > things like this? > > > Why you had these strange questions? It's something I ask any Intel developer who sends odd patches that have obviously not been reviewed by Intel's kernel developers. They are a resource you should be using to tell you these types of things, don't make me, a community member, tell you this. > Over years, we have been maintaining and using these drivers internally > for various purpose across our group for SoC pre-silicon and post-silicon > degugging, e.g. IOAPIC RTE dumping, GPIO tunning, raw device degugging > without a driver(i2c, spi, uart), etc., etc., ... > Trying to push some existed codes upstream is not a bad thing. Trying to push code that is incorrect is a bad thing. Just because it has been living in a private tree for X number of years is not an excuse, because you are now asking me and others to maintain this API you have created (which is undocumented) for the next 40+ years. Again, use the interfaces we already have, and if they are not sufficient for whatever reason, help make them better. Don't create whole new ones just because someone 5+ years ago didn't know about them, or that they weren't even present at that time. That's not the community's fault, it's yours. greg k-h -- 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/
