Ben, Was trying to get the latest debian kernel sources for 3.2.15-1. In the link you provided, the following step: svn co svn://anonscm.debian.org/svn/kernel/dists/sid/linux-2.6
does not seem to work. Is this the only way to get the sources? Am I missing something? Thanks, Sarvesh -----Original Message----- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Friday, April 20, 2012 7:14 AM To: Bandi,Sarveshwar Cc: Debian kernel maintainers Subject: RE: Basic question on debian kernel versions On Thu, 2012-04-19 at 00:55 -0700, sarveshwar.ba...@emulex.com wrote: > Ben, > Thanks that clarifies a lot. > > I do intend to provide updates to driver. Some quick questions. I know > need to figure this myself but am running round In circles. > - Can you give me a pointer to latest debian kernel tree? I assume I > will be able figure out the latest commit id that was taken for debian > from that. Depending on which form you prefer to work with, you can use: 1. A git repository containing branches tracking each of the releases/suites. This is *not* the working repository (that's option 2) and is not always up-to-date, but may be preferable as a way to view and prepare patches: http://anonscm.debian.org/gitweb/?p=kernel/linux-2.6.git 2. The source package 'linux-2.6' contains upstream source and all the patches we apply to it. You can check out the development branch for each release/suite with Subversion: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs 3. The package 'linux-source-2.6.32' or 'linux-source-3.2' (depending on which release you are targetting) contains the source with all Debian patches applied: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-getting > - Is it sufficient to give you commit id (from net-next) that need to > be taken into debian or do I need to give patches Against the latest > tree? If the driver source in net-next can just be dropped into the older kernel version and still work, then the commit ID is probably OK. But very often that isn't the case due to API changes (and I can't believe it's true for Debian 6.0, i.e. Linux 2.6.32). I personally prefer to see a patch series with upstream references (as you see in the kernel.org stable/longterm branches) and any necessary fix-ups for API differences made in those individual patches. As an example, see my own backport of tg3 at <http://anonscm.debian.org/gitweb/?p=kernel/linux-2.6.git;a=shortlog;h=refs/heads/squeeze;pg=1>. It's OK to backport the addition of new functions, e.g. the series of commits 'net: Add netdev_alloc_skb_ip_align() helper' up to 'err.h: add helper function to simplify pointer error checking' that you can see at <http://anonscm.debian.org/gitweb/?p=kernel/linux-2.6.git;a=shortlog;h=refs/heads/squeeze;pg=7>. But this has to be done with care to avoid affecting other drivers! > - Whats the process, Do I just post these on this list or do I need to > open bugs first? Or just point me to a faq. Do open a bug, requesting addition of new hardware support. Start with: Package: src:linux-2.6 Version: <current version> Severity: important If you want Debian 6.0 to be updated then specify the latest version there (2.6.32-43); if you only want this to go into Debian 7.0 then specify the latest version there (3.2.15-1). Patches should be sent to the bug address, which will forward to the debian-kernel mailing list. If you end up with a very long patch series it may be better to send it as a tarball. But if there's any thing that needs significant changes in the process of backporting, it might still be worth sending that individually so it's easier to review. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
