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

Re: [libimobiledevice-devel] ipheth

On 2 April 2010 15:11, "L. Alberto Giménez" <agimenez@sysvalve.es> wrote:
> On 04/01/2010 10:20 PM, Paul McEnery wrote:
>> 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
> Hi Paul,
> While I respect your opinion, I'm not with you at all. Hardware drivers
> *do* belong to the kernel. Integrating into mainline is just a matter of
> working on it to fit to the development/coding/interface standards out
> there.
> Just think that for *every* piece of hardware you need additional
> user-space tools other than the kernel module itself, just as with the
> ipheth driver, so I don't see a special case here.
>> 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.
> IMO, KDMS is just a proper way to use external modules that are not in
> mainline in your current system. It's just a "patch" to mask the fact
> that they are not in mainline, which is what I think that every kernel
> module should tend to.
> I mean, DKMS is not a fix to the fact that you need independent
> userspace tools (that, as I mention before, happen to be needed for
> *every* hardware/kernel module). In fact, althought you are compiling or
> integrating the module with DKMS, you *still* need usbmuxd and the
> pairing program.
> Interesting discussion here. I hope it moves forward :)

Hi Alberto.

Thanks for taking the time to explain your submission for mainline
kernel inclusion. I'd like to go back for a moment to the point that
Martin S. made about the need for a kernel space driver. IIRC, the
user space driver was submitted to the libiphone-devel (as it was
then) mailing list by Bradley Baetz. I managed to find a discussion
that he had on the NetworkManager mailing list [1]. There appeared to
be some inherent issues with a user space driver and its integration
with NetworkManager, which by my reading of it appear to be seamlessly
solved by a kernel space driver. Without wanting to say anything on
Bradley's behalf, it appeared as if he was in support of the tethering
driver being implemented in kernel space. That said, and given the
maturity of ipheth, would it be fair to say that ipheth is the way
forward in terms of i<device> tethering?

If not, I'd like to see the discussion on this topic continue.
However, if the answer to the above question is "yes", and ipheth is
going to be included in the mainline kernel; that leaves the following
details to be worked out.

Where do the udev rules and pairing utility reside?

I see two options here:

1. Keep the ipheth-utils package and drop ipheth-dkms when ipheth
makes it into the mainline kernel. Given that mainline inclusion could
take a while, users (of Debian at least) could start to benefit almost
immediately since all of the packaging work has already been done.

2. Shift these utilities into other packages such as
libimobiledevice-utils and/or usbmuxd. The benefit of this approach is
that there will be less packages to maintain. The drawback; it could
take some time to be worked out and packaged.

Sorry to spam everyone, I'd just like to make sure that the right
people are included in the discussion. Most of them are unfortunately
not on any of the lists.


1. http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00069.html

Reply to: