On 07/30/2015 04:01 PM, Marciniszyn, Mike wrote: >> >> I thought you were getting rid of this? >> >> Jason > > Doug wanted the v4 submitted as we currently have it. To be accurate, I said "If you want a chance at making 4.3, I need a v4". I didn't comment on whether or not any specific review comments were addressed. > Doug? I have no problem with this code. That Al finds the user space ABI for this driver to be bizarre is neither here nor there to me. Sure, this file does not exhibit normal file API behavior. Who cares? It's not a normal file in *any* sense of the word. For example, the normal write routine will never, ever accept just plain data. It's always in the form of a command. If you don't have the right magic decoder ring, you will get nothing but errors when trying to do something with this file. Much like /dev/infiniband/uverbs? files, it is a command interface, not a raw data interface. I actually think the fact that you guys use write for a single command and writev/write_iter for a command queue is an elegant solution to your particular needs. The only reason Al threw a hissy over it is because it tripped him up when he went to do the conversion from writev to write_iter. That's understandable. So, some clear documentation so someone like Al doesn't have to go reading through sources and try to figure out what you are doing would be the generally nice thing to do for other kernel generalists that might come poking around this way. Or, another option would be to drop the write function altogether and just make all commands come through writev/write_iter and if you only have one command, you only send one element. Regardless, those things can be cleaned up in follow on patches, please do not resubmit this set for that. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature