[Crash-utility] Re: Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted

Which also doesn't explain what this turd is for. Note that this statement directly conflicts with your debugging statement you need it switchable, and directly conflicts with the Red Hat crash memory access. So you are trying to support something with a changelog that demonstrates that what you are trying to make configurable is completely broken anyway The functionality provided by STRICT_DEVMEM is the same with it on or off - absolutely *nothing*. You can turn it off at boot time, but if you intend not to use it then it is better (and measurably so with microbenchmark tools) to compile without it. Red Hat doesn't do the two kernels as the maintenance cost exceeds the gain for customers. Note however that compiling it out really does compile it *out* and the overhead is gone totally for the many embedded and other devices that don't use it. It is Red Hat, two words and a trademark (sorry but our legal people insist we remind people who get it wrong). Also I don't actually care what Red Hat ship. The fact Red Hat (or any vendor) ship something doesn't make it a good idea. With your patch I get crap in the kernel I don't need. In every kernel including those on memory tight devices like wireless routers that don't need it. You are turd polishing, and what is needed is a shovel. Even if you want to turd polish there are cleaner solutions. A process with CAP_SYS_RAWIO can cheerfully bypass any restriction you try and place so you could rip out all the sysctl crap and just say that the /dev/mem restriction doesn't apply to a CAP_SYS_RAWIO process. It's still a turd but the change is a lot cleaner and one line long with no userspace semantics, paths and the like. There are proper ways to deal with X, modern video cards and modern security models. They involve using framebuffer mappings off the PCI device node itself and DRI. Alan