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
> 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
> 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
19 matches
Mail list logo
