--nextPart1778744.D6yzTQQHGv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 21 July 2006 05:09, Greg Troxel wrote:
> christos@astron.com (Christos Zoulas) writes:
> > In article <44BFC17A.50307@3am-software.com>,
> >
> > Matt Thomas  <matt@3am-software.com> wrote:
> >>Joanne M Mikkelson wrote:
> >>> +struct usb_bulk_ra_wb_opt {
> >>> +	int	ra_wb_buffer_size;
> >>> +	int	ra_wb_request_size;
> >>> +};
> >>
> >>These should be unsigned.
> >
> > Aside from that, the changes look fine. Is there a reason why we wouldn=
't
> > want to enable them by default all the time?
>
> I can see two reasons not to have these changes compiled in all the
> time:
>
> It's easier to convince oneself that committing the code won't cause
> trouble with the ifdef, which is why I suggested that route to Joanne.
>
> This adds a bit of code to GENERIC.  In general it seems good to be
> able to exclude functionality one doesn't need.
>
> Right now it's only the USRP I know of that can use the changes.  But
> really anything that sends a lot of data over bulk endpoints to user
> space would benefit.

Don't you agree that options that make a kernel device/interface to comply=
=20
more closely to the specifications should be enabled by default? The intend=
ed=20
changes are not to extend but to add missing code making this device more=20
compliant.

My expectation from a user's point of view is that the kernel implements an=
d=20
supports a device/interface compliant to its specifications. This is not th=
e=20
case with the current implementation of the device under review.

cheerio Berndt

--nextPart1778744.D6yzTQQHGv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQBEwK2acUIHpeIRpjERAsRRAJ0cfSa31qUzeandDKKNTEbfaA+R8gCeK/PM
q5/ah1kI/3CrvXna8popRwM=
=c+QZ
-----END PGP SIGNATURE-----

--nextPart1778744.D6yzTQQHGv--