Re: [libimobiledevice-devel] ipheth
On 1 April 2010 18:23, Martin S. <info@sukimashita.com> wrote:
> On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery wrote:
>> On 1 April 2010 14:07, Ben Hutchings <ben@decadent.org.uk> wrote:
>> > Paul,
>> >
>> > I missed you talking about ipheth on IRC earlier.
>> >
>> > I've seen the submission of ipheth on the netdev mailing list, and made
>> > some comments on it there. If it is accepted, we can include it in the
>> > Debian kernel packages and there will then be no need for ipheth-dkms.
>> > You'll still need ipheth-utils. As for the udev rules, what do they do?
>> >
>>
>> Hi Ben.
>>
>> The udev rules detect when an iPhone has been plugged in and execute a
>> utility (ipheth-pair) which ensures that the iPhone is paired with the
>> system to which it has been attached. Ipheth-pair is a small program
>> written in C which makes use of libimobiledevice. Essentially
>> ipheth-utils provides provides only the udev rules file and
>> ipheth-pair utility. Ipheth-dkms provides the kernel module source
>> code...
>>
>> So I'm guessing that ipheth-utils could be a package which is
>> maintained long-term once ipheth is included in the mainstream kernel,
>> or...
>>
>> Would it be more sensible to have libimobiledevice provide a generic
>> pairing utility and set of udev rules which execute it when an
>> i<device> is attached? Possibly part of libimobiledevice-utils? This
>> appears to be a cleaner solution than maintaining a separate package
>> for the task.
>>
>> Does anyone else have an opinion on this?
>
> Afaik. running any tool from libimobiledevice tools has the same effect
> (for instance ideviceinfo). Those will pair a previously unpaired device
> on the fly, too.
>
> Only issue to take care of is that password protected devices that pair
> for the first time with the host computer need their password disabled
> in order for the initial pairing to succeed.
>
> Additionally, I recently pushed a flag into the usbmuxd udev rules named
> "USBMUX_SUPPORTED" which dependent rules can use to detect devices
> supporting the usbmux protocol without having to maintain any usb id
> ranges which clearly belong into usbmuxd.
>
> If you like we can create a simple "idevicepair" tool to allow cli based
> manual pairing, unpairing and managing pairing records on the host.
>
> Besides that, the only thing I would add for discussion is to question
> the need for a kernel driver since I have seen someone on the libiphone
> ML did implement all the tethering stuff in user-space.
>
Hi Martin.
Thanks for your input on this. I know there was a brief discussion on
the topic of a kernel vs user space tethering driver, and speed was
one of the topics. I recall a few claims being made about how much
faster kernel space is, but this was never substantiated, and there
was never a conclusion to the discussion. IIRC the user space driver
was something that didn't integrate with the other components such as
NetworkManager in quite the same way that ipheth does. Ipheth is just
another interface - which is why it fits in very nicely with NM.
That said, ipheth is a tried and tested solution that appears to be
working well for many users [1].
Ben, one of the reasons that I was slow to respond to the call to
integrate ipheth into the mainline kernel is that I don't believe that
it belongs there. It's far too dependent on other bits and pieces in
order to function. It requires the user space usbmuxd daemon - and the
phone must be paired before it will function. It may well be easy to
add a utility for paring devices to the libimobiledevice-utils
package, but I'm not sure the solution becomes any more elegant. Then,
there is still the matter of what to do with the udev rules. I guess
it could be left to usbmuxd to pair any device which is connected, but
this has purposefully been left to each user space application to
handle appropriately. I'm not sure that all of this can (or should for
that matter) be elegantly put together.
Given what ipheth is, and how it works, I feel that DKMS provides a
flexible and practical way of making it available to users. Despite my
view on it, I am sure there are differing opinions - and I would like
to hear them.
Regards,
Paul.
1. http://popcon.ubuntu.com/unknown/by_vote
Reply to: