Subject: Re: ugen change for review (try 2)
To: Berndt Josef Wulf <firstname.lastname@example.org>
From: Greg Troxel <email@example.com>
Date: 07/21/2006 13:41:11
Berndt Josef Wulf <firstname.lastname@example.org> writes:
> On Friday 21 July 2006 05:09, Greg Troxel wrote:
>> I can see two reasons not to have these changes compiled in all the
>> 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 more closely to the specifications should be enabled by
> default? The intended changes are not to extend but to add missing
> code making this device more compliant.
There are two issues: functionality/semantics and performance. The
change increases functionality but changes semantics. Thus, it's not
appropriate to enable RA_WB all the time.
The basic issue is the relationship of system calls and USB
transactions. Now, with ugen(4), a read system call causes a USB read
transaction. For some devices, that might be important, where the
read transcation initiates a measurement, or something else.
Write transaction buffering is less problematic, but write-behind
breaks the current notion that the transaction has finished (at some
layer - I'm not sure all the way down).
It's perhaps true for the USRP and USRP-like devices that one would
always want RA_WB, but it's also quite trivial for the USRP library to
enable this feature.
Greg Troxel <email@example.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)
-----END PGP SIGNATURE-----