netdev
[Top] [All Lists]

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for

To: bogdan.costescu@xxxxxxxxxxxxxxxxxxxxx (Bogdan Costescu)
Subject: Re: [PATCH] support for Cobalt Networks (x86 only) systems (for
From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 2 Jun 2001 17:15:02 +0100 (BST)
Cc: alan@xxxxxxxxxxxxxxxxxxx (Alan Cox), mark@xxxxxxxxxxxxxxxx (Mark Frazer), jgarzik@xxxxxxxxxxxxxxxx (Jeff Garzik), zaitcev@xxxxxxxxxx (Pete Zaitcev), linux-kernel@xxxxxxxxxxxxxxx (Linux Kernel Mailing List), netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.33.0106021007290.22222-100000@kenzo.iwr.uni-heidelberg.de> from "Bogdan Costescu" at Jun 02, 2001 10:20:26 AM
Sender: owner-netdev@xxxxxxxxxxx
> > 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!

How does that solve the problem ?

> > 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 ?

The mtime tells you exactly that.

> 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

I disagree. A non priviledged app should not be able to poke around in MII
registers anyway. So you only have to cache the generic state of the link.

> each MII register access. Another solution is to have each register start
> its own cache timer.

You don't need timers.

> 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.

You don't need any timers if you are caching. Zilch nada none. You know the
last time a query came in. The mtime lets the app know the last time the value
was modified.

Alan



<Prev in Thread] Current Thread [Next in Thread>