lkml.org 
[lkml]   [1999]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: AIMS Labs radio card: frequency limit (fwd)
    -----BEGIN PGP SIGNED MESSAGE-----

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:0.021 / U:0.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site