[Click] userdevs

[Eddie Kohler]

Hi Roman,

I have checked in versions of your ToUser and FromUser elements to the Click 
repository.  Thanks so much for these changes!

In the process of checking them in, I made several changes.  Here they are.

1. At first I could not compile them because of kernel version differences. 
(For example, your code assigned file_operations::readv and writev, but on 
2.6.19.2, those operations do not exist.)

2. You assigned many members of struct file_operations to return_EIO.  But 
more modern style is simply to leave the operations null.

3. I changed Click to export a function click_new_file_operations() for the 
elements to use.  This will allow you to unload the Click module even while a 
process is reading from /dev/fromclick.

4. All other elements call the capacity of a queue CAPACITY, not SIZE.  Changed.

5. FromUser and ToUser seemed potentially too general as names.  (After all, 
ToDeviceSniffers also sends a packet "to the user"; similarly for 
FromHost/FromUser.)  I've changed the names to FromUserDevice and 
ToUserDevice.  However, I don't feel strongly about this, and am happy to 
change back; just let me know.

6. It seemed weird to me that ToUserDevice copied the packet data three times, 
once out of the packet into the slot, once out of the slot into the temporary 
slot (introducing a race condition), and once out of the temporary slot to the 
user device.  I have changed this so that ToUserDevice stores *packets*, not 
slots.  The packet data is copied just once.  Perhaps the slot structure is 
actually faster in practice; let me know if you chose slots rather than 
packets for a reason.  However, the way I've done it has other advantages 
(allows more than one concurrent reader, better locking).

7. I've also tried to update the cleanup() procedures so that sleeping 
processes don't access freed element memory.  The cleanup()s schedule() 
themselves until their wait queues are empty.  I haven't tested this deeply.

8. The differences between ToUserDevice and FromUserDevice interactions seemed 
weird.  In particular, read() functions ALWAYS return a number of bytes, and 
accept a number of bytes; it is not a good idea for ToUserDevice to change the 
argument and return value to numbers of slots.  (This will confuse lots of 
programs and users, and lead to segmentation faults.)  I changed the function 
to follow a different spec.  In normal mode, read() will return one packet 
into the provided buffer.  After an ioctl -- ioctl(fd, 
CLICK_IOC_TOUSERDEVICE_SET_MULTI, (unsigned long) 1) -- the file descriptor is 
placed in "multipacket mode".  read() will then store multiple packets' data 
in the buffer.  Each packet is preceded by an integer (its length), and 
followed by padding so that the next length is on an integer boundary.  But I 
have not tested multipacket mode.

9. The first time I ran a configuration with both FromUserDevice and 
ToUserDevice (before many of these changes), the thing went haywire.  I think 
this was due to a cleanup problem, and I think I have fixed it.  But because 
of this, because of the extensive click_chatters, and because the elements' 
locking discipline still seems a bit weird (FromUserDevice in particular), 
I've marked the elements as "experimental".  They will not be compiled unless 
the user supplies --enable-experimental to ./configure.

Thanks again for these elements.  Please update them as you like and send 
patches, etc.!

Eddie


Roman Chertov wrote:
> Eddie,
>    The copyright should be Purdue copyright (I included that in the 
> sources).  As far as I understand the Purdue and Click copyrights are 
> similar.
> 
> Roman
> 
> Eddie Kohler wrote:
>> Roman,
>>
>> What should the copyright on these files be?  And are you authorized 
>> to release them with the Click license?
>>
>> Eddie
>>
>>
>>
>> Roman Chertov wrote:
>>> Hello Eddie,
>>>     These are my latest drivers that allow to kernel level Click to 
>>> communicate with user level apps.  Please let me know if you have 
>>> issues.  Sorry for the delay with these but we have had connectivity 
>>> issues in one of the labs.
>>>
>>> Roman
>>>
>>>
>>> // Simple script that uses four /dev/toclick devices
>>> // and two /dev/touser devices  Just tunnels the packets from
>>> // the devices to each other via click.
>>> // ==============================================
>>>
>>> ip_route :: RadixIPLookup(10.0.1.0/24 0,
>>>                           10.0.2.0/24 0,
>>>                           10.0.4.0/24 1,
>>>                           10.0.5.0/24 1,
>>>                           0/0 2);//*/
>>>
>>> elementclass FromU
>>> {
>>>     $dev,  |
>>>     // now it runs with too much slop.  try threading this
>>>     FromUser($dev, SIZE 32) -> Unqueue
>>>                             -> CheckIPHeader2(0)
>>>                             -> [0]output
>>> };
>>>
>>> FromU0 :: FromU(0)-> ctr0::AverageCounter -> ip_route;
>>> FromU1 :: FromU(1)-> ctr1::AverageCounter -> ip_route;
>>> FromU2 :: FromU(2)-> ctr2::AverageCounter -> ip_route;
>>> FromU3 :: FromU(3)-> ctr3::AverageCounter -> ip_route;
>>>
>>>
>>>
>>> ip_route[0] -> EtherEncap(0x0800, 0:0:0:0:0:0, 1:2:3:4:5:6)
>>>             -> recv_ctr :: AverageCounter
>>>         -> tu0::ToUser(0, SIZE 5000);
>>>
>>>
>>> ip_route[1] -> EtherEncap(0x0800, 0:0:0:0:0:0, 1:2:3:4:5:7)
>>>             -> tu1::ToUser(1, SIZE 5000);
>>>
>>>
>>>
>>> ip_route[2] -> IPPrint
>>>             -> Discard;
>>>
>>
>