FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 04-01-2010, 01:07 PM
Ben Hutchings
 
Default ipheth

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?

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-01-2010, 01:30 PM
Paul McEnery
 
Default ipheth

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?

Regards,
Paul.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: p2yb4892f8e1004010630q941d7cfere161b15ab4d98a8c@ma il.gmail.com">http://lists.debian.org/p2yb4892f8e1004010630q941d7cfere161b15ab4d98a8c@ma il.gmail.com
 
Old 04-01-2010, 03:14 PM
Peter Robinson
 
Default ipheth

On Thu, Apr 1, 2010 at 2:30 PM, Paul McEnery <pmcenery@gmail.com> 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?

All the other udev rules for the iphone/ipod touch interfaces are
contained in usbmuxd so would it make sense to merge it into those
rules, and then AFAICS the pair utility is a small util so it would
probably be worthwhile merging it into libimobiledevice. Save the
maintenance on yet another release. That way as well it should be easy
to keep them all in sync for any api changes etc.

Peter


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: l2o5256d0b1004010814z3b8e703cn400543f7b02f44dc@mai l.gmail.com">http://lists.debian.org/l2o5256d0b1004010814z3b8e703cn400543f7b02f44dc@mai l.gmail.com
 
Old 04-01-2010, 05:23 PM
"Martin S."
 
Default ipheth

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.

--- Martin S.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1270142630.6437.169.camel@mirell">http://lists.debian.org/1270142630.6437.169.camel@mirell
 
Old 04-01-2010, 08:20 PM
Paul McEnery
 
Default 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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: g2jb4892f8e1004011320h278ff4eeh7ea64aa595136ab1@ma il.gmail.com">http://lists.debian.org/g2jb4892f8e1004011320h278ff4eeh7ea64aa595136ab1@ma il.gmail.com
 
Old 04-01-2010, 08:40 PM
Daniel Borca
 
Default ipheth

Martin,

ipheth needs ValidatePair, not Pair
http://libiphone.lighthouseapp.com/projects/27916/tickets/89-provide-access-to-validatepair#ticket-89-9
http://github.com/dgiagio/ipheth/blob/master/ipheth-pair/ipheth-pair.c

Regards,
Daniel Borca


--- On Thu, 4/1/10, Paul McEnery <pmcenery@gmail.com> wrote:

> From: Paul McEnery <pmcenery@gmail.com>
> Subject: Re: [libimobiledevice-devel] ipheth
> To: "Martin S." <info@sukimashita.com>
> Cc: "Ben Hutchings" <ben@decadent.org.uk>, "Julien BLACHE" <jblache@debian.org>, libimobiledevice-devel@lists.libimobiledevice.org, "Debian kernel team" <debian-kernel@lists.debian.org>, "Daniel Borca" <dborca@yahoo.com>, "Diego Giagio" <diego@giagio.com>
> Date: Thursday, April 1, 2010, 11:20 PM
> 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
>





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 448944.25149.qm@web110412.mail.gq1.yahoo.com">http ://lists.debian.org/448944.25149.qm@web110412.mail.gq1.yahoo.com
 
Old 04-01-2010, 08:49 PM
"Martin S."
 
Default ipheth

On Thu, 2010-04-01 at 13:40 -0700, Daniel Borca wrote:
> Martin,
>
> ipheth needs ValidatePair, not Pair
> http://libiphone.lighthouseapp.com/projects/27916/tickets/89-provide-access-to-validatepair#ticket-89-9
> http://github.com/dgiagio/ipheth/blob/master/ipheth-pair/ipheth-pair.c
>
> Regards,
> Daniel Borca

ideviceinfo and other tools call lockdownd_new_with_handshake(). That
also uses ValidatePair in order to verify pairing:
http://cgit.sukimashita.com/libimobiledevice.git/tree/src/lockdown.c#n688

Afaik. what counts for ipheth to work is the lockdown key
"TrustedHostAttached" to be switched to "True" by the device. This is
confirmed and reported by running "ideviceinfo -k TrustedHostAttached".

Some idevicepair tool could provide this information.

I think to solve this discussion we need to look at how this issue is
solved on Mac OS X and Windows by iTunes.

--- Martin S.

>
>
> --- On Thu, 4/1/10, Paul McEnery <pmcenery@gmail.com> wrote:
>
> > From: Paul McEnery <pmcenery@gmail.com>
> > Subject: Re: [libimobiledevice-devel] ipheth
> > To: "Martin S." <info@sukimashita.com>
> > Cc: "Ben Hutchings" <ben@decadent.org.uk>, "Julien BLACHE" <jblache@debian.org>, libimobiledevice-devel@lists.libimobiledevice.org, "Debian kernel team" <debian-kernel@lists.debian.org>, "Daniel Borca" <dborca@yahoo.com>, "Diego Giagio" <diego@giagio.com>
> > Date: Thursday, April 1, 2010, 11:20 PM
> > 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
> >
>
>
>
>



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1270154991.6437.248.camel@mirell">http://lists.debian.org/1270154991.6437.248.camel@mirell
 
Old 04-02-2010, 08:09 PM
Paul McEnery
 
Default 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.

Regards,
Paul.

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: y2qb4892f8e1004021309l27c086dex1fbe1d7db74df725@ma il.gmail.com">http://lists.debian.org/y2qb4892f8e1004021309l27c086dex1fbe1d7db74df725@ma il.gmail.com
 
Old 04-02-2010, 08:40 PM
Ben Hutchings
 
Default ipheth

On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
[...]
> 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.
[...]

The Debian kernel team's policy on backporting drivers is that drivers
must have been *accepted* upstream, not that they must have been part of
an upstream release. ipheth is a pretty small driver and doesn't appear
to have any major problems, so I would expect it to be accepted on the
second submission, within the next week or so. At that point we can
immediately add it to our kernel packages.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-04-2010, 04:27 PM
Bastien Nocera
 
Default 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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1270398457.14605.2771.camel@localhost.localdomain" >http://lists.debian.org/1270398457.14605.2771.camel@localhost.localdomain
 

Thread Tools




All times are GMT. The time now is 09:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org