Re: [libimobiledevice-devel] ipheth

2010-04-29 Thread Paul McEnery 
On 27 April 2010 17:39, Julien BLACHE jbla...@debian.org wrote:
 Olivier Galibert galib...@pobox.com wrote:

 Hi,

 Why can't ipheth just depend on libimobiledevice-utils ?  It *is* a
 functional dependency after all, even if they're not communicating
 directly with each other.

 The ipheth-dkms package will disappear because ipheth has been accepted
 upstream and the kernel team added it to our 2.6.32 packages.

 So there's only ipheth-utils left, containing the udev rules and the
 pairing utility. If a pairing utility is also distributed as part of
 libimobiledevice, we're left with just the udev rules, and at that point
 it's just sane to ask ourselves where the udev rules belong.

 I think it's going to end up in libimobiledevice-utils at that point,
 unless there's a compelling reason not to do that. A package for a
 single very small file is a big no-no.



Is anyone prepared to commit to including a pairing utility and the
udev rule as part of libimobiledevice?

If so, I guess we have a solution. The respective distro packagers can
do the rest.

Regards,
Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/h2pb4892f8e1004292133wb1e728fck4eca1d7627d87...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-27 Thread Paul McEnery 
On 27 April 2010 10:47, Martin S. i...@sukimashita.com wrote:
 On Tue, 2010-04-27 at 00:38 +0200, L. Alberto Giménez wrote:
 On Sat, Apr 24, 2010 at 11:55:53AM +0100, Paul McEnery wrote:
  In order for the udev rule to execute *any* application which performs
  the pairing, that application must exist in some package. That package
  will need to be a dependency of usbmuxd (unless usbmuxd provides it).
  It cannot simply be assumed that if usbmuxd is installed that gvfs,
  libgpod, etc will also be installed, let alone executed before the
  user attempts to connect using ipheth. The only way that these
  assumptions can be met, is with the appropriate dependencies.
 
  The way that this must be tested is as follows:
 
  - Debian base install (bare minimum system).
  - install something
  - configure interface to test
 
  The something above needs to ensure that when an iPhone/device is
  plugged it, it will pair automatically.

 Hi, If I'm allowed to put my $2c, I propose to put the pairing utility on the
 libimobiledevice package, and make usbmuxd depend on it (which IMO is quite
 natural).

 Does it make sense at all?

 It would be a circular dependency and is not right. libimobiledevice
 depends on usbmuxd. Also mind checking this overview:
 http://libimobiledevice.org/am-stack-fig-4.png

 ipheth does not depend on usbmuxd nor does it need it to work as it
 talks to a different USB interface.


I dont think this is strictly true. Usbmuxd must be up and running or
the internet connection does not work. I recall seeing TX timeout
messages in syslog if usbmuxd failed to start/was not running while
trying to communicate over the ipheth interface.


I'll try and sum up what I think is needed:

1. libimobiledevice supplies some sort of pairing utility, or set of
utils which can pair, unpair, and list.

2. This idevicepair util gets packaged in Debian in the existing
libimobiledevice-utils package.

3. The existing ipheth-utils package should be renamed to ipheth-support which:
   a. supplies a udev rule;
   b. depends on libimobiledevice-utils.

Does this sound sensible?

I may need some help with the udev rule... The existing ipheth udev
rule could do with some work. I have not had time to test it yet, but
I had been planning to replace it with this:

=8==
ACTION==add, SUBSYSTEM==net, ENV{ID_USB_DRIVER}==ipheth,
ATTR{idVendor}==05ac, RUN+=ipheth-pair
=8==


Regards,
Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/z2pb4892f8e1004270539xa2e83109hd91dde68f8c2f...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-27 Thread Paul McEnery 
On 27 April 2010 14:33, Peter Robinson pbrobin...@gmail.com wrote:
 On Tue, Apr 27, 2010 at 1:39 PM, Paul McEnery pmcen...@gmail.com wrote:
 On 27 April 2010 10:47, Martin S. i...@sukimashita.com wrote:
 On Tue, 2010-04-27 at 00:38 +0200, L. Alberto Giménez wrote:
 On Sat, Apr 24, 2010 at 11:55:53AM +0100, Paul McEnery wrote:
  In order for the udev rule to execute *any* application which performs
  the pairing, that application must exist in some package. That package
  will need to be a dependency of usbmuxd (unless usbmuxd provides it).
  It cannot simply be assumed that if usbmuxd is installed that gvfs,
  libgpod, etc will also be installed, let alone executed before the
  user attempts to connect using ipheth. The only way that these
  assumptions can be met, is with the appropriate dependencies.
 
  The way that this must be tested is as follows:
 
  - Debian base install (bare minimum system).
  - install something
  - configure interface to test
 
  The something above needs to ensure that when an iPhone/device is
  plugged it, it will pair automatically.

 Hi, If I'm allowed to put my $2c, I propose to put the pairing utility on 
 the
 libimobiledevice package, and make usbmuxd depend on it (which IMO is quite
 natural).

 Does it make sense at all?

 It would be a circular dependency and is not right. libimobiledevice
 depends on usbmuxd. Also mind checking this overview:
 http://libimobiledevice.org/am-stack-fig-4.png

 ipheth does not depend on usbmuxd nor does it need it to work as it
 talks to a different USB interface.


 I dont think this is strictly true. Usbmuxd must be up and running or
 the internet connection does not work. I recall seeing TX timeout
 messages in syslog if usbmuxd failed to start/was not running while
 trying to communicate over the ipheth interface.


 I'll try and sum up what I think is needed:

 1. libimobiledevice supplies some sort of pairing utility, or set of
 utils which can pair, unpair, and list.

 2. This idevicepair util gets packaged in Debian in the existing
 libimobiledevice-utils package.

 3. The existing ipheth-utils package should be renamed to ipheth-support 
 which:
   a. supplies a udev rule;
   b. depends on libimobiledevice-utils.

 Does this sound sensible?

 I may need some help with the udev rule... The existing ipheth udev
 rule could do with some work. I have not had time to test it yet, but
 I had been planning to replace it with this:

 Why not just include the required udev rule in the libimobiledevice
 along with the pairing util? Ultimately it doesn't really matter if
 the rule is included their or even in the upstream udev package. Why
 have a separate package for a 2 line text file?


I hear what you are saying, but again it comes down to guaranteeing
that the components are installed which give the required
functionality. In order to maintain the proper chain of dependency,
the udev package would need to depend on libimobiledevice-utils. You
cannot simply supply a udev rule which points to an executable without
guaranteeing that that executable exists.

I dont like the idea of a package supplying a single udev rule either,
but we need to make sure the dependencies are correct.

How about this then libimobiledevice-utils supplying the udev rule
and pairing utility, and providing a virtual package which Provides:
ipheth-support? Maybe the provides bit is not required...

Suggestions welcome...

Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/h2mb4892f8e1004270714kbfe9bf53nf16f13831c012...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-24 Thread Paul McEnery 
2010/4/22 Ben Hutchings b...@decadent.org.uk:
 On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
 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.

 Since ipheth has now been accepted by David Miller, I've just added it
 to the repository for Debian kernel packages.


Thanks Ben.

I'll update the ipheth package in the next couple of days. I'll pick
up the discussion about dropping ipheth-dkms on the debian-kernel
list...

Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/s2sb4892f8e1004232246s11e6dc90xe88da5e4a679a...@mail.gmail.com

ipheth

2010-04-24 Thread Paul McEnery 
Since ipheth has now been accepted into the mainline kernel, I see a
couple of choices for the ipheth package:

1. Drop ipheth-dkms altogether.
2. Drop the dependency on ipheth-dkms in the ipheth-utils package.

My initial thoughts are to simply drop the dependency on the dkms
package, but ipheth will now be in every kernel going forward, so
there will not be any need for it. Any advice would be much
appreciated. Please include me in any reply as I'm not on the list.

Many thanks,
Paul.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/v2gb4892f8e1004232253rcccb676ey53a63a2a55de5...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-24 Thread Paul McEnery 
On 24 April 2010 08:00, Peter Robinson pbrobin...@gmail.com wrote:
 On Sat, Apr 24, 2010 at 6:46 AM, Paul McEnery pmcen...@gmail.com wrote:
 2010/4/22 Ben Hutchings b...@decadent.org.uk:
 On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
 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.

 Since ipheth has now been accepted by David Miller, I've just added it
 to the repository for Debian kernel packages.


 Thanks Ben.

 I'll update the ipheth package in the next couple of days. I'll pick
 up the discussion about dropping ipheth-dkms on the debian-kernel
 list...

 Was was the final decision of merging the small util into one of the
 other packages and the udev rules into usbmuxd?


This was discussed a few weeks ago, but I don't recall anyone being in
overwhelming support of the idea. I'm not sure that usbmuxd should
have *libimobiledevice-utils* as a dependency for something may not be
used by everyone. If there is some value in this, then I think its
worth reopening the discussion.

At this point I'm working on dropping the ipheth-dkms package and
keeping only ipheth-utils which provides the udev rules and pariing
utility.

If the former approach is preferred, then we can look at getting the
respective maintainers involved...

Regards,
Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/g2mb4892f8e1004240118r49443f08odced4d7f0dcb5...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-24 Thread Paul McEnery 
On 24 April 2010 11:01, Peter Robinson pbrobin...@gmail.com wrote:
 Was was the final decision of merging the small util into one of the
 other packages and the udev rules into usbmuxd?


 This was discussed a few weeks ago, but I don't recall anyone being in
 overwhelming support of the idea. I'm not sure that usbmuxd should
 have *libimobiledevice-utils* as a dependency for something may not be
 used by everyone. If there is some value in this, then I think its
 worth reopening the discussion.

 No, you've mis interpreted what was said. The udev rule would be in
 usbmuxd with the other ipod/iphone rules for various bits and then the
 actual pairing utill would be in libimobiledevice. There would be no
 extra dependencies.


In order for the udev rule to execute *any* application which performs
the pairing, that application must exist in some package. That package
will need to be a dependency of usbmuxd (unless usbmuxd provides it).
It cannot simply be assumed that if usbmuxd is installed that gvfs,
libgpod, etc will also be installed, let alone executed before the
user attempts to connect using ipheth. The only way that these
assumptions can be met, is with the appropriate dependencies.

The way that this must be tested is as follows:

- Debian base install (bare minimum system).
- install something
- configure interface to test

The something above needs to ensure that when an iPhone/device is
plugged it, it will pair automatically.

I agree that a maintaining such a small package may be pointless, but
we need some agreement on *exactly* how this is going to work

Regards,
Paul.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/t2ub4892f8e1004240355z3ff79312p42e3696f7fd8b...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-07 Thread Paul McEnery 
On 3 April 2010 22:11, L. Alberto Giménez agime...@sysvalve.es wrote:
 On 04/02/2010 10:09 PM, Paul McEnery wrote:
 [...]
 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 idevice tethering?

 Hi Paul,

 Reading the thread that you posted, it seems like the original author
 agreed to kind of support a kernel-space driver.

 And about your question, I *personally* think that it's the way forward.
 We have a hardware device that does networking. Si it needs a driver.
 And I'm not the best friend of userspace drivers, except for very
 specific tasks and to play a little bit (look ma! I implemented a
 filesystem with FUSE!).


 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.

 I think that this is the one that would fit my view (which may not be
 the correct one, but it's my view). Then we can handle everything else
 with package dependencies (usbmuxd, libimobiledevice, ...).

 There are still some issues that are pending to fix over the first
 driver submission. I've already posted a couple of messages regarding
 those issues (I don't have the knowledge to decide about the low-level
 aspects of the device or the kernel API itself) and contacted with
 Daniel and Diego, so Í think that it's close to get in (linux-next, I
 guess) if the list members don't have further comments.

 If you need help packaging (I think that you are the future maintainer
 for those Debian packages, am I right?), I have some basic experience
 with it, so don't feel alone, I can help if required :)



Hi Alberto.

I've left this for a couple of days to see if anyone else has
something they would like to add. Thanks for offering your help with
regard to packaging assistance. At the moment though, I think I have
it under control. Ipheth is currently in the Debian NEW queue, and
should be accepted shortly. At this point, I think that we will be
moving forward with option 1.

Once you have successfully submitted ipheth for mainline inclusion, I
will drop the -dkms package and simply maintain a single ipheth-utils
package.

Regards,
Paul.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/z2gb4892f8e1004070742sef1704c0n293fe6bc2dc29...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-02 Thread Paul McEnery 
On 2 April 2010 15:11, L. Alberto Giménez agime...@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 idevice 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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/y2qb4892f8e1004021309l27c086dex1fbe1d7db74df...@mail.gmail.com

Re: ipheth

2010-04-01 Thread Paul McEnery 
On 1 April 2010 14:07, Ben Hutchings b...@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
idevice 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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/p2yb4892f8e1004010630q941d7cfere161b15ab4d98...@mail.gmail.com

Re: [libimobiledevice-devel] ipheth

2010-04-01 Thread Paul McEnery 
On 1 April 2010 18:23, Martin S. i...@sukimashita.com wrote:
 On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery wrote:
 On 1 April 2010 14:07, Ben Hutchings b...@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
 idevice 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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/g2jb4892f8e1004011320h278ff4eeh7ea64aa595136...@mail.gmail.com