bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ioperm and pseudo devices


From: Marcus Brinkmann
Subject: Re: ioperm and pseudo devices
Date: Wed, 20 Nov 2002 01:29:00 +0100
User-agent: Mutt/1.4i

On Tue, Nov 19, 2002 at 07:17:12PM -0500, Roland McGrath wrote:
> > I think we need a flag in the device structure to mark the type of the
> > device more properly than the device ops does.  In particular, I am worried
> > about someone sending an io perm modify IPC to a non-io perm device port, it
> > doesn't look to me as if I coded any guard against this into it.
> 
> That RPC goes to the task.  You are talking about its argument.
> convert_io_perm_to_port needs to check that it's really an io_perm port.

Yup, sorry.  I shouldn't do this stuff when I am tired.
 
> As it happens, I don't think that any other device uses no_device_ops (I
> don't recall what it was there for in the first place).  So you could use
> ops==&no_device_ops as the test.  Or to avoid the presumption you could
> just make your own all-zeros io_perm_device_ops so that the address would
> be unique.

Yeah, I was thinking of that.  In fact, the reason I became aware of that is
that I wanted to use another pseudo device with no ops for the proxy memory
objects (but for those I need a close function, so I made my own device ops
structure).  I know that this is lame, as one reason against a new kernel
object type for iopb was that it is machine-specific, and I don't have this
argument here.

> It seems to me we might actually want a device_ops anyway, to have close.
> Then io_perm.c could use the oskit interfaces for the global io bitmap,
> to disallow an io_perm range that overlaps with a kernel driver.

Hu, never heard about that.  Sounds like a good idea.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]