Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Thu, Sep 20, 2007 at 09:50:42PM -0700, Randy Dunlap wrote: > so kernel sample code goes in the new samples/ directory, > and userspace sample code gets pushed to util-linux ? I'm not sure we want to have purely sample code in util-linux, but rather extended sample code that makes some use. So if you're writing user space sample code for your new feature make sure it's somewhat production quality, has a useful interface and write a little manpage for it. That'll also help us to win sysdamins hearts back because BSD and solaris already have all these neat little tools that need to be hacked from scratch in perl on Linux. For kernel code a samples dir might make sense because say a demo of the firmware loader (one of those things in Documentation/ right now) of course never can be "real" code. OTOH a fork probe as provided with the tracing code sounds more like a real thing that should go into drivers/misc/. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Thu, 20 Sep 2007 21:50:42 -0700 Randy Dunlap wrote: > On Wed, 19 Sep 2007 20:01:15 +0200 Sam Ravnborg wrote: > > > On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: > > > On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: > > > > > Well, this is kernel code - so util-linux is not the solution here > > > > > obviously :) > > so kernel sample code goes in the new samples/ directory, > and userspace sample code gets pushed to util-linux ? > > > > > Can you sketch what you have in mind. > > > > We right now have said we wnated to: > > > > 1) include a framework for executing simple new-syscall-test-stubs > > > > 2) have a nice place for kernel example code > > > > > > > > I could come up with something but I expect you already have something > > > > in your mind where to put stuff. > > > > If I have a rough idea I can start looking into the kbuild bits of it. > > > > Not that I will have it ready within the next two weeks but nice buffer > > > > when I anyway drop sleeping.. > > > > > > I think for samples we just want a samples/ toplevel directory with > > > normal Kbuild and Kconfig files. Not any different from drivers or > > > filesystems, just a new hiearchary. > > > > OK - anyone can do this. So I will not worry. I began looking into this. Yes, we should add Makefile(s) so that sample code can be built. Does that mean that it has to be moved to a different directory? For some (not all) sample code, we either move its related txt or README file to the samples/ dir also, or we create the need to look in 2 places to see the sample code + related doc. The latter is not good, so I suppose that we move those related txt files with the sample code. Then we have docs split into 2 places (not counting drivers/ and fs/ .txt files & other README* files throughout the kernel tree). Having docs split into more places isn't good either. I'm for just add Makefile(s) in the Documentation/ tree so that sample code can be built there (as well as moving the sample code out of .txt files and into standalone source files). I'll back up and re-read where this (new) requirement is coming from. [reads] It seems to mostly be about having the ability to build the sample code so that it doesn't bitrot. That's good. But docs and sample code are often very related. I don't see why we would arbitrarily split them up. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Thu, 20 Sep 2007 21:50:42 -0700 Randy Dunlap wrote: On Wed, 19 Sep 2007 20:01:15 +0200 Sam Ravnborg wrote: On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: Well, this is kernel code - so util-linux is not the solution here obviously :) so kernel sample code goes in the new samples/ directory, and userspace sample code gets pushed to util-linux ? Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. I think for samples we just want a samples/ toplevel directory with normal Kbuild and Kconfig files. Not any different from drivers or filesystems, just a new hiearchary. OK - anyone can do this. So I will not worry. I began looking into this. Yes, we should add Makefile(s) so that sample code can be built. Does that mean that it has to be moved to a different directory? For some (not all) sample code, we either move its related txt or README file to the samples/ dir also, or we create the need to look in 2 places to see the sample code + related doc. The latter is not good, so I suppose that we move those related txt files with the sample code. Then we have docs split into 2 places (not counting drivers/ and fs/ .txt files other README* files throughout the kernel tree). Having docs split into more places isn't good either. I'm for just add Makefile(s) in the Documentation/ tree so that sample code can be built there (as well as moving the sample code out of .txt files and into standalone source files). I'll back up and re-read where this (new) requirement is coming from. [reads] It seems to mostly be about having the ability to build the sample code so that it doesn't bitrot. That's good. But docs and sample code are often very related. I don't see why we would arbitrarily split them up. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Thu, Sep 20, 2007 at 09:50:42PM -0700, Randy Dunlap wrote: so kernel sample code goes in the new samples/ directory, and userspace sample code gets pushed to util-linux ? I'm not sure we want to have purely sample code in util-linux, but rather extended sample code that makes some use. So if you're writing user space sample code for your new feature make sure it's somewhat production quality, has a useful interface and write a little manpage for it. That'll also help us to win sysdamins hearts back because BSD and solaris already have all these neat little tools that need to be hacked from scratch in perl on Linux. For kernel code a samples dir might make sense because say a demo of the firmware loader (one of those things in Documentation/ right now) of course never can be real code. OTOH a fork probe as provided with the tracing code sounds more like a real thing that should go into drivers/misc/. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Wed, 19 Sep 2007 20:01:15 +0200 Sam Ravnborg wrote: > On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: > > On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: > > > > Well, this is kernel code - so util-linux is not the solution here > > > > obviously :) so kernel sample code goes in the new samples/ directory, and userspace sample code gets pushed to util-linux ? > > > Can you sketch what you have in mind. > > > We right now have said we wnated to: > > > 1) include a framework for executing simple new-syscall-test-stubs > > > 2) have a nice place for kernel example code > > > > > > I could come up with something but I expect you already have something > > > in your mind where to put stuff. > > > If I have a rough idea I can start looking into the kbuild bits of it. > > > Not that I will have it ready within the next two weeks but nice buffer > > > when I anyway drop sleeping.. > > > > I think for samples we just want a samples/ toplevel directory with > > normal Kbuild and Kconfig files. Not any different from drivers or > > filesystems, just a new hiearchary. > > OK - anyone can do this. So I will not worry. > > > > tests stuff was rather disliked by Linus, so I wonder wether we should > > go ahead with it. > I heard it like "Ok for new syscalls". > > And it is resonable for new syscalls because: > o Make the test of the syscall public > o Is a nice example of the usage of the syscalls (both good and bad cases) > o Is availbale for other platforms that plan to implement the same syscall > o We (at least a few sufficiently skilled ones) will then review not only > the syscall but also the use of the syscall That's a good idea/plan. > > We'd need a test driver like expect to driver the > > testcases. > OK - may give it a spin one day. > But I hope someone that have done similar stuff can come > with some example code we can adapt to the kernel. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Wed, 19 Sep 2007 20:01:15 +0200 Sam Ravnborg wrote: On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: Well, this is kernel code - so util-linux is not the solution here obviously :) so kernel sample code goes in the new samples/ directory, and userspace sample code gets pushed to util-linux ? Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. I think for samples we just want a samples/ toplevel directory with normal Kbuild and Kconfig files. Not any different from drivers or filesystems, just a new hiearchary. OK - anyone can do this. So I will not worry. tests stuff was rather disliked by Linus, so I wonder wether we should go ahead with it. I heard it like Ok for new syscalls. And it is resonable for new syscalls because: o Make the test of the syscall public o Is a nice example of the usage of the syscalls (both good and bad cases) o Is availbale for other platforms that plan to implement the same syscall o We (at least a few sufficiently skilled ones) will then review not only the syscall but also the use of the syscall That's a good idea/plan. We'd need a test driver like expect to driver the testcases. OK - may give it a spin one day. But I hope someone that have done similar stuff can come with some example code we can adapt to the kernel. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: > On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: > > > Well, this is kernel code - so util-linux is not the solution here > > > obviously :) > > > > Can you sketch what you have in mind. > > We right now have said we wnated to: > > 1) include a framework for executing simple new-syscall-test-stubs > > 2) have a nice place for kernel example code > > > > I could come up with something but I expect you already have something > > in your mind where to put stuff. > > If I have a rough idea I can start looking into the kbuild bits of it. > > Not that I will have it ready within the next two weeks but nice buffer > > when I anyway drop sleeping.. > > I think for samples we just want a samples/ toplevel directory with > normal Kbuild and Kconfig files. Not any different from drivers or > filesystems, just a new hiearchary. OK - anyone can do this. So I will not worry. > tests stuff was rather disliked by Linus, so I wonder wether we should > go ahead with it. I heard it like "Ok for new syscalls". And it is resonable for new syscalls because: o Make the test of the syscall public o Is a nice example of the usage of the syscalls (both good and bad cases) o Is availbale for other platforms that plan to implement the same syscall o We (at least a few sufficiently skilled ones) will then review not only the syscall but also the use of the syscall > We'd need a test driver like expect to driver the > testcases. OK - may give it a spin one day. But I hope someone that have done similar stuff can come with some example code we can adapt to the kernel. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Test harness in the kernel for new syscalls? [Was: Trace code and documentation (updated)]
On Wed, Sep 19, 2007 at 06:51:09PM +0100, Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: Well, this is kernel code - so util-linux is not the solution here obviously :) Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. I think for samples we just want a samples/ toplevel directory with normal Kbuild and Kconfig files. Not any different from drivers or filesystems, just a new hiearchary. OK - anyone can do this. So I will not worry. tests stuff was rather disliked by Linus, so I wonder wether we should go ahead with it. I heard it like Ok for new syscalls. And it is resonable for new syscalls because: o Make the test of the syscall public o Is a nice example of the usage of the syscalls (both good and bad cases) o Is availbale for other platforms that plan to implement the same syscall o We (at least a few sufficiently skilled ones) will then review not only the syscall but also the use of the syscall We'd need a test driver like expect to driver the testcases. OK - may give it a spin one day. But I hope someone that have done similar stuff can come with some example code we can adapt to the kernel. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
