Re: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3

[Jeff Garzik <jgarzik@pobox.com>]

Mark Lord wrote:
> Jeff Garzik wrote:
> 
>>
>> We don't add hooks on the _hope_ that _future_ code will (a) use the 
>> hooks and (b) be GPL'd.
> 
> 
> Sure we do.  All of the time.
> 
> All of the other RAID drivers in the kernel have ioctl() hooks
> for external code to control driver interfaces and settings.
> Except with that kind of interface, we never get an open-source
> version of that external code.

You are missing the key point that an ioctl is _vastly_ differently from 
a kernel interface, from both a legal and technical perspective.

The userland<->kernel interface is a hard "line in the sand" where we 
don't presuppose you are "linking" (as the GPL defines it)


> Given all of the fuss over this core driver (qstor.{ch}),
> there is simply no way the vendor wants to go through it all again
> for their RAID management module.  So sure, it will be GPL and
> given away in source form (website, installation CD, etc..),
> but it won't appear here simply because we're making too hard
> for them to do so.

Hardly.  You're requesting hooks for something that is (a) unreviewed 
and (b) doesn't even exist.  So far as things stand, the need for the 
hooks has not been justified.

Furthermore, it has always been the Linus policy "do what you need, and 
no more."  Adding hooks before they are used violates that credo.


> The exports are needed if we want that component to be open source.
> Otherwise, they'll be replaced by ioctl()s like all of the other
> drivers, and that part of the source code may then never be released.

Fundamentally we do not add kernel interfaces for code that isn't in the 
kernel.

Overall, I don't see why it is so damned difficult to delete the hooks 
then add them back when they _are_ needed.  I would certainly support 
you in that effort.

	Jeff