[Prev][Next][Index][Thread]
Re: osenv_mem_alloc and stuff...
> while reading the oskit.ps, the paper on OSKit 0.96, some things come to =
> my attention, maybe I am ignorant, if so, please excuse me: blocking =
I'm glad you're reading it!
> memory allocation --- isn't it enough to implement a lock acquire in the =
> beginning of the code, so that if it is reentered, it will wait on the =
> lock? or test if("lock acquired?" && non-blocking) return error, null =
One problem is that there is no "lock" in the osenv API. However, this
could be done by the OS hosting the drivers. If the driver blocks on the
lock, what happens? The API defines it to be blocking, meaning that
the driver set may be reentered by another context. However, it is
possible to spin on the lock, or to yield to another thread that is
not dealing with osenv.
non-blocking is required when the driver may not be re-entered -- such
as when it is called from an interrupt handler. [Note that the drivers
will not function "optimally" if it always fails -- incomming packets
will get dropped, for example.]
I should note that the drivers that we have released have not been
extensivly tested with blocking operations -- we haven't tested
with osenv_mem_alloc blocking, as well as other "blocking" operations.
Leigh has found a few problems with component blocking when he was
playing the pthreads in the OSKit. One thing that could happen is
that a component calls into another component which blocked, but the
first component wasn't prepared to be reentered. I believe Leigh has
added some work-arounds for a few of the problems, but it has not
been dealt with correctly yet (although we are planning on doing so).
> (or whatever)? Isn't it better to have some sort of linked list, holding =
> all the memory buffers allocated? Thus the OS will be able to ignore the =
> OSENV_AUTO_SIZE flag and will disable the opportunity a buggy driver to =
> report more or less memory than actually allocated? It may be hard to =
> keep track of all the memory blocks (problems with allocation of memory =
> for the linked list arise), but still this makes the OS less dependant =
> on drivers' correctness.
Linked lists are bad; they don't scale at all. Note that the memory
allocations are actually being done by the glue code, which provides
a wrapper for the driver's native memory allocation interface.
OSENV_AUTO_SIZE is used to allow malloc(or kalloc) fall through without
additional processing; the OS can certainly always track the size even
when the flag is not set, and report an error if the size is wrong.
> As to some questions, stated in the draft as to memory functions: =
> osenv_mem_get_phys(...) -- better to supply the exact pointer of the =
> memory block, since this will constitute a linear search of all the =
> memory blocks, else the OS will have an overhead to calculate to which =
> memory block this pointer belongs, even if the pointer was an exact =
> start of a memory block (as returned from osenv_mem_alloc), there would =
> be still an overhead...
Well, that would be nice. Unfortunatly, the problem is that there
is no way to do that with the encapsulated drivers.
But all you need to track is the page mapping -- if it is in the same
virtual page, it will have the same physical page.
Note that some of the drivers call that routine on memory they did not
allocate -- a common case is using it on the data segment containing
SCSI scripts to pass to the scsi command processor. There is no "fix"
other than modifying the drivers to copy the scripts to allocated memory.
> Interrupts: as I understand it, osenv_intr_disable() is called by a =
> driver set, to "...disable further entry in the calling driver set =
> through an interrupt handler..." Isn't it better, instead of disabling =
> _all_ the interrupts (CLI or whatever), to disable the interrupt that =
> the driver services by masking it in the PIC register (x86)? this way =
> other drivers will go on working and since driver sets are by default =
> disjoint, that is have nothing common, this won't affect other driver =
> sets. (disabling interrupts can be done in a software level by rasing a =
> flag that the interrput handler examines at its start...) i.e. just use =
> a single/multiple calls to osenv_irq_disable(...) ?
Well, driver sets in the oskit currently are not as disjoint as we would
like. It is also important to note that munging the PIC is much slower
than twidling the processor's interrupt enable flag.
However, if you wish to use the osenv drivers, you are certainly free
to implement the API in this manner. For my MS thesis, I run the
device drivers in separate address spaces in user mode, and I deal with
interrupts using a mutex rather than using the processor flag at all.
> I'd be more than glad to get comments...
>
> FtpDaemon
Hope this helps a little.
Kevin Van Maren
University of Utah, CSL