Re: [LTP] [PATCH] lib: add tst_rh_kvercmp to test RHEL kernel version

Re: [LTP] [PATCH] lib: add tst_rh_kvercmp to test RHEL kernel version

[chrubis]

Hi!
> Add an additional kernel version field compare is more sane.
> But the RHEL version number like "2.6.18-248" is not common.
> So we add this specific version number check function *_rh_*
> only for RHEL use. Further more, we can add addition specific
> kernel version number check functions for SLES and so on if needed.

What is the expected usage?

Do we have a test that started to fail due to change that has been
introduced in some RHEL kernel update that changed only the last number
in version?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] lib: add tst_rh_kvercmp to test RHEL kernel version

[chrubis]

Hi!
> Yes, for inotify04 on RHEL5. Below commit is back-ported to RHEL5 updated
> version, so then inotify will send IN_ATTRIB events when link count changes.
> But in test case, we only judge the kernel version 2.6.25 to add IN_ATTRIB
> event.

> commit ece95912db94d98e202cbedb8f35206deb29d83d
> Author: Jan Kara <jack@suse.cz>
> Date:   Wed Feb 6 01:37:13 2008 -0800

<snip>

> RHEL5 changelog:
> - [fs] inotify: send IN_ATTRIB event on link count changes (Eric Paris ) [471893]
> 
> 
> The man page of inotify said that:
> IN_ATTRIB         Metadata changed, e.g., permissions, timestamps, extended attributes, link count (since Linux 2.6.25), UID, GID, etc. (*).
> 
> So, in the test case, we judge that if the kernel version is less than 2.6.25, we
> assume that the IN_ATTRIB will not be sent in the event. But after back-port
> this patch, RHEL5 includes this event when the link count changes.
> 
> There are many test cases are suffering such situation, because sometimes the patch
> back-port may break our kernel version check. So I considering introduce some
> vendor specific kernel version check like RHEL and SLES.

So the case here is that the test is disabled because the we think that
it will not work. I'm fine with adding more information to the
tst_kvercmp() but we should do it more extensible and data driven
manner.

What about we create an array with extra version strings per
distribution that gets passed to tst_kvercmp2() function and is used
when particular distribution is detected?

Roughly something as:

In the LTP lib:

struct tst_kern_extraver {
	char *dist_name;
	char *extra_ver;
};

int tst_kvercmp2(int r1, int r2, int r3, struct tst_kern_extraver *vers);


In the testcase:

static struct tst_kern_extraver exver[] = {
	{"RHEL6", "234"},
	{"SLES10", "0.91"},
	{NULL, NULL}
};


...

	if (tst_kvercmp2(2, 6, 25, exver) < 0)
		...
...


-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] lib: add tst_rh_kvercmp to test RHEL kernel version

[chrubis]

Hi!
> > So the case here is that the test is disabled because the we think that
> > it will not work. I'm fine with adding more information to the
> > tst_kvercmp() but we should do it more extensible and data driven
> > manner.
> > 
> > What about we create an array with extra version strings per
> > distribution that gets passed to tst_kvercmp2() function and is used
> > when particular distribution is detected?
> 
> RHEL kernel with a suffix like ".el5" on RHEL5 and ".el6" on RHEL6,
> I wonder how to detect SLES kernels?

We can use '/proc/version' and '/etc/SuSE-release' to identify SUSE
kernel running on the top of SLES userspace, which should be good enough
heuristics.

I can write that part of the code once we have the code for RHEL in
place.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list