> No the application gets back no data, ever, because a third party application
> keeps beating it. You don't even need maliciousness for this, synchronization
> effects and locking on the file will ensure it gets you in the end
Sure, but as I already wrote, you can detect that something is wrong. Then
shoot the person!
> > With caching, you'd have to let the application know when the cached
> > value was last read and how long it will be cached for. With rate
>
> fstat() mtime. That seems easy enough
This only answered the first part of the question: when. How do you pass
the "how long" info ?
Does the same applies for the MII ioctl case ?
Now let's talk about implementation issues. For the MII case, you have
several registers that have to be read. The way it generally done is for
the ioctl to pass MII address and register number and receive back the
value.
Caching means that the driver (I don't think that it can be done at
higher levels) has to keep track of accesses to all MII interfaces (yes,
there can be more than one on a NIC) and all of their registers. One
solution is to read all registers at once and start the cache timer for
each MII register access. Another solution is to have each register start
its own cache timer.
OTOH, ioctl rate limiting can be done at higher level and you need only
one timer per netdevice. So, it's done once and all net drivers benefit
from it.
Guess which one I prefer...
-- Bogdan CostescuIWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/