[PATCH] 2.6 PPC64: Reduce rtas spamming

[Dave Hansen]

On Thu, 2004-07-22 at 12:12, Paul Mackerras wrote:
> First, we won't remove any /proc files from 2.6 that are being used by
> applications.  That's a job for 2.7.  (I think we could remove things
> like /proc/ppc64/rtas/poweron though.)

What about the new kernel development model? ;)

> Secondly, we can discuss the rmo_buffer thing if you like, but I'll be
> surprised if you can come up with something that doesn't involve
> unnecessarily duplicating code.  The users of rmo_buffer absolutely
> need to know the physical address of the rmo_buffer memory.  Given
> that, I don't see any good reason for making a device with an mmap
> method for mapping the rmo_buffer memory into userspace when we
> already have a perfectly good device which we can use for that
> purpose, namely /dev/mem.
>
> In other words, you'll need to produce a more sophisticated technical
> argument than just "/dev/mem? ugh..".  8-)

The argument against /dev/mem is pretty simple: it's a bit too big of a
hammer.  Using it will force you to either run as root, or allow a
non-root user/group to write to it, which is an equivalent of giving
them root.

If it were another device, you can give selected users access to it, and
the worst they can do is corrupt RTAS calls (which may be a root
equivalent too, I imagine).

A suggestion would be to use the current ppc_rtas to get that
information back out.  Could there be some special args passed to the
syscall that give you the address of the buffer?

Something conceptually along the lines of:

        if (uargs->token == SPECIAL_TOKEN) {
        	uargs->rets = phys_to_virt(&rtas_rmo_buf);
        	return foo;
        }

So, from userspace and librtas, you just see it as a normal ppc_rtas
call with a token that isn't defined by the hardware spec.

This has the advantage of isolating all of the rtas code to a slightly
more restricted area.  It also makes it more explicit to someone reading
the code that the same users of ppc_rtas also want to know the physical
address of the rtas_rmo_buf.

-- Dave

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/