On Thursday, 7. October 2010 12:27:21 Xiaofan Chen wrote:
> > 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.
The least breakage, the better.
I guess most users want detaching, there's normally no point on not doing it
on a normal distribution:
- ftdi_sio is enabled in the kernel
- you are running as a normal user
No need to burden the detach call on every libftdi (API) user.
> > 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
If we do this as a setting instead of a parameter to the
open() call, we can maintain API and ABI stability.
So it would work out of the box for most people
and Thomas could still tweak it to his liking.
> > 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.
Yes, this is also my opinion.
Thomas K., would that be fine with you?
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx