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.
> 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. The thing I need is to dump any registers just by 2 simple commands. > All of your patches are line-wrapped and totally fail to apply, so even > if we wanted to take this type of changes, I couldn't :( > Sorry for that. I recently upgraded my email client, will fix it next posting. > 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? 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. > 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/
