On 2/25/10, Garrett Cooper <[email protected]> wrote: > On Thu, Feb 25, 2010 at 1:33 AM, Rishikesh K Rajak > <[email protected]> wrote: >> On Thu, Feb 25, 2010 at 02:39:37PM +0530, Silesh C V wrote: >>> >> >>> >> The end goal is to have these tests fit directly into LTP without >>> >> having to fudge around writing a secondary driver, thus maintaining >>> >> two pieces of dependent code [which is of course more complicated than >>> >> one piece of code], and thus is more of a pain to maintain longterm. >>> >> There's a lot of code in the repository like this that was ported and >>> >> subsequently not properly adapted to the existing infrastructure, thus >>> >> creating additional headache for maintainers and end-users. >>> > >>> > Ok -- I take that back. I have no idea wtf is going on in this >>> > directory nor the ultimate intent of the tests in here, apart from >>> > being a lot of ad hoc pain in the arse-ness. >>> >>> The README in testcases/kernel/device-drivers/ says that these tests >>> should not be run with the other tests, and they have to be built >>> separately. I agree that this is because they have a kernel space part >>> also. But this prevents us from building device_driver tests that >>> have only user space part (as in RTC tests), along with the overall >>> build. And these tests does not belong in any other directory other >>> than kernel/device-drivers. So as long as other tests are there we >>> will have to live with building new device driver tests separately.I >>> can re-send the patch with Garrett's suggestions incorporated. >>> >>> Subrata, suggestions ? >> >> Hi Silesh, >> >> How about porting this on new makefile infrastructure ? I think this is >> time where we can look back and can make one piece of code as garret >> said is correct. Please see your fesibility. Let me know if you still >> want this to be integrated. Before that can you please little more >> descriptive with your patch e,g: what it is doing. >> >> And also it is always good if you include more documentation for each >> function as coding style suggests. > > Regardless of whether or not this can fit within the new makefile > infrastructure -- please at least consider adding in the bits to use > tst_res(3).
OK.Coming in the next patch. It will make maintenance considerably easier in the long > run. I can port a Makefile over in < 30 mins -- it's the C code that > I'd have to fumble around with as I'm not the original developer, I > may not understand all the nuances of what's trying to be tested, etc. > > More documentation would be extremely helpful, in particular pointers > to additional reference material so that someone who has _zero_ > understanding in how the rtc driver typically works in Linux can at > least look up additional materials to develop a better understanding > of what's going on... OK. Coming in the next patch. > >>> > >>> > I've learned enough to keep my hands off this because it looks like a >>> > mess. > > Thanks, > -Garrett > Thanks, Silesh ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
