Sorry to have to forward this to the list, but Russell's server just
noticed that I had a open mail relay problem on my end at the end of
August, as a result I cannot send mail directly to him.
----------
Forwarded message ---------- Date: Sat, 16 Jan 1999 22:43:15 -0800 (PST)
From: David Lang <dlang@diginsite.com>
To: Russell Kroll <rkroll@exploits.org>
Subject: Re: AIMS Labs radio card: frequency limit
why have the kernel limit it at all? why not leave that up to the
application frount end?
David Lang
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
On Sat, 16 Jan 1999, Russell Kroll wrote:
> Date: Sat, 16 Jan 1999 12:26:48 -0700 (MST)
> From: Russell Kroll <rkroll@exploits.org>
> To: dlang@diginsite.com
> Subject: Re: AIMS Labs radio card: frequency limit
>
> > if someone sets these cards out of range what happens? if it is mearly
> > poor or non-existant reception, then let the driver set it to whatever and
> > let the manufacturer worry about the specs, like everything else - if you
> > use it out of spec you are on your own. If actual damage can be done, then
> > we need to have the driver limit the freq.
>
> I've been unable to get the cards to perform a 'halt and catch fire'
> operation despite sending all sorts of crazy data during tests. This
> doesn't mean it's impossible, but bad results seem unlikely. The usual
> result when tuning to an unsupported frequency is static.
>
> The general idea at this point is to code in defaults of 87-108 and allow
> clueful types to override with a module parameter. This way, you can
> sidestep my "known good" values if you know better.
>
Good signature made 1999-01-17 06:43 GMT by key:
2048 bits, Key ID 84A6971B, Created 1997-09-26
"<dlang@diginsite.com>"
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNqGLaj7msCGEppcbAQG5qQgAq/Vo2qSgXw3RynMprYCaRs1ISUdBBVzT
+GFMadMrp4sVJPTN6wmA8I/J2dFOYkZFeRrwFJsQ04s3ylcI5TlOyzbhMmo2M8ji
HpBY/YS2pfg/yQ51rzJ/GdEF6lPnPRGzItOJGDBgcuPVvRorroaykiFNTmLQP9Rk
7pwfr9E/YMGJhjD515UbTzGpAFjByklq+qVRWSgv74zkJnO1jqv1FV+FWQBO0UYE
tuXbYdD6UcWYcgrk8Dyaji5UV6wtyXy6g5/CaVwRyk3GxbQlDGJjPg72H3V+BvBP
2NQVO6iEvyKqR3y+9DhJU3eFDKcdVBKq4V8u8LYo249LXegKPxEIZg==
=/1db
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/