On Thu, Oct 7, 2010 at 6:05 PM, Thomas Klose <thomas.klose@xxxxxxxxxxxxx> wrote:
> In my opinion, the best solution would be to leave the kernel modules
> untouched in the open and close functions. For convenience, functions to
> detach and re-attach modules could be introduced (similar to those,
> provided by libusb):
>
> ftdi_detach_kernel_module(),
> ftid_detach_kernel_module_desc(), ...
> ftdi_attach_kernel_module(),
> ftid_attach_kernel_module_desc(), ...
>
> I realize, that this would break some applications. If you depend on
> detaching, you would have to call the detach function first. However,
> the change in the code would be minimal.
> Maybe this is too drastic and the libftdi users cannot live with this
> kind of changes. This is something only you can say.
I agree that you have a point. Let's see what the admin says.
> An alternative would be to provide options, how to open the device. I
> think this is what Uwe was suggesting in one of his earlier mails.
> However, I have no idea, how you intend to do this without changing the
> API.
So Uwe's suggestion seems to be the best. As for API compatibility,
I think the admin will have to decide. I personally do not see that
API compatibility that important for libftdi-1.0. To me it is more important
to get it right and easy to extend than keep the compatibility with the
original libftdi. But I know other people may have different opinions.
> In any case, I think the system should be in the same condition if the
> device was closed (re-attaching modules if necessary).
>
I think you have a point here.
--
Xiaofan
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
