Re: [RFC][PATCH] nbd driver for 2.5+: fix locking issues with ioctl UI

[Lou Langholtz <ldl@aros.net>]

Christoph Hellwig wrote:

>On Wed, Jun 25, 2003 at 09:36:50AM -0600, Lou Langholtz wrote:
>  
>
>>I have also attached a patch to Pavel's nbd-2.0 release nbd tools that 
>>updates the nbd-client to work with linux 2.5 as well as 2.5.74 
>>(assuming the aforementioned patch 6.1 made it into 2.5.74). Handling is 
>>switched at compile time however and uses <linux/version.h> to do the 
>>switching. This will have problems of course if the builder doesn't pay 
>>close attention to where there header file are coming from or tries to 
>>run the same binary on a different kernel release. Etc.
>>    
>>
>
>That's broken.  You must make sure that a binary works with different
>kernels or at least make it fail gracefully.  Using <linux/version.h>
>from userspace is absolutely not acceptable, just don't use kernel headers
>at all but a local copy of <linux/nbd.h>.
>  
>
Yes. To be fair though, the binary (and the driver too) was broken on 
linux 2.5 kernels long before I even proposed any changes to the nbd 
driver. I'm trying to fix that. But it's a puzzle that has to have 
pieces moved out of the way first. With constraints like making one 
patch per fundemental change, it's more of a challenge trying to keep 
things in sync with user space. I'd like to see binary (runtime) 
compatibility too, but it's a bigger step to implement that. In the 
meantime, the hack/patch I submitted to nbd-client seems like a step 
forward. At least it works its way around several of the 
incompatibilities and lets people find out what other problem may lie 
ahead. I just found another problem for example with the disconnect 
function in nbd-client that will need to be fixed in order to be able to 
unload the module. A future step will be to change the compile time 
switching to a runtime switch, but I'm not sold on any one way to 
implement this yet. If you have something in mind for this, let me know. 
For example, should the ioctls be used to somehow notify the user 
process of the differing implementation. Like returning EINVAL for 
NBD_SET_SOCK. That'd tell nbd-tool that the nbd driver thinks something 
about the ioctl was invalid but not what. I wanted to return EDEPRECATED 
instead but I haven't found that errno yet. I could overload an errno 
but that seems ugly too. Or the driver could have a NBD_GET_VERSION 
ioctl. Is there precedence for that? I haven't come accross it yet.

How would you propose these issues be solved? Keep in touch!! Thanks!!