From: Shureih, T. <tar...@in...> - 2002-06-21 17:18:51
|
The problem I am running in, in my opinion, has no relation as of yet = to the missing -- yet to be delivered -- rcu framework patch. To give you a background, our kernel is not a stock kernel.org kernel: Our source tree is a progressive development tree where multiple = patches are applied and integrated together to provide multiple functionality. The dcache file I sent is obviously not a "clean" file as provided by kernel.org's distribution of the kernel 2.4.18 source. It has been modified by another patch (feature) that our TLT kernel supports. I sent the two files, the .rej and the original (from our tree) in = order for the owner of the "Scalability -Locking primitives- peel off dcache = lock" to see what the other patch added and probably modify the patch to = accommodate the changes done by the other patch (we applied) to the dcache.h file. -- Tariq =A4 -----Original Message----- From: Maneesh Soni [mailto:ma...@in...]=20 Sent: Friday, June 21, 2002 1:31 AM To: Shureih, Tariq; Hanna Linder Cc: 'be...@us...'; 'yo...@us...'; 'kh...@us...'; 'Lisa = Perry'; 'lse...@li...'; Whalen, Mauri; Peddibhotla, Rammohan Subject: Re: [Lse-tech] [normal] - Scalability (Locking primitives - = peel off dcache lock ) not integrated Hi Tariq, hanna There cannot be a conflict between these two patches, atleast in=20 include/linux/dcache.h file simply because it is not a common file = between the=20 two patches. Both patches are independent and not related. But it is = true that both patches need rcu frame-work patch (not there yet) to get them build. I also tried to apply both patches on 2.4.18 kernel (from kernel.org) = and found=20 that when patch 2 is applied after patch 1, both apply cleanly. And not = very cleanly in the reverse order.=20 Now the conflict you are seeing after applying patch 1 (Fast_walk+dcache_rcu...) could be because of some other patch applied on clean 2.4.18 (from kernel.org) src tree.=20 The dcache.h file you sent is not same as in clean 2.4.18 kernel. And = as=20 fast_walk+dcache_rcuA2-2.4.18.patch was built for clean 2.4.18 src = tree, the conflict has to be resolved manually.=20 As you seem not able to do it I have done that for you this time. I = could not=20 generate a new patch for TLT kernel build so I have just modified the dcache.h=20 file you have sent. Please find the file attached to this mail. Regards, Maneesh PS: I will be leaving for OLS today so will not access this emailid = till=20 2nd Jul. On Thu, Jun 20, 2002 at 03:19:19PM -0700, Shureih, Tariq wrote: > All: >=20 > =20 >=20 > I received the Locking primitives - peel off dcache lock and = attempted to > integrate it into our TLT kernel build. >=20 > =20 >=20 > The download site included two (2) patches: >=20 > 1- Fast_walk+dcache_rcuA2-2.4.16.patch.gz >=20 > 2- Files_struct_rcu-2.4.18-07.patch.gz >=20 > =20 >=20 > Patch 2 depends on patch 1 to be applied first. >=20 > =20 >=20 > Patch 2 applies just fine; however, patch 1 does not and conflicts = with > another feature in our source tree. Upon trying to resolve it, it = turned > out that some knowledge is required I do not have. >=20 > =20 >=20 > The conflict is in one file = "linux-2.4.18/src/include/linux/dcache.h". =20 >=20 > I attached the original file from our source tree as well as the > "dcache.h.rej" file showing the area of conflict. >=20 > =20 >=20 > This feature will not be in the build. >=20 > =20 >=20 > Bugzilla item number: 582 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > ^-^-^-^-^-^-^-^- >=20 > Tariq Shureih >=20 > Software Engineering & Integration >=20 > Intel Corporation -- TSP >=20 > (503) 677-6776 >=20 > tariq.shureih@Intel.com <mailto:tariq.shureih@Intel.com>=20 >=20 > =20 >=20 --=20 Maneesh Soni IBM Linux Technology Center,=20 IBM India Software Lab, Bangalore. Phone: +91-80-5044999 email: ma...@in... http://lse.sourceforge.net/locking/rcupdate.html |