lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4656C8BC.6060807@garzik.org>
Date:	Fri, 25 May 2007 07:30:04 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Henry Su <henry.su@....com>
CC:	alan@...rguk.ukuu.org.uk, greg@...ah.com, bzolnier@...il.com,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	xiaosuzi520@...mail.com
Subject: Re: [patch] Add the device IDs for AMD/ATI SB700

Henry Su wrote:
> I check the latest kernel source code with git, and find out that the SMBus patch has not been applied yet, 

Correct.  When you don't see a patch in the upstream git tree 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
then the next step is consult the MAINTAINERS file, and determine to 
whom you should send a follow-up patch, or simply contact about the 
status of a patch you just sent.  In this case, SMBus is in drivers/i2c 
sub-directory, which leads us to find in MAINTAINERS,

I2C SUBSYSTEM
P:      Jean Delvare
M:      khali@...ux-fr.org
L:      i2c@...sensors.org
T:      quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
S:      Maintained

That tells us the maintainer of the subsystem, and also ("T:") an 
external reference (a tree) to where the maintainer posts accepted 
patches, prior to sending them upstream.

So for SMBus, you should make sure your SMBus changes appear in Jean 
Delvare's quilt tree.  If they do not, create a new patch and send it to 
Jean and CC i2c@...sensors.org and linux-kernel@...r.kernel.org.


> and the patch for IDE  has not been  applied completely.one more device id should be added to pata_atiixp.c,
> l list the patch as following, or you can fetch it from the attached file, could you please apply this for me? 

Actually it has been applied -- the part that I maintain (drivers/ata/*) 
is currently stored in a secondary tree, as described above.  Your patch 
has been stored on the 'upstream' branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

Currently, the upstream Linux kernel is only accepting bug fixes.  I 
merge ATA bug fixes (and sometimes simple PCI ID additions) into 
libata-dev.git#upstream-fixes during this phase of development.  These 
changes are sent upstream in 24-48 hours, to ensure that they will be 
included in the next release (kernel 2.6.22).

All other ATA changes are merged into libata-dev.git#upstream.  When 
Linus releases kernel 2.6.22, the "merge window" opens, allowing 
non-bug-fix changes to be submitted upstream.  When the merge window 
opens, I submit everything in libata-dev.git#upstream to Linus and 
Andrew Morton for inclusion in the official upstream kernel tree.

That is our development process in a nutshell.

The kernel development process is conducted entirely via email, so you 
see why it is so important to learn how to email patches in the proper 
format.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ