From 70d256d2bd3fea95898383e7bcf6e90442cb6069 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 16 Mar 2011 03:14:36 +0100 Subject: gsoc/ideas/diskfs_locking: Revert wording change The new wording actually changes the meaning, to one which is wrong. The most frequent cause of Hurd hangs are probably ext2fs hangs; but they are *not* necessarily all caused by locking problems. (Actually most of them used to be caused by exec issues at some point... Though I'm not sure about the current situation.) Making it less diskfs-specific is probably useful though. This needs some further consideration. --- community/gsoc/project_ideas/libdiskfs_locking.mdwn | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 0e38b6a0..74937389 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -11,12 +11,8 @@ License|/fdl]]."]]"""]] [[!meta title="Fix libdiskfs Locking Issues"]] -Every now and then, new locking issues are discovered in -[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example. Nowadays -these in fact seem to be the most often encountered cause of Hurd crashes -/ lockups. - -One of these could be traced +Nowadays the most often encountered cause of Hurd crashes seems to be lockups +in the [[hurd/translator/ext2fs]] server. One of these could be traced recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken and not released in some cases. There is reason to believe that there are more faulty paths causing these lockups. -- cgit v1.2.3 From 99b52de704d58fd8bb6c5c65d500fb9812c8f873 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 16 Mar 2011 03:29:06 +0100 Subject: gsoc/ideas: Add back () to function names IMHO it's clearer that way -- especially in browsers that don't display all text attributes, i.e. all text mode browsers. --- community/gsoc/project_ideas/secure_chroot.mdwn | 2 +- community/gsoc/project_ideas/valgrind.mdwn | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index 57739861..bfaf330b 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] [[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a -`chroot` [[system call]]. However, the current implementation is not really +`chroot()` [[system call]]. However, the current implementation is not really good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 79c8bd1d..5fa748ff 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -33,14 +33,14 @@ Compared to Linux, [[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps. Almost all [[system call]]s are implemented as [[RPC]]s instead -- either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]]. -All RPCs use a pair of `mach_msg` invocations: +All RPCs use a pair of `mach_msg()` invocations: one to send a request message, and one to receive a reply. -However, while all RPCs use the same `mach_msg` trap, +However, while all RPCs use the same `mach_msg()` trap, the actual effect of the call varies greatly depending on which RPC is invoked -- -similar to the `ioctl` call on Linux. +similar to the `ioctl()` call on Linux. Each request thus must be handled individually. -Unlike `ioctl`, +Unlike `ioctl()`, the RPC invocations have explicit type information for the parameters though, which can be retrieved from the message header. By analyzing the parameters of the RPC reply message, -- cgit v1.2.3 From 39692274c2a2a4fdab1ad49e37ec8088002b0caf Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 16 Mar 2011 03:40:12 +0100 Subject: gsoc/ideas: Drop autogenerated link list I don't see the point of having this redundant list. What's more, the autogenerated list is problematic for a number of reasons -- which is why I had switched to manually listing each task in the first place... --- community/gsoc/project_ideas.mdwn | 7 ------- 1 file changed, 7 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 030c18f3..a574192a 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -76,13 +76,6 @@ will assist you as well as we can. See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/Hurd_Porting). -Here is a list of what we consider suitable tasks: - -[[!map show=title pages="(community/gsoc/project_ideas/* and - !community/gsoc/project_ideas/*/*) or tagged(gsoc-task)"]] - -Here are these pages' content: - [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] -- cgit v1.2.3 From e2c45c18055f6bd2613dc2bd694e70e806e15698 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 16 Mar 2011 03:50:17 +0100 Subject: gsoc/ideas: Drop locking validity task for now It's probably too vague. Not sure it can be made any better -- perhaps just mention this aspect in the testing framework task instead?... --- community/gsoc/project_ideas.mdwn | 1 - 1 file changed, 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index a574192a..12074168 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -82,7 +82,6 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] -- cgit v1.2.3 From 0729272db4fe4563fee46488236d75e9c4700eee Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 24 Mar 2011 22:55:40 +0100 Subject: gsoc/ideas: Proper task description for "automated testing" --- community/gsoc/project_ideas.mdwn | 2 +- .../gsoc/project_ideas/testing_framework.mdwn | 55 ++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 community/gsoc/project_ideas/testing_framework.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 12074168..8d31ed7f 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -103,7 +103,7 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] -[[!inline pages="open_issues/unit_testing" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/testing_framework" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/testing_framework.mdwn b/community/gsoc/project_ideas/testing_framework.mdwn new file mode 100644 index 00000000..0448bc6b --- /dev/null +++ b/community/gsoc/project_ideas/testing_framework.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Automated Testing Framework"]] + +Hurd development would benefit greatly from automated tests. +Unit tests should be added for all the major components +(Mach; Hurd servers and libraries). +Also, functional tests can be performed on various levels: +Mach; individual servers; and interaction of several servers. + +(The highest level would actually be testing libc functionality, +which in turn uses the various Hurd mechanisms. +glibc already comes with a test suite -- +though it might be desirabe to add some extra tests +for exercising specific aspects of the Hurd...) + +Our page on [[automated testing|open_issues/unit_testing]] collects some relevant material. + +The Goal of this task is to provide testing frameworks +that allow automatically running tests +as part of the Hurd and Mach build processes. +The student will have to create the necessary infrastrucure, +and a couple of sample tests employing it. +Ideally, all the aspects mentioned above should be covered. +At least some have to be ready for use and upstream merging +before the end of the summer. + +(As a bonus, +in addition to these explicit tests, +it would be helpful to integrate some methods +for testing [[locking validity|open_issues/locking]], +performing static code analysis etc.) + +This task probably requires some previous experience +with unit testing of C programs, +as well as dealing with complex build systems. +No in-depth knowledge about any specific parts of the Hurd should be necessary, +but some general understanding of the Hurd architecture +will have to be aquired to complete this project. +This makes it a very good project +to get started on Hurd development :-) + +Possible mentors: ? + +Exercise: Create a program performing some simple test(s) on the Hurd or Mach code. +It doesn't need to be integrated in the build process yet -- +a standalone progrem with it's own Makefile is fine for now. -- cgit v1.2.3