[ As this is becoming more and more MII specific, I changed the subject ]
On Sat, 2 Jun 2001, Alan Cox wrote:
> > 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
On Fri, 1 Jun 2001, Bogdan Costescu wrote:
> On Fri, 1 Jun 2001, jamal wrote:
>
> > One idea i have been toying with is to maintain hysteris or threshold of
> > some form in dev_watchdog;
>
> AFAIK, dev_watchdog is right now used only for Tx (if I'm wrong, please
> correct me!). So how do you s
Pete Zaitcev wrote:
> > i2c is only in our stuff because the i2c core is not in the standard kernel
> > yet. As soon as it is, I will make cobalt_i2c* go away.
>
> I am puzzled by this comment. Did you look into drivers/i2c/?
> It certainly is a part of a stock kernel. The main user is
> the V4
[ OK, this time I cc'ed netdev 8-) ]
On Fri, 1 Jun 2001, Alan Cox wrote:
> Please re-read your comment. Then think about it. Then tell me how rate
> limiting differs from caching to the application.
For caching, the kernel establishes the rate with which the info is
updated. There's nothing wr
Alan Cox <[EMAIL PROTECTED]> [01/06/01 10:32]:
> > No way! If I implement a HA application which depends on link status, I
> > want the info to be accurate, I don't want to know that 30 seconds ago I
> > had good link.
> >
> > IMHO, rate limiting is the only solution.
>
> Please re-read your com
> I'd argue for rate limiting as the application only gets back new data,
> never a cached value n times in a row.
Which is worse. I cat the proc file a few times and your HA app is unlucky. It
now gets *NO* data for five minutes. If we cache the values it gets approximate
data
-
To unsubscribe
On Fri, 1 Jun 2001, jamal wrote:
> Jeff, Thanks for copying netdev. Wish more people would do that.
Shame on me, I should have thought of that too... I joined lkml only about
2 weeks ago because netdev related topics are sometimes discussed only
there...
> Not really.
>
> One idea i have been t
> No way! If I implement a HA application which depends on link status, I
> want the info to be accurate, I don't want to know that 30 seconds ago I
> had good link.
>
> IMHO, rate limiting is the only solution.
Please re-read your comment. Then think about it. Then tell me how rate limiting
dif
Jeff, Thanks for copying netdev. Wish more people would do that.
On Fri, 1 Jun 2001, Bogdan Costescu wrote:
> On Fri, 1 Jun 2001, Jeff Garzik wrote:
>
> > The loss and regain of link status should be proactively signalled to
> > userspace using netlink or something similar.
>
> [ For the genera
On Fri, 1 Jun 2001, David S. Miller wrote:
> Don't such HA apps need to run as root anyways?
Not necessarily, but eventually you can let root (CAP_NET_ADMIN, anyway)
go through without any limitations, root can bring down the system at will
in other ways.
In addition, the rate limiting solution
On Fri, 1 Jun 2001, Jeff Garzik wrote:
> The loss and regain of link status should be proactively signalled to
> userspace using netlink or something similar.
[ For the general discussion ]
I fully agree, but I just wanted to give an example of legit use from
user space of _current_ values from
Jeff Garzik writes:
> For your HA application specifically, right now, I would suggest making
> sure your net driver calls netif_carrier_xxx correctly, then checking
> for IFF_RUNNING interface flag. IFF_RUNNING will disappear if the
> interface is up, but there is no carrier [as according t
Bogdan Costescu wrote:
> No way! If I implement a HA application which depends on link status, I
> want the info to be accurate, I don't want to know that 30 seconds ago I
> had good link.
To tangent a little bit, and add netdev to the CC...
The loss and regain of link status should be proactive
On Fri, 1 Jun 2001, Alan Cox wrote:
> I am sure that to an unpriviledged application reporting back the same result
> as we saw last time we asked the hardware unless it is over 30 seconds old
> will work fine. Maybe 10 for link partner ?
No way! If I implement a HA application which depends on
> Only some of them can be cached... (some of the MIIs in some drivers
> are already cached, in fact) you can't cache stuff like what your link
> partner is advertising at the moment, or what your battery status is at
> the moment.
I am sure that to an unpriviledged application reporting back
Alan Cox wrote:
> > In both of these situations, calling the ioctls without priveleges is
> > quite useful, so maybe rate-limiting for ioctls and proc files like this
> > would be a good idea in general.
> Many of them (like the MII and APM ones) the result can be cached
Only some of them can be
> In both of these situations, calling the ioctls without priveleges is
> quite useful, so maybe rate-limiting for ioctls and proc files like this
> would be a good idea in general.
Many of them (like the MII and APM ones) the result can be cached
-
To unsubscribe from this list: send the line "
Bogdan Costescu wrote:
>
> On Fri, 1 Jun 2001, Pete Zaitcev wrote:
>
> > > But, each time a user cats this proc file, the user is banging the
> > > hardware. What happens when a malicious user forks off 100 processes to
> > > continually cat this file? :)
> >
> > Nothing good, probably. Same s
On Fri, 1 Jun 2001, Pete Zaitcev wrote:
> > But, each time a user cats this proc file, the user is banging the
> > hardware. What happens when a malicious user forks off 100 processes to
> > continually cat this file? :)
>
> Nothing good, probably. Same story as /proc/apm, which only
> hits BIO
> But, each time a user cats this proc file, the user is banging the
> hardware. What happens when a malicious user forks off 100 processes to
> continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
> S
> + /* setup osb4 i/o regions */
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
> + request_region(reg, 4, "OSB4 (pm1a_evt_blk)");
Check request_region worked
> +static int
> +i2c_wait_for_smi(void)
Obvious question - why duplicate t
> From: Tim Hockin <[EMAIL PROTECTED]>
> Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
> > i2c framework is not used, I wonder why. Someone thought that
> > it was too heavy perhaps? If so, I disagree.
>
> i2c is only in our stuff because the i2c core is not in the standard kernel
> yet. As soon
Tim Hockin wrote:
> +int __init
> +cobalt_acpi_init(void)
> +{
> + int err, reg;
> + u16 addr;
> + unsigned long flags;
> +
> + if (cobt_is_5k()) {
> + /* setup osb4 i/o regions */
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
>
General comments:
* Code looks really clean. Nice work.
* Use module_init/exit. I know, I know, you heard it before :)
* I dunno if Linus will take it as-is because he has been threatening to
stop taking PCI drives that use old-style PCI init for no good reason.
(he even made me change a drive
> > Off-hand I see old style initialization. Is it right for new driver?
>
> the old-style init is because it is an old driver. I want to do a full-on
> rework, but haven't had the time.
New-style init by itself shouldn't be hard to do, independent of a full
re-work...
> > 2. Spaces and tabs
> Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
> Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
> i2c framework is n
Tim Hockin said once upon a time (Thu, 31 May 2001):
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.
I can
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.
Looks interesting. Seemingly literate use of spinlocks.
Of
apparently, LKML silently (!) bounces messages > a certain size. So I'll
try smaller patches. This is part 2/2 of the general Cobalt support.
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if th
apparently, LKML silently (!) bounces messages > a certain size. So I'll
try smaller patches. This is part 1/2 of the general Cobalt support.
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if th
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
Is not? ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems So
32 matches
Mail list logo
