[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [libimobiledevice-devel] ipheth



On Thu, 2010-04-01 at 21:20 +0100, Paul McEnery wrote:
<snip>
> 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.

Adding support for the user-space tethering service would be fairly
straight-forward, Dan Williams and I already added support for Bluetooth
that way. It ends up being better integrated into the applications, if
there are things that cannot be exported via the kernel interfaces.

> 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.

You could say the exact same thing about things like Bluetooth support
(BlueZ in-kernel and bluetoothd). You won't be able to make it work one
bit without the user-space daemon.

>  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.

The pairing could also not be done automatically, and you'd document it
for people that want to use the command-line, and integrate it in
something like nautilus-ideviceinfo for others (add a checkbox about
whether to enable tethering, and allow things like entering passcodes).

> 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.

DKMS isn't good enough to provide an integrated user-experience on
distributions like Fedora (which only ship in-kernel modules, no
out-of-tree drivers). If you're really not willing to get the driver
upstream, then we'd probably end up shipping the user-space driver, and
writing integration into NetworkManager for it.

The best course of action, IMO, would be:
- get ipheth into the kernel
- add a command-line application to do the pairing
- integrate a checkbox in nautilus-ideviceinfo to allow
enabling/disabling the tethering support (so NetworkManager doesn't
automatically connect to it when you're not interested in sharing the
connection)

Cheers


Reply to: