> I've had this idea in my head for long, but as never found the time
> to work on it, didn't feel appropriate to throw it to the wall and
> expect someone else to implement it. Anyway, it seems to me it might
> be a nice GSoC project, and not necessarily too complex. As I've my
> plate already full, I'm not volunteering myself for mentoring,
> though. I'm CCing email@example.com as they should be in the loop and
> Petter as he was working on integrating package data into
> discover-data at some point in the past, which might be interested
> in mentoring.
Yeah. Note that part of your propopsal is already implemented in
discover/discover-data, and the /sbin/discover-pkginstall script will
install hardware dependent packages. It can for example install raid
monitoring software when a supported raid is detected. It might
provide a starting point.
Keeping the mapping from hardware to packages up to date is a hard
problem without cooperation from the various package maintainers, and
some hardware is hard to detect, but for the easy stuff (PCI and USB),
the implementation is trivial.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Sun Apr 4 00:30:02 2010
Delivery-date: Sat, 03 Apr 2010 23:55:38 +0300
Received: from liszt.debian.org ([126.96.36.199]:51393)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
for email@example.com; Sat, 03 Apr 2010 23:55:38 +0300
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id AC80913A61E2; Sat, 3 Apr 2010 21:27:21 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on liszt.debian.org
X-Spam-Status: No, score=-5.8 required=4.0 tests=FOURLA,RCVD_IN_DNSWL_LOW,
RDNS_NONE,STATIC_RIMA_TDE autolearn=failed version=3.2.5
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id 21A9E2D0F19
for <firstname.lastname@example.org>; Sat, 3 Apr 2010 21:11:21 +0000 (UTC)
X-Virus-Scanned: at lists.debian.org with policy bank en-ht
X-Amavis-Spam-Status: No, score=-7.8 tagged_above=-10000 required=5.3
tests=[BAYES_00=-2, FOURLA=0.1, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1,
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id 6qff5GfPqo9L for <email@example.com>;
Sat, 3 Apr 2010 21:11:13 +0000 (UTC)
X-policyd-weight: using cached result; rate: -6.1
Received: from eul0600410.eu.verio.net (unknown [188.8.131.52])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "smtp.capside.com", Issuer "int-W000026-CA" (not verified))
by liszt.debian.org (Postfix) with ESMTPS id A97862D0F16
for <firstname.lastname@example.org>; Sat, 3 Apr 2010 21:11:13 +0000 (UTC)
Received: (qmail 21438 invoked by uid 89); 3 Apr 2010 21:11:09 -0000
Received: from 152.Red-88-2-254.staticIP.rima-tde.net (HELO [192.168.1.30]) (184.108.40.206)
(smtp-auth username email@example.com, mechanism cram-md5)
by eul0600410.eu.verio.net (NEVRiON/smtpd) with (AES256-SHA encrypted) ESMTPSA; Sat, 03 Apr 2010 23:11:09 +0200
Date: Sat, 03 Apr 2010 23:11:06 +0200
User-Agent: Mozilla-Thunderbird 220.127.116.11 (X11/20090706)
To: Paul McEnery <firstname.lastname@example.org>
CC: Diego Giagio <email@example.com>, Daniel Borca <firstname.lastname@example.org>,
Julien BLACHE <email@example.com>,
Debian kernel team <firstname.lastname@example.org>
Subject: Re: [libimobiledevice-devel] ipheth
References: <1270127260.12516.31.camel@localhost> <p2yb4892f8e1004010630q941d7cfere161b15ab4d98a8c@m ail.gmail.com> <1270142630.6437.169.camel@mirell> <g2jb4892f8e1004011320h278ff4eeh7ea64aa595136ab1@m ail.gmail.com> <4BB5FB10.email@example.com> <y2qb4892f8e1004021309l27c086dex1fbe1d7db74df725@m ail.gmail.com>
In-Reply-To: <y2qb4892f8e1004021309l27c086dex1fbe1d7db74df725@m ail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailing-List: <firstname.lastname@example.org> archive/latest/57791
Resent-Date: Sat, 3 Apr 2010 21:27:21 +0000 (UTC)
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 i<device> tethering?
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 =CD 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
L. Alberto Gim=E9nez
GnuPG key ID 0x3BAABDE1
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com=