diff options
32 files changed, 1542 insertions, 431 deletions
diff --git a/community.mdwn b/community.mdwn index 5421dd1f..658b604e 100644 --- a/community.mdwn +++ b/community.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 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 @@ -18,6 +18,8 @@ Further ways of getting in contact or getting information: [[Shared-Wiki-Weblog|Weblogs]] -- A shared weblog by Hurd developers and enthusiasts. +[[User Pages|/user]] + [[Meetings]] -- Meetings with Hurd developer attendance. [[GSoC]] -- Participation in the Google Summer of Code diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 875b462f..1346203d 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -31,6 +31,10 @@ Some knowledge of POSIX capabilities will need to be obtained, and for the latter part also some knowledge about the Hurd architecture. This project is probably doable without previous experience with either, though. +David Hedberg applied for this project in 2010, +and though he didn't go through with it, +he fleshed out many [[libcap/details]]. + Possible mentors: Samuel Thibault (youpi) Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn new file mode 100644 index 00000000..aa27a84e --- /dev/null +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -0,0 +1,766 @@ +[[!meta copyright="Copyright © 2010 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="Details on implementing libcap"]] + + +This is the proposal submitted by David Hedberg for GSoC 2010 (who opted +to go with another mentoring organization), adapted from an initial +proposal and several amendments into a single document, but the idea +is to further adapt it to a more neutral design document over time. + + +# The proposal + +### Quick description of POSIX capabilities + +The original suggestion can be found [[here|libcap]]. +POSIX capabilities never actually entered the POSIX standard but was +left as a draft. Linux has nevertheless implemented this draft, and +there are reasons for doing the same in the Hurd - a more fine grained +control of rights leading to increased security being one of them. + +POSIX capabilities are give on a per-process basis, and basically allows +splitting up those rights usually granted to root into smaller and more +specific rights. Examples of capabilities are CAP_CHOWN and CAP_KILL, +overriding certain restrictions on chown and allowing the process to +kill processes with different UID's, respectively. + +Each process is given three sets with capabilities: the Permitted set +(P), the Effective set (E) and the Inheritable set (I). The effective +set contains the capabilities that are currently active. The permitted +set contains the capabilities that the process has the right to use. +The inheritable set contains the capabilities that can be inherited +by children to the process. A process can drop capabilities from its +permitted set, but not set them. The effective set and the inheritable +set can be changed freely as long as they stay subsets of the permitted +set. + +Capabilities can also be set on executables. When executed, the resulting +process is given the capabilities both as defined by the parent process +and by the capabilities set on the file (formula below), resulting in +what might be explained as a fine-grained setuid. Implementing this +requires support for *xattr* or similar. + +Some applications that are currently using capabilities are samba, ntp, +vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot. + + +### A quick description of capabilities in Linux + +Each process has a three bit fields representing each of the three +sets (P, E and I). Each bit field is currently built up of two (32 +bit) integers to be able to hold the 33 currently defined capabilities +(see linux/capability.h). Each process further has a bounding set which +bounds the permitted set. Two syscalls handles the setting and getting +of capabilities; *capset* and *capget*. Some related functionality +can also be controlled by calling *prctl*: the right to read/drop the +bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether +or not the process should keep its capabilities when a change is made +to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS). User space +applications are expected(recommended?) to use libcap to take advantage +of the functionality provided. Some applications also use libcap-ng +which is "intended to make programming with POSIX capabilities much +easier than the traditional libcap library". Most applications seem +to be using the original libcap, however. + + +## Implementing libcap + +The exercise for this assignment was to get the libcap used in +Linux to compile under the Hurd. This was accomplished using the +latest git version of libcap from (..), corresponding to libcap +2.19. The changes were simple and amounted to simply removing the +dependency on some Linux-specific headers and creating stubs for +capset, capget and prctl described above. This suggests that porting +this library to the Hurd once the proper functionality is in place +could be relatively simple. The patch is available +[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth"). +One could also consider implementing the three missing functions in the +Hurd (or Hurd glibc) which would allow the usage of the Linux libcap +without modifications. As the Linux libcap maintainer might or might +not be interested in making libcap multi platform, this approach might +be preferable. + + +## Implementing POSIX capabilities in the Hurd + +As I am still reading up on how things fit together in the Hurd this is +very likely to contain some misunderstandings and be at least partly off +the mark. I intend to have grasped this by the time I start working on +it however, if I were to be given the chance. Below are two possible +approaches as I have understood them after some reading and discussions +on #hurd@freenode. + + +### The basics, Approach 1: Special UID's + +Let each capability be represented by a specific UID. One could imagine +reserving a range of the possible uid_t's for this purpose. The euids +vector in the authhandle struct could perhaps hold the effective set while +the auids vector could hold the permitted set as these seem to roughly +correspond to eachother in intent. This leaves the Inheritable set. +One solution could be to store the inheritable set in the agids vector, +but that does not seem to be a very natural nor nice solution. One could +extend the authhandle struct with an additional vector, but one would then +need to also extend the auth interface with RPC's to be able to modify +and access it. Another possibility is to store all the capabilities +in the same idvec and use separate defines for the the different sets +(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD). This does not seem like a +good solution. + +Storing each capability in its own uid_t might also arguably be somewhat +wasteful, although this is probably of secondary concern (if at all). +One could also imagine that legacy applications might be confused, +although I am not sure I can see any obvious problems. What happens +when a process have only capability id's? + + +### The basics, Approach 2: Extend the auth interface + +This approach would expand the auth interface and extend +the auth server with another set of RPC's for capabilities +(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and +*auth_server_authenticate*), mirroring those currently declared for id's. +This would obviously require changes to more parts of the Hurd for +processes to be able to take advantage of capabilities, but as the logic +behind handling capabilities and that behind handling user id's might +not be completely comparable, this might make for a cleaner solution. +It would also remove the problem of having to sensibly map all the +three capability sets onto semantically differing sets of user/group +ids, something that might be even more important if we were to also +implement something like the bounding sets used in Linux or perhaps +other related functionality. We are also not limited to having to store +the capabilities as id vectors, although doing so would perhaps still +make sense. + + +### The individual capabilities + +Implementing the individual capabilities will probably have to be thought +of on a case-by-case basis. Taking chown (in *libdiskfs*) as an example, +the exact approach would differ slightly depending on how the approach +taken to implement capabilities. If the first approach were to be taken, +the UID's (and thus the capabilities) of the caller would already be +available to the function through the *iouser* struct contained in the +*protid* struct given as the first argument. Implementing capabilities +would then simply be a matter of checking for the special UID's. If the +second approach were to be taken, one would need to perhaps expand the +iouser struct to contain information about the capabilities. + +Just like Linux has defined many Linux-specific capabilities - some of +which could certainly be useful also applied to the Hurd - one could +also imagine extending the POSIX capability system also for Hurd specific +purposes. + + +## Some applications using capabilities + +#### Samba 3 + +Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities. +Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files +from being deleted. Can also use a couple of IRIX specific capabilities +(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific +ones if running on IRIX. + + +#### ntpd + +Checks if capabilities are supported, more precisely if CAP_SYS_TIME, +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are +supported. If they are supported, it uses prctl with PR_SET_KEEPCAPS +to keep privileges across setuid() and then drops root. After done with +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except +CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE. + + +#### vsftpd + +Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process" +security model (typically disabled by default). + + +#### proftpd-basic + +Provides support for capabilities from mod_cap. Uses CAP_USE_CHOWN, +CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE. +Distribution contains README.capabilities with some explanations. +Also ships with their own libcap for some reason, based on libcap 1.10. + + +#### dovecot + +Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID, +CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops +the rest. + + +#### bind9 + +Reasons for each capability are clearly noted in comments in update.c +in linux_initialprivs() and linux_minprivs(). initialprivs drops all +capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT, +CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN. minprivs only +sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE. + + +#### pulseaudio + +Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it +(anymore?). Seems to use libcap to drop caps, however. + + +#### pinentry + +Checks if CAP_IPC_LOCK is available and "uses it" to gain only the +ability to lock memory when needed. + + +#### zsh + +Comes with a module "caps" which contains "[b]uiltins for manipulating +POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the +"cap" builtin, which makes it possible to change the shell's process +capability sets. This might be useful for testing. + + +#### inetutils (ping,traceroute) + +Does not use capabilities explicitly, but is nevertheless a useful +example of how file capabilities could be used. ping and traceroute +are currently installed suid root since they need to be able to open +raw sockets. With file capabilities, this could be accomplished by +instead setting the capability CAP_NET_RAW on the two executables, +thus giving the utilities almost only the specific rights they need. + + +## The capabilities + +The above might give some hint as to what capabilities should be +prioritized. One assumption I have made is that the goal of this project +is to implement, as far as possible, the same functionality as what is +present in Linux. No effort has (so far) been made to look into possible +applications specific to the Hurd. + +A few of the above mentioned applications also explicitly uses +PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should +be passed on to children. This means that the implementation in the +Hurd should take this into account. + +I have below done a preliminary classification of the capabilities +as defined in Linux capability.h into four "classes": Network, File +management, "glibc -> mach" and Other. There are also some capabilities +that either depend on functionality not implemented or are too Linux +specific. I have not described each capability in detail as looking +at the comments in capability.h and reading in capabilities(7) are +better sources. + + +### The Networking Class + +These would mostly affect pfinet. The general picture seem to be that +pfinet currently uses a boolean (int) isroot in struct sock_user to keep +track of the credentials of the caller. This would need to be expanded +somehow to keep track of the separate capabilities. + +CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024 +CAP_NET_RAW: Allow use of RAW and PACKET sockets. +CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast" +CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related +administration. + + +### The Files Management Class + +The description of CAP_CHOWN in the original proposal should apply to +(most of?) these. That is, modify the iouser struct. At least libdiskfs +should be modified, but the same or similar modifications might need to +be made to several servers (libnetfs..? The actual servers implementing +the filesystem?) + +CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs" +CAP_FOWNER: allow chmod, utime, .. for files not owned. +CAP_FSETID: Don't clear setuid/setgid when a file is modified. +CAP_DAC_OVERRIDE and +CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission +checks. ( hurdexec.c, file-access.c, .. ? ) +CAP_MKNOD: allows usage of "the privileged aspects of mknod()". Does this +one make sense in the Hurd? + + +### The (glibc -> gnumach) Class + +These seem to be implemented in glibc by direct calls to gnumach. +If they should be implemented, maybe a proxy in the Hurd is needed? + +CAP_SYS_TIME: manipulate the system clock, set real-time clock. +CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl +CAP_KILL: No permission checks for killing processes +CAP_SYS_NICE: setpriority/getpriority for arbitrary processes. + + +### The Rest Class + +CAP_SYS_CHROOT: Allows usage of chroot(). +It's either really simple (not needed in the case of the Hurd) or really +difficult. Needs some figuring out. One of the calls that should be +high-priority. +CAP_SYS_ADMIN: General administration rights. Seemingly sprinkled out +into just about everything. Quick grep through the Linux sources gives +440 hits in .c-files. +CAP_SYS_BOOT: Allow use of reboot(). +glibc calls init:startup_reboot.. +CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket +credentials passing" +CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials +passing" +CAP_SYS_TTY_CONFIG: vhangup, some other places. vhangup() is a stub in +the Hurd, but maybe the console server is otherwise affected? +CAP_SYS_RESOURCE: Override various limits. (quota, reserved space etc. +on ext2, interrupt frequencies, consoles,...). According to "The Critique" +mach performs no resource accounting so some of these might be moot to +implement, while others still apply. +CAP_SYS_RAWIO Allow raw input/output. Sprinkled in many places, +device drivers among others. Many of these will probably be difficult +to implement. +CAP_SETPCAP: This one has (or had?) two different usages in Linux: +If file capabilities are not supported it gives the right to grant +or remove capabilities from the permitted set of arbitrary processes. +If file capabilities are supported, it allows for removing capabilities +from the bounding set of the current process. As the Hurd implementation +won't have file capabilities initially it might make sense to implement +this if possible. If bounding sets are implemented this should probably +be the way provided to modify them. + + +### Unimplementable + +*(At this point in time, as far as I can determine)* + +CAP_LINUX_IMMUTABLE: depends on chattr etc. working. +CAP_SETFCAP: depends on xattr's +CAP_SYS_PACCT: acct() missing in the Hurd. +CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN, +CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE + + +## Priority when implementing + +The two most used capabilities as unscientifically judged from +the selection of applications above are CAP_NET_BIND_SERVICE and +CAP_CHOWN, suggesting that implementing the "network class" and the +"file management" class of capabilities as classified above might be a +good start. These also, to me, seem to be easier classes to implement. +CAP_NET_ADMIN might need some extra work. + +Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am +not completely clear on how these should be handled. + +Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL +and CAP_SYS_NICE might be a good choice to tackle if possible. This +might, if I have understood things correctly, involve writing a proxy +Hurd server for these calls in mach. + +CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit +of "everything" (ADMIN being the worse one), meaning that experience +and infrastructure gained from implementing the previous capabilities +might come in handy. CAP_SYS_RAWIO might be difficult; it can be found +inside many drivers in the Linux source. + + +## Additional general details + +[This article](http://www.ibm.com/developerworks/library/l-posixcap.html) +contains a good general description of how capabilities in Linux +works. As there will be no file capabilities in the Hurd initially, +an approach emulating the behavior Linux exhibits when SECURE_NOROOT +and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start. +This is called the "root-user-is-privileged" model in the article, +and somewhat simplified it means that processes started by root, or +setuid-root, is given all capabilities no matter what capabilities the +parent might or might not hold at the time of execution. Quoting verbatim +from the article: + +> * When SECURE_NOROOT is not set, then when a process executes a file, +> the new capability sets may be calculated as though the file had some +> file capability sets set fully populated. In particular: +> +> * The file inheritable and permitted sets will be full on if the +> process's real or effective uid is 0 (root) or the file is setuid +> root. +> +> * The file effective set will be full on if the process's effective +> uid is root or the file is setuid root. +> +> +> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches +> its real or effective uids to or from 0, capability sets are further +> shifted around: +> +> * If a process switches its effective uid from 0 to non-0, then its +> effective capability set is cleared. +> +> * If a process switches its real, effective, or saved uids from at +> least one being 0 to all being non-zero, then both the permitted +> and effective capabilities are cleared. +> +> * If a process sets its effective uid from non-zero to 0, then the +> effective capabilities are set equal to the permitted capabilities. + +The capabilities of the resulting process are determined by the following +formulas, again taken from the article, with p for Process and f for file: + +> pI' = pI +> pP' = fP | (fI & pI) +> pE' = pP' & fE + +The security under the above described model, being what at least some +of the applications I listed in my last comment employs, is basically +the following (also detailed somewhat in the same article): + +* Execute process as root (or setuid) to gain all capabilities. + +* Use the prctl system call to enable keepcaps for the process + (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). + keepcaps should be off by default. + +* setuid to a non-root user, and by doing so losing the possibility to + regain capabilities by simply starting a new process. + +* Drop all the capabilities except those few actually needed. + + +## Infrastructure details - Special UIDs approach + +The auth server must somehow keep track of three sets of capabilities. +I suggest keeping these three sets in three additional idvec's in the +authhandle struct, and will for the purpose of this description name +these pcaps (permitted), ecaps (effective) and icaps (inheritable). +This will simplify keeping track of the internal logic somewhat. +In addition to this, there is a need to keep track of the "keepcaps" flag +as described above. I suggest representing this with an int keepcaps +in the same struct. + +1. Expand authhandle struct with three additional idvecs and one integer. +Fix static functions handling the struct, such as destroy_authhandle. + +2. Implement the necessary logic in auth_makeauth to handle capabilities. + +Problems: +Assume that all capabilities are mapped onto uids, given names on the form +uid_<capability>, for example uid_cap_net_raw. Assume that the presence +of an uid in euids suggest that the capability is in the effective set +of the process, that the presence of this uid in auids suggests that it +is in the permitted set of the process, and that the presence of this +uid in aguids suggest that it is in the inheritable set of the process. +That they are internally stored in separate idvec's can be ignored as +an implementation detail. + +* The UID's have as it is different meanings depending on where in the + array they are positioned, and certain clients seem to rely on this. + The first UID in euids is the effective uid, and the first and second + UIDs in auids are the real and saved UIDS respectively. At least + some users of makeauth would need to made aware of capabilities, + for example setuid in glibc. + +* Setting/getting the keepcaps-flag is also a bit of a problem. To avoid + changing the auth interface yet another special UID could be used + for this purpose, although that seems to be really stretching it. + The cleaner solution would probably be to expand the interface with + something along the lines of auth_setkeepcaps/auth_getkeepcaps. + This interface would only be used by prctl. + +Another problem with this approach is that it seems a bit difficult +to oversee the affects that using other RPC's like fsys_getroot and +io_restrict_auth might have on capabilities. + + +## Infrastructure details - "extend-interfaces" approach + +This approach has started to seem like the better way to me, as the +usage of capabilities becomes more explicit through the entire "chain", +perhaps making it somewhat more easy to understand all the interactions. + +I suggest something like the following new interface methods: + +*** + + +### The auth interface + + routine auth_getauth_caps ( + handle: auth_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + routine auth_makeauth_caps ( + handle: auth_t; + other_handles: portarray_t; + euids: idarray_t; + auids: idarray_t; + egids: idarray_t; + agids: idarray_t; + ecaps: idarray_t; + pcaps: idarray_t; + icaps: idarray_t; + flags: int; /* keepcaps.. ? */ + out newhandle: mach_port_make_send_t); + + routine auth_server_authenticate_caps ( + handle: auth_t; + sreplyport reply: mach_port_poly_t; + rendezvous: mach_port_send_t; + newport: mach_port_poly_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + +### The io interface + + routine io_restrict_auth_caps ( + io_object: io_t; + RPT + out new_object: mach_port_send_t; + uids: idarray_t SCP; + gids: idarray_t SCP; + ecaps: idarray_t SCP); + + +### The fsys interface + + routine fsys_getroot_caps ( + fsys: fsys_t; + RPT + #ifdef FSYS_GETROOT_UREPLY + ureplyport ureply: mig_reply_port_t; + #endif + dotdot_node: mach_port_send_t; + gen_uids: idarray_t; + gen_gids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t; + flags: int; + out do_retry: retry_type; + out retry_name: string_t; + out file: mach_port_send_t); + +*** + +These are meant to be able to replace the old methods with +capability-aware methods, instead of merely complementing them. +The replacing work could then be made a more gradual process. Steps: + +* Extend authhandle with the same data members as in the UID-case. + +* Implement new _caps-functions according to described interface + extensions above, refactor code a bit to share common uid-handling + logic. Both makeauth's should drop all capabilities if switching from + uid 0 without having keepcaps. For example, keepcaps should be unset + by default. + +* Fix glibc. Extend hurd_id_data in hurd/id.h to store capabilities, + switch to capability aware functions where necessary. + +* io-reauthenticate. Fix implementations to use + auth_server_authenticate_caps instead. For this we also need somewhere + to save the caps, so it ties in with for example the extension of + iouser as mentioned in the details. + +* fsys_getroot. Implement fsys_getroot_caps in libdiskfs, trans, + libtreefs, libtrivs, libnetfs. Fix users of function in libdiskfs, + libfshelp, settrans, libtreefs, clookup. + +* io_restrict_auth. Implement io_restrict_auth_caps in libdiskfs, + libtreefs, libtrivfs, libnetfs, boot. Fix users in utils(symlink, + firmlink), libtrivs, term, clookup + +Among the problems might be that there are a lot of arguments that +needs to be passed around, and that it seems somewhat ugly to end up +with function names referencing caps in particular. + +Below some more about the specific capabilities. This should in large +be common to the two approaches above. + + +## Actually handing out the capabilities to process + +This seems like a good job for the file_exec route in the fs interface. +Quoting from the comments above the definition in fs.defs: "*Necessary +initialization, including authentication changes associated with set[ug]id +execution must be handled by the filesystem*". The capability-granting +functionality should to be added in at least the implementations in +libdiskfs and libnetfs as far as I can determine, and should be "easy +enough" once the infrastructure for implementing the file-related +capabilities (CAP_CHOWN etc.) are in place. This also seem to make +sense considering the future possibility for file capabilities. + + +## Some implementation details of individual capabilities. + +### Net-related capabilities. + +This turned out to be a bit less work than I had thought, as the +imported Linux code already seem to contain all the necessary checks. +What remains to do to implement all of these capabilities is mostly a +matter of putting some infrastructure in place. + +* In struct sock_user (pfinet.h), change isroot for idvec + caps. Alternatively, add idvec caps. + +* Change the function make_sock_user in socket.c to take an idvec caps + as a parameter and properly set the given caps to the corresponding + idvec in sock_user. + +* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth, + S_socket_create, S_socket_accept. This should be doable with the + current infrastructure. For example, S_socket_create currently + sets isroot in the new sock_user from the corresponding member in + the trivfs_protid struct. This does not present a problem however, + as the latter struct also provides access to an iouser (iohelp.h) + from which the needed uids of the user should be available. + +* Fix up parts of source from Linux, modify task_struct add idvec, + modify prepare_current to take the caps idvec instead of isroot. + Re-implement the existing function capable(int cap) to actually check + for the capability passed as an argument instead of just return isroot. + +* Change a few isroot's at 3 other places in the code to check for + capabilities. Since these places all have access to isroot and thus by + implication the sock_user, they also have access to the new capability + information; no restructuring necessary. + + +### File-related capabilities + +While there are a lot of servers in the Hurd, I am not sure all of these +capabilities actually make sense to implement in all of them. + + +#### CAP_CHOWN + +Implementing this in libdiskfs should take care of it where it makes +sense. Servers using libdiskfs uses iouser from libiohelp to hold +user credentials. As noted above, this struct is already capable of +holding our capabilities as uid's or is otherwise extended to contain +the necessary idvecs if using the second general approach. Adding a +check along the lines of *idvec_contains(uid_cap_chown)* in function +diskfs_S_file_chown (file-chown.c) should be all that's needed. + +In libnetfs, netfs_attempt_chown is declared as a function that the +server using the library must implement. Any checks for chown rights +are however most likely performed on the server side, suggesting that +there is nothing we can do here to implement CAP_CHOWN. Even if we do +need to add something, an iouser containing the necessary information +to implement the checks in a manner analogous to that in libdiskfs seems +to be passed to each important function. + + +#### CAP_DAC_* + +These might actually make sense to implement in more servers, and the +logic seems somewhat involved. Need to add the necessary checks to +at least file_check_access, file_exec in libdiskfs. file_exec also in +libnetfs, probably. Possibly changes also in other places. + +The main difficulties overall seem to lie in getting the infrastructure +properly in place rather than implementing most of the individual +capabilities, and I have updated the schedule a bit in an attempt to +reflect this. + + +## Schedule updating + +The more I look into this the less time it seems likely to take to +do the work. Below is my best estimation at the moment, and I have +basically adjusted everything to what I think is more likely estimations. +If this is correct I would be more or less around midterm. I haven't +gone completely to the individual level as that doesn't seem to make +sense, but what is clustered together are either related capabilities +or a collection of capabilities classified roughly with regards to how +much I know about the area and how many different rights they control. +It's not my intention to "slack off" or anything, so if this estimation +were to be correct I could perhaps take a look at the xattrs-patch, +or spend the rest of my time fixing PATH_MAX-issues. Then again, maybe +there is some great difficulty hidden somewhere. + + +#### Some justifications: + +Dummy libcap, more or less done. +*1 day* (making sure it "fails gracefully" shouldn't really take longer than this) + +Application for testing, the beginnings of a fairly extensive "test suit" on Linux. +*2 days* + +Basic infrastructure. +*5 days*, depends on the chosen approach, but it is probably wise to +reserve at least a bunch of days for this. + +Implementations of prctl/capset/capget in libshouldbeinlibc, +or a port of libcap to the Hurd in any other way. +*5 days* + +CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN +*4 days*, as noted above this should be easy, but it might uncover bugs +in the newly implemented infrastructure for example. + +CAP_CHOWN,CAP_FOWNER,CAP_FSETID +*2 days*, I think these only needs to be done in libdiskfs + +CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH +*4 days*, these might need changes to various servers + +CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL +CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT +*2 weeks*, these are varied and I'm not that sure exactly how each should +be tackled so some research is needed. + +CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +*4 days* + +CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO +*2 weeks*, these too are pretty varied and some might need some individual +researching + +CAP_SETPCAP +*1 day* + + +## Schedule + +24/5 Start coding +25/5 Dummy libcap ready for use. +27/5 The beginnings of a "test suite", written on Linux. + 1/6 Basic infrastructure in place + 6/6 Dummy libcap extended with real functionality to make use of + implemented capability and infrastructure, or the Hurd adapted for + compatibility with Linux libcap. +10/6 The "network class" of capabilities implemented. +12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID +16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH +30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE, + CAP_SYS_CHROOT, CAP_SYS_BOOT + 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +12/7 "Mentors and students can begin submitting mid-term evaluations" +16/7 GSoC Mid-term evaluations deadline. +18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO +19/7 CAP_SETPCAP diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index 735c8bbb..331336ac 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -34,7 +34,7 @@ make such a split later on feasible. This is [[!GNU_Savannah_task 5469]]. -Possible mentors: ? +Possible mentors: zhengda Exercise: You could try making some improvement to the existing pfinet implementation; or you could work towards running some existing userspace @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009 Free Software Foundation, Inc."]] +2009, 2010 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 @@ -88,6 +88,7 @@ in the *unstable* branch of the Debian archive. * RPC [[Interface]]s * Libraries * [[libpager]] + * [[libports]] * [[libstore]] * [[libchannel]] * [[libhello_example]] -- Hurd library example diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index c5dddfb6..d5beade9 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -21,10 +21,14 @@ Find it in the [[source repositories/incubator]], *cross-gnu* branch. Read through it. Understand it. Only then use it by following the next steps. -/!\ Be made aware that -- while it is of course possible to build a working -cross-compiler -- this is not trivial to do. You'll have to patch source -packages. See the following list about needed patches, which have not yet been -installed in the upstream repositories. + +## Status + +/!\ Please note that these cross toolchains does not yet encompass all of the +functionality that native toolchains provide. For example, there is only +support for C and C++ so far, but not for other languages. A bunch of fixes / +enhancements of [[glibc]] are missing. We're working towards minimizing these +differences, as well as towards pushing all patches upstream. ### Supported Versions of Source Packages @@ -34,138 +38,95 @@ guarantee is given. Always the preferred version is listed first. * `src/binutils`: [[GNU_Binutils|binutils]] - * CVS `binutils-2_19-branch` - - $ mkdir binutils-2_19-branch - $ cd binutils-2_19-branch - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ - co -r binutils-2_19-branch binutils - - The sources are rooted in `binutils-2_19-branch/src/`. Also use these - commands for updating, instead of the usual `cvs update`. - - * The 2.19 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should - also be fine. - - * CVS `binutils-2_18-branch` + * CVS `binutils-2_20-branch` - $ mkdir binutils-2_18-branch - $ cd binutils-2_18-branch + $ mkdir binutils-2_20-branch + $ cd binutils-2_20-branch/ $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ - co -r binutils-2_18-branch binutils + co -r binutils-2_20-branch binutils - The sources are rooted in `binutils-2_18-branch/src/`. Also use these + The sources are rooted in `binutils-2_20-branch/src/`. Also use the above commands for updating, instead of the usual `cvs update`. - * The 2.18 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should - also be fine, as should be all other recent releases. + * Release of the 2.20 series from <ftp://ftp.gnu.org/gnu/binutils/> + should also be fine. * `src/gcc`: [[GNU_Compiler_Collection|gcc]] - * SVN `gcc-4_1-branch` + * SVN `gcc-4_5-branch` - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch - - Prepare: + $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch - $ ( cd gcc-4_1-branch/ && contrib/gcc_update --touch ) + Patches: - * Releases of the 4.1 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine. - - * SVN `gcc-4_2-branch` - - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch - - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html> + * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html> Prepare: - $ ( cd gcc-4_2-branch/ && contrib/gcc_update --touch ) + $ ( cd gcc-4_5-branch/ && contrib/gcc_update --touch ) - * Releases of the 4.2 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine, but need the same set of patches as the `gcc-4_2-branch` - needs. + * SVN `gcc-4_4-branch` - * SVN `gcc-4_3-branch` + $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch + Patches: - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html> + * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html> Prepare: - $ ( cd gcc-4_3-branch/ && contrib/gcc_update --touch ) - - * Releases of the 4.3 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine, but need the same set of patches as the `gcc-4_3-branch` - needs. - - * SVN `trunk` -- upcoming 4.4 series + $ ( cd gcc-4_4-branch/ && contrib/gcc_update --touch ) - $ svn co svn://gcc.gnu.org/svn/gcc/trunk - - Prepare: - - $ ( cd trunk/ && contrib/gcc_update --touch ) + * Releases of the 4.5 and 4.4 series from <ftp://ftp.gnu.org/gnu/gcc/> + should also be fine, but need the same set of patches as the + `gcc-4_5-branch` needs. * `src/gnumach`: [[GNU_Mach|microkernel/mach/gnumach]] - * CVS `gnumach-1-branch` + * Git `master` branch - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd ↩ - co -r gnumach-1-branch gnumach - $ mv gnumach gnumach-1-branch + $ git clone ↩ + git://git.sv.gnu.org/hurd/gnumach.git gnumach Prepare: - $ ( cd gnumach-1-branch/ && autoreconf -vfi ) + $ ( cd gnumach/ && autoreconf -vi ) * `src/mig`: [[microkernel/mach/mig/GNU_MIG]] - * CVS `HEAD` + * Git `master` branch - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig + $ git clone ↩ + git://git.sv.gnu.org/hurd/mig.git mig Prepare: - $ ( cd mig/ && autoreconf -vfi ) + $ ( cd mig/ && autoreconf -vi ) * `src/hurd`: [[GNU_Hurd|hurd]] - * CVS `HEAD` + * Git `master` branch - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd + $ git clone ↩ + git://git.sv.gnu.org/hurd/hurd.git hurd - * `src/glibc`: [[GNU_C_Library|glibc]] - - * CVS `glibc-2_7-branch` + * `src/libpthread`: [[libpthread]] - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩ - co -r glibc-2_7-branch glibc - $ mv libc glibc-2_7-branch + * Git `tschwinge/Peter_Herbolzheimer` branch - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00030.html> + $ git clone --no-checkout ↩ + git://git.sv.gnu.org/hurd/libpthread.git libpthread + $ cd libpthread/ + $ git checkout origin/tschwinge/Peter_Herbolzheimer - * Recent releases of the 2.7 series from <ftp://ftp.gnu.org/gnu/glibc/> - should also be fine, but need the same set of patches as the - `glibc-2_7-branch` needs. - -<!-- - - * CVS `HEAD` - - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩ - co glibc - $ mv libc glibc-HEAD + * `src/glibc`: [[GNU_C_Library|glibc]] - * TODO. - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00026.html> + * Git `tschwinge/Roger_Whittaker` branch ---> + $ git clone --no-checkout ↩ + git://git.sv.gnu.org/hurd/glibc.git glibc + $ cd glibc/ + $ git checkout origin/tschwinge/Roger_Whittaker <!-- @@ -206,7 +167,7 @@ the following. The system you're running the script on (the *build* system) needs to have a basic compiling environment installed, i.e., a C compiler with the basic libraries and `make`. You might also need `flex` and `bison`. For building -recent version of GCC (e.g., the upcoming 4.3, which is not yet supported) +recent version of GCC (4.3 onwards) you'll need to have development packages of GMP and MPFR installed. @@ -235,29 +196,13 @@ flow by. In the end you should see a message: *[...]/cross-gnu: Everything should be in place now.* -### Makefile - -A [[Makefile]] has been written to automate the above steps. You will require -an Internet connection and atleast 1.5 GiB of hard-disk space. Just run... - - make - -... to build the toolchain. To clean up, use... - - make clean - - ### Staying Up-To-Date You can re-run `cross-gnu` to rebuild the parts of the sources that have changed since the last run. This will save a lot of time compared to starting from scratch again. Also, it is especially useful if you aren't working with -unpacked tarballs, but on CVS's branches or want to quickly get a new tool -chain with patches you applied to the source trees. However: do *not* use this +unpacked tarballs, but on CVS's / SVN's / Git's branches or want to quickly get +a new toolchain +with patches you applied to the source trees. However: do *not* use this technique when doing major changes to the source trees, like switching from GCC -4.0 to GCC 4.1. - - -# References - -* <http://lists.gnu.org/archive/html/bug-hurd/2004-09/msg00030.html> +4.4 to GCC 4.5. diff --git a/hurd/building/cross-compiling/Makefile b/hurd/building/cross-compiling/Makefile deleted file mode 100644 index 7a6a9524..00000000 --- a/hurd/building/cross-compiling/Makefile +++ /dev/null @@ -1,168 +0,0 @@ -# "HurdToolchainMakefile" - a Makefile for setting up Hurd toolchain builds - -# Copyright (C) 2007 Free Software Foundation, Inc. - -# This program is free software; you can redistribute it and/or modify it -# under the terms of the GNU General Public License as published by the -# Free Software Foundation; either version 2, or (at your option) any later -# version. -# -# This program is distributed in the hope that it will be useful, but -# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY -# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with this program; if not, write to the Free Software Foundation, Inc., -# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. - -# Written by Shakthi Kannan <shakthi.kannan@qvantel.com>. - - -## Variables -TOPDIR=. -DOWNLOADS=${TOPDIR}/downloads -ROOT=${TOPDIR}/root -SRC=${ROOT}/src -GLIBC_DIR=${SRC}/glibc -PATCH0_DIR=patch0 -PATCH1_DIR=patch1 - -## Patches -PATCH1 = 0003-2007-09-13-H.J.-Lu-hongjiu.lu-intel.com.patch \ - 0005-Hurd-specific-kernel-features.h.patch \ - 0007-2007-10-05-version-of-stat.patch.patch \ - 0008-r2425-of-debian-patches-hurd-i386-local-atomic-no-mu.patch \ - 0010-r2425-of-debian-patches-hurd-i386-local-gscope.diff.patch \ - 0012-r2425-of-debian-patches-hurd-i386-local-no-strerror_.patch \ - 0013-r2626-of-debian-patches-hurd-i386-local-tls-support.patch \ - 0014-r2591-of-debian-patches-hurd-i386-local-tls.diff.patch \ - 0015-r2630-of-debian-patches-hurd-i386-submitted-libc_onc.patch \ - 0016-Include-stdint.h.patch \ - 0017-r2598-of-debian-patches-any-local-stdio-lock.diff.patch \ - 0018-r2650-of-debian-patches-hurd-i386-submitted-strtoul.patch \ - 0019-2007-11-12-Aurelien-Jarno-aurelien-aurel32.net-Tho.patch \ - 0020-r2656-of-debian-patches-any-submitted-sched_h.diff.patch \ - 0022-2007-11-18-Roland-McGrath-roland-frob.com.patch - -PATCH0 = 0009-2007-07-22-version-of-init-first.c_vs._GCC_4.1.patch.patch \ - 0011-2007-02-08-version-of-resolv_res_send.c.patch.patch - -all: create_dir get_sources apply_glibc_patches build_all - -## Create directories -create_dir: - cd ${TOPDIR} - mkdir ${DOWNLOADS} - mkdir -p ${SRC} - -get_sources: get_cross_gnu get_binutils get_gcc get_gnumach get_mig get_hurd get_glibc - -get_cross_gnu: - @ echo " ___ _ __ ___ ___ ___ __ _ _ __ _ _ " - @ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |" - @ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |" - @ echo " \___|_| \___/|___/___/ \__, |_| |_|\__,_|" - @ echo " |___/ " - cd ${DOWNLOADS}; \ - wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu - @ echo " ___ _ __ ___ ___ ___ __ _ _ __ _ _ ___ _ ____ __" - @ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |_____ / _ \ '_ \ \ / /" - @ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |_____| __/ | | \ V / " - @ echo " \___|_| \___/|___/___/ \__, |_| |_|\__,_| \___|_| |_|\_/ " - @ echo " |___/ " - cd ${DOWNLOADS}; \ - wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu-env; \ - chmod +x cross-gnu; \ - chmod +x cross-gnu-env - -get_binutils: - @ echo " _ _ _ _ _ " - @ echo "| |__ (_)_ __ _ _| |_(_) |___ " - @ echo "| '_ \| | '_ \| | | | __| | / __|" - @ echo "| |_) | | | | | |_| | |_| | \__ \\" - @ echo "|_.__/|_|_| |_|\__,_|\__|_|_|___/" - cd ${SRC}; \ - cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src co -r binutils-2_18-branch binutils; \ - mv src binutils - -get_gcc: - @ echo " __ _ ___ ___ " - @ echo " / _\` |/ __/ __|" - @ echo "| (_| | (_| (__ " - @ echo " \__, |\___\___|" - @ echo " |___/ " - cd ${SRC}; \ - svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch; \ - mv gcc-4_1-branch gcc; \ - ( cd gcc/ && contrib/gcc_update --touch ) - -get_gnumach: - @ echo " _ " - @ echo " __ _ _ __ _ _ _ __ ___ __ _ ___| |__ " - @ echo " / _\` | '_ \| | | | '_ \` _ \ / _\` |/ __| '_ \ " - @ echo "| (_| | | | | |_| | | | | | | (_| | (__| | | |" - @ echo " \__, |_| |_|\__,_|_| |_| |_|\__,_|\___|_| |_|" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach; \ - ( cd gnumach/ && autoreconf -vfi ) - -get_mig: - @ echo " _ " - @ echo " _ __ ___ (_) __ _ " - @ echo "| '_ \` _ \| |/ _\` |" - @ echo "| | | | | | | (_| |" - @ echo "|_| |_| |_|_|\__, |" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig; \ - ( cd mig/ && autoreconf -vfi ) - -get_hurd: - @ echo " _ _ " - @ echo "| |__ _ _ _ __ __| |" - @ echo "| '_ \| | | | '__/ _\` |" - @ echo "| | | | |_| | | | (_| |" - @ echo "|_| |_|\__,_|_| \__,_|" - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd - -get_glibc: - @ echo " _ _ _ " - @ echo " __ _| (_) |__ ___ " - @ echo " / _\` | | | '_ \ / __|" - @ echo "| (_| | | | |_) | (__ " - @ echo " \__, |_|_|_.__/ \___|" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc co -r glibc-2_7-branch glibc; \ - mv libc glibc - mkdir ${GLIBC_DIR}/${PATCH0_DIR} - mkdir ${GLIBC_DIR}/${PATCH1_DIR} - -get_patch0: $(PATCH0) - -get_patch1: $(PATCH1) - -$(PATCH1): - wget -r -np -nd -P ${GLIBC_DIR}/${PATCH1_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@ - cd ${GLIBC_DIR}; \ - patch -p1 < ${PATCH1_DIR}/$@ - -$(PATCH0): - wget -r -np -nd -P ${GLIBC_DIR}/${PATCH0_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@ - cd ${GLIBC_DIR}; \ - patch -p0 < ${PATCH0_DIR}/$@ - -apply_glibc_patches: get_patch0 get_patch1 - -build_all: - ROOT=${TOPDIR}/root ; \ - export PATH="$(PATH):$(DOWNLOADS)" ; \ - echo $$PATH ; \ - . ${DOWNLOADS}/cross-gnu-env ; \ - ${DOWNLOADS}/cross-gnu - -clean: - rm -rf downloads root *~ diff --git a/hurd/faq/old-stuff.mdwn b/hurd/faq/old-stuff.mdwn index 6968a894..df2058c0 100644 --- a/hurd/faq/old-stuff.mdwn +++ b/hurd/faq/old-stuff.mdwn @@ -6,7 +6,7 @@ If you still have problems, do not hesitate to make use of the [[mailing lists]] * Yes and no. GNU refers to the system as a whole, while GNU/Hurd is more specific, saying that it is the GNU system running on the Hurd -- to differentiate it from the GNU system running on Linux, GNU/Linux. Also see [[GNU/GnuNames]] * **_What editor can I use?_** - * `nano` is the default editor on a fresh install, not `ae`. + * `nano` is the default editor on a fresh install, not `ae`, but a lot of editors are available. * **_Why can't I get the answers I need from Hurd hackers?_** * This [document](http://www.catb.org/~esr/faqs/smart-questions.html) may help you understand some developers attitudes and social norms. @@ -28,16 +28,16 @@ If you still have problems, do not hesitate to make use of the [[mailing lists]] * These are different versions of the Mach microkernel that supports the Hurd that runs on top of it. For more info, see [[Mach]] * **_What software is available for GNU?_** - * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[porting/guidelines]] document for some common build problems and their solutions. + * Most (2/3) packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Notably, [GNOME](http://www.gnome.org), and [KDE](http://www.kde.org) work. See the [[porting/guidelines]] document for some common build problems and their solutions. * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source && cd <package\_dir> && debian/rules binary". - * As of January 2007, 50% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. + * As of April 2010, 65% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. * **_How do I initialize a serial console on the Hurd?_** * You can try out the Serial Howto at <http://www.nongnu.org/thug/serial-howto.txt> * For a real serial console at boot time you need to rebuild your GNUmach 1.x kernel. For more info see the Utah release notes at [http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html#serial\_console](http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html#serial_console) * **_Will GNU work in Vmware?_** - * It's highly recommended and easier to get a full image for Bochs. See [[Distrib]] + * It's highly recommended and easier to get a full image for qemu. See [[Distrib]] * It didn't use to, [Hurd bootstrap fails](http://lists.debian.org/debian-hurd/2002/debian-hurd-200207/msg00069.html). Vmware is not [free software](http://www.gnu.org/philosophy/free-sw.html) and it is [[Distrib/VmWare]]. We recommend to use [free](http://www.gnu.org/philosophy/free-sw.html) alternatives, like [[Distrib/BochsEmulator]]. * A faster, more widespread and [free](http://www.gnu.org/philosophy/free-sw.html) recent alternative is [QEMU][[running/QEMU]]. You can find more informations on [[running/QEMU]]. * If someone prefers using VMWare: diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn new file mode 100644 index 00000000..f9aa518f --- /dev/null +++ b/hurd/libports.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +*libports* is a convenience library for easier handling of [[Mach +ports|microkernel/mach/port]]. It is documented in the [[Reference_Manual]]. + +*libports* is not (at least, not for now) a generalization / abstraction of +Mach ports to the functionality the Hurd needs, that is, it is not meant to +provide an interface independently of the underlying [[microkernel]]. diff --git a/hurd/logo.mdwn b/hurd/logo.mdwn index aae80561..467e6ba8 100644 --- a/hurd/logo.mdwn +++ b/hurd/logo.mdwn @@ -1,25 +1,11 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -The famous *Hurd Boxes* logo is available at -<http://www.gnu.org/graphics/hurd_mf.html>. - - -On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]] -converted these four boxes from the [original METAFONT -sources](http://www.gnu.org/graphics/hurd.mf) to -[[hand-written_SVG_code|boxes-redrawn.svg]]. - -[[!img boxes-redrawn.png]] - - -This symbol is also being used as a favicon for this web site. - -[[!img /favicon.ico]] +[[!meta redir=/logo]] diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 74c1ac8b..e58a2058 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -20,10 +20,10 @@ Basically all package management schemes follow similar approach, it will have a There can be both aproaches - * Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re implement, apt-rpm, yum ... - * Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ... + * Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re-implement, apt-rpm, yum ... + * Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ... -One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a chioce to continue builing packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface). +One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a choice to continue building packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface). ## Why? @@ -40,7 +40,7 @@ With the increased flexibility in implementing filesystems as per the requiremen ## How? - * Installtion of a package is just drag the pacakage (be it a tgz, rpm, deb or an exe) and drop it to the package manager. + * Installation of a package is just drag the package (be it a tgz, rpm, deb or an exe) and drop it to the package manager. * apt-cache search vim --> ls -al /packages/meta/ |grep vim * apt-get install vim --> install vim @@ -77,12 +77,12 @@ just writing the new translator. ## Initial idea -A bit complex than the earlier scheme but it is more exciting and we can look at this schem seriously once we have the simple scheme working. +A bit more complex than the earlier scheme but it is more exciting and we can look at this scheme seriously once we have the simple scheme working. All packages are installed at `/packages/binary/<packagename>/<packageversion>`. -For eaxmple vim 6.4 version can be installed from source like +For example vim 6.4 version can be installed from source like # cd vim64 # ./configure --prefix=/packages/binary/vim/6.4 @@ -99,7 +99,7 @@ Now if you have another vim version, say 7.0 then just follow the steps # make # make install -You have 2 versions of vim and how can you sepcify which one is the current version? You can symlink the current version to select the version you would like to see as default +You have 2 versions of vim and how can you specify which one is the current version? You can symlink the current version to select the version you would like to see as default # ln -s /packages/binary/vim/7.0 /packages/vim/current @@ -141,7 +141,7 @@ v. Add your name below and give a shout in the list. Add your comments here -## Interesting? +## Interested? To join the project just list your name below. diff --git a/ikiwiki.setup b/ikiwiki.setup index 108078f5..eb31a420 100644 --- a/ikiwiki.setup +++ b/ikiwiki.setup @@ -38,8 +38,9 @@ IkiWiki::Setup::Standard->import({ # users who are wiki admins adminuser => [qw{tschwinge}], # users who are banned from the wiki - banned_users => [qw{AlbertF bernhart ColetCris - http://calvinyoung.myopenid.com/}], + banned_users => [qw{AlbertF bernhart ColetCris flamberian jasclaine + http://calvinyoung.myopenid.com/ + http://hilarybunton.myopenid.com/}], # where the source of the wiki is located srcdir => $srcdir, # where to build the wiki @@ -25,18 +25,12 @@ kernels (such as Linux). for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible. -<em>[[Our mission explained|community/weblogs/antrik/hurd-mission-statement]].</em></p> +<em>[[Our_mission_explained|community/weblogs/antrik/hurd-mission-statement]].</em></p> </div> </div> --- -[[!template id=note text="""**Breaking News** - -The *[[Google Summer of Code|community/gsoc]]* is on! If you're a student, -consider applying for a GNU/Hurd project."""]] - - [[!toc]] @@ -73,8 +67,7 @@ To help the Hurd you can for example (from high level stuff to the inner core) * Work on the [[Hurd_on_Mach|contributing#hurd_on_mach]], or * Help to port the Hurd [[to_a_modern_microkernel|contributing#hurd_on_modern_microkernel]]. -You can find most Hurd related sourcecode in the -[savannah git repositories for the Hurd](http://git.savannah.gnu.org/cgit/hurd/). +See our [[source_repositories]] for the source code. Read about ways to contribute [[in_more_detail|contributing]]. @@ -51,12 +51,13 @@ to always greet the channel when you enter and before leave. # Regular Meetings Starting in early 2008, there have been regular IRC meetings held between the -(now former) [[community/GSoC]] students and their mentors. These continue to -take place even that the [[Google_Summer_of_Code_2008|community/gsoc/2008]] is -over, and still take place, currently **every Wednesday at 11:00 UTC in the `#hurd` -channel**. Of course, the meetings are not only for (former) GSoC students and -mentors, but open to any interested party. So, everyone, take your chance to -chat with GNU Hurd developers! +(now former) [[Google Summer of Code|community/gsoc]] students and their +mentors. These meetings turned out to considerably help student-mentor +interactions, and other developers regularely took part, too. For this reason, +we decided to continue having these meetings, even if it's not currently Google +Summer of Code time. The meetings take place in the **`#hurd` channel every +Monday and Thursday at 10:30 UTC** and are open to any interested party. So, +everyone, take your chance to chat with GNU Hurd developers! # Channels diff --git a/logo.mdwn b/logo.mdwn new file mode 100644 index 00000000..aae80561 --- /dev/null +++ b/logo.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +The famous *Hurd Boxes* logo is available at +<http://www.gnu.org/graphics/hurd_mf.html>. + + +On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]] +converted these four boxes from the [original METAFONT +sources](http://www.gnu.org/graphics/hurd.mf) to +[[hand-written_SVG_code|boxes-redrawn.svg]]. + +[[!img boxes-redrawn.png]] + + +This symbol is also being used as a favicon for this web site. + +[[!img /favicon.ico]] diff --git a/hurd/logo/boxes-redrawn.png b/logo/boxes-redrawn.png Binary files differindex fd26a87e..fd26a87e 100644 --- a/hurd/logo/boxes-redrawn.png +++ b/logo/boxes-redrawn.png diff --git a/hurd/logo/boxes-redrawn.svg b/logo/boxes-redrawn.svg index c0a7e460..c0a7e460 100644 --- a/hurd/logo/boxes-redrawn.svg +++ b/logo/boxes-redrawn.svg diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 500424bb..be762960 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -70,6 +70,12 @@ pp. 67--77." [Chapter 4, Inter Process Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html). + * OSF's [Server Writer's Guide (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps) + [Server Writer's Guide (pdf)](http://shakthimaan.com/downloads/hurd/server_writer.pdf) + + * OSF's [Server Writer's Interfaces (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps) + [Server Writer's Interfaces (pdf)](http://shakthimaan.com/downloads/hurd/server_interface.pdf) + * Flags: * [[dealloc_and_dealloc[]|dealloc]] diff --git a/news/2010-03-31.mdwn b/news/2010-03-31.mdwn index d51fdf46..c3c424d1 100644 --- a/news/2010-03-31.mdwn +++ b/news/2010-03-31.mdwn @@ -8,7 +8,7 @@ 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 date="2010-04-01 07:45 UTC"]] +[[!meta date="2010-04-01 07:55 UTC"]] A month of the Hurd: some more *bug squashing* and *Google Summer of Code 2010*. [[!if test="included()" then="""[[!toggle id=full_news diff --git a/news/2010-04-30.mdwn b/news/2010-04-30.mdwn index c4a388bd..131af4ea 100644 --- a/news/2010-04-30.mdwn +++ b/news/2010-04-30.mdwn @@ -8,60 +8,84 @@ 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]]."]]"""]] -<!-- Date when the news item is (to be) pulished (important for RSS feeds). -Will be set by tschwinge when publishing. -[[!meta date="YYYY-MM-DD HH:MM UTC"]] ---> +[[!meta date="2010-05-02 21:20 UTC"]] -A month of the Hurd: *Arch Hurd on Hardware*, *X.org out of the box*, *new debian qemu image* and *GSoC students*. +A month of the Hurd: *Arch Hurd*, *updated Debian GNU/Hurd QEMU image*, and *GSoC students*. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" else="[[!paste id=full_news]]"]] [[!cut id="full_news" text=""" -> This month the Arch Hurd team -> reported the first instance of Arch Hurd -> [running on real hardware](http://www.archhurd.org/news/11) (and uploaded -> [a photo](http://wiki.archhurd.org/wiki/User:Giselher#ArchHurd_on_a_real_PC) as evidence). -> -> Also the fix from *Samuel Thibault* got included in libxcb1, so X.org -> [works out of the box again](http://lists.debian.org/debian-hurd/2010/04/msg00034.html) with -> a simple startx and *Philip Charles* -> [extended his offerings](http://lists.debian.org/debian-hurd/2010/04/msg00019.html) -> with an updated *GRUB usb stick for booting Debian/Hurd*. - -> And mainly thanks to *Jose Luis Alarcon Sanchez* we now have a -> [new qemu image](http://lists.debian.org/debian-hurd/2010/04/msg00098.html) -> Which runs out of the box via `qemu -hda debian-hurd-17042010-qemu.img`. -> -> Now to the GSoC news: we got -> [3 students](http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010) -> working on the Hurd this year: -> ->> *Jeremie Koenig* mentored by *Samuel Thibault* will be working on adapting the debian-installer to ->> [produce working Debian GNU/Hurd installation images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) ->> so we can more easily offer up to date disc-sets ->> ([details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig)). ->> ->> Also *Emilio Pozuelo Monfort* mentored by *Fredrik Hammar* will work on the ->> possibly boring yet extremely valuable task of ->> [fixing compatibility problems exposed by projects testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396) ->> ([[details|community/gsoc/project_ideas/testsuites]]). -> ->> And finally *Karim Ahmed* mentored by *Sergio Lopez* will work on ->> [Tuning the VM Subsystem in GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) ->> to get the virtual memory management in Hurd/Mach up to date ->> ([[details|community/gsoc/project_ideas/vm_tuning]]). -> -> So we had quite an exiting month with many starting threads, -> which makes this the perfect time to -> subscribe to our [[mailing_lists]] (bug-hurd and debian-hurd are the main lists) -> and see the Hurd make another leap forward :) -> -> We’d be happy to see you sign up and -> contribute towards making the Hurd usable for everyone -> ([[our_mission|community/weblogs/antrik/hurd-mission-statement]]). - -<!-- Handled debian-hurd until 2010-04-28. --> +> The Arch Hurd folks keep [making good +> progress](http://lists.gnu.org/archive/html/help-hurd/2010-04/msg00003.html): +> their count of available packages keeps increasing, and one of their team +> reported the first instance of Arch Hurd [running on real +> hardware](http://www.archhurd.org/news/11) (and uploaded [a +> photo](http://wiki.archhurd.org/wiki/User:Giselher#ArchHurd_on_a_real_PC) as +> evidence). + +> Of course, our Debian port is still progressing, too: 66% of all Debian +> packages [are currently available for Debian +> GNU/Hurd](https://buildd.debian.org/stats/hurd-i386.txt). + +> *Samuel Thibault*'s fix got included in libxcb1, so X.org again [works out of +> the box](http://lists.debian.org/debian-hurd/2010/04/msg00034.html) using a +> simple `startx`. + +> *Philip Charles* [extended his +> offerings](http://lists.debian.org/debian-hurd/2010/04/msg00019.html) with an +> updated *GRUB USB stick for booting Debian GNU/Hurd*. + +> *Carl Fredrik Hammar* proposed a patch to [faciliate debugging the startup of +> misbehaving +> translators](http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00037.html). + +> Mainly thanks to *Jose Luis Alarcon Sanchez*, we now have a [new QEMU +> image](http://lists.debian.org/debian-hurd/2010/04/msg00098.html). It can be +> run with a simple `qemu -hda debian-hurd-17042010-qemu.img`. + +> *Thomas Schwinge* updated [our glibc maintenance +> repository](http://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker) +> to a recent version, including a bunch of the patches from the Debian glibc +> package (and these are meant to eventually be submitted upstream). After a +> long break, he as well +> [updated](http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00062.html) +> his [[toolchain_cross-compilation_script|hurd/building/cross-compiling]] to +> the current source code packages, and added C++ support. + +> On to the Google Summer of Code 2010: we got three students working on the +> Hurd this year: + +> * *Jeremie Koenig*, mentored by *Samuel Thibault*, will be working on +> adapting the Debian Installer to [produce working Debian GNU/Hurd +> installation +> images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) +> so we can easily offer up to date disc-sets. +> ([Details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig).) + +> * *Emilio Pozuelo Monfort*, mentored by *Carl Fredrik Hammar* (who was a +> GSoC student in 2007), will be working on a task that may be perceived as +> less exciting from the outside, but yet is extremely valuable: [fixing +> compatibility problems exposed by projects' +> testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396). +> ([[Details|community/gsoc/project_ideas/testsuites]].) For starters, he +> already got a glibc patch [accepted +> upstream](http://sourceware.org/ml/libc-alpha/2010-04/msg00046.html). + +> * *Karim Allah Ahmed*, mentored by *Sergio López*, will be working on +> [tuning the VM Subsystem in +> GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) +> to bring the virtual memory management in Hurd/Mach up to date. +> ([[Details|community/gsoc/project_ideas/vm_tuning]].) + +> We'd be happy to see *YOU* sign up on our mailing lists +> ([[mailing_lists/bug-hurd]] and [[mailing_lists/debian-hurd]] are the main +> lists), and [[contribute|contributing]] towards making the Hurd usable for +> everyone, as written down in +> [[our_mission_statement|community/weblogs/antrik/hurd-mission-statement]]. +> Perhaps one of the unassigned projects (outside of the Google Summer of Code +> context) from our [[project_ideas_list|community/gsoc/project_ideas]] is fit +> for you? + """]] diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn index 71f495cc..d97f5458 100644 --- a/open_issues/crash_server.mdwn +++ b/open_issues/crash_server.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 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 @@ -49,9 +49,47 @@ one... 17M core On Linux, the `core` file occupies 76 KiB of disk space, which seems - much more reasonable. + much more reasonable. This is possibly related with the default 128MiB + heap preallocation. - * ... produce an invalid `core` file: + * ... does not always produce a useful backtrace: + + `abort();` + + $ gdb test core + warning: core file may not match specified executable file. + [New Thread 86678] + warning: Wrong size fpregset in core file. + ... + Core was generated by `./test'. + Program terminated with signal 6, Aborted. + warning: Wrong size fpregset in core file. + (gdb) bt + #0 0x00000000 in ?? () + #1 0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1) + at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144 + #2 0x0109a433 in kill_port (pid=<value optimized out>) + at ../sysdeps/mach/hurd/kill.c:68 + #3 kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105 + #4 0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139 + #5 0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 + #6 0x0109de59 in abort () at abort.c:88 + #7 0x0804849f in main () + + `char *foo = 0; *foo = 1;` + + $ gdb test core + Program terminated with signal 11, Segmentation fault. + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + #1 0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64, + init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>, + stack_end=0x1023e5c) at libc-start.c:251 + #2 0x080483d1 in _start () + + `raise (SIGABRT);` $ gdb a.out core warning: core file may not match specified executable file. @@ -68,8 +106,7 @@ one... #0 0x00000000 in ?? () Cannot access memory at address 0x17 - [[!tag open_issue_gdb]] Probably the `crash` server code and [[GDB]] are - out of sync. + [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly. * ... against `crash-suspend` will... diff --git a/open_issues/gcc/c++.mdwn b/open_issues/gcc/c++.mdwn deleted file mode 100644 index cab4c1f1..00000000 --- a/open_issues/gcc/c++.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]] - -[[!tag open_issue_porting open_issue_gcc fixed_in_debian]] - -Modify the [[hurd/building/cross-compiling]] shell script to configure GCC for -building GCC with C++ support when building its second (i.e., final) version. - -Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the -resulting binaries would also work), but linking fails with GCC SVN trunk: - - $ $TARGET-g++ -Wall a.cc -lpthread - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2' - collect2: ld returned 1 exit status - -Whether this defect report also applies to a natively-build GCC from SVN trunk -has not yet been checked. - -[[Thomas_Schwinge|tschwinge]] suspects the problem to be a configuration issue -of a GCC helper library, whose configuration setup has changed after GCC 4.3. - -The need for `-lpthread` is another story. See the Debian glibc patches -repository for details. diff --git a/open_issues/glibc_testsuite.mdwn b/open_issues/glibc_testsuite.mdwn new file mode 100644 index 00000000..4cceb241 --- /dev/null +++ b/open_issues/glibc_testsuite.mdwn @@ -0,0 +1,105 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!tag open_issue_glibc]] + +`configure --without-cvs --prefix= --disable-profile --build=i486-gnu +--host=i486-gnu` + +`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to +c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. + +Configured with `--prefix=/usr` instead of `--prefix=`. + +Resolved failures: + + * localedata/tst_mblen.out + * localedata/tst_mbrlen.out + * localedata/tst_mbrtowc.out + * localedata/tst_mbsrtowcs.out + * localedata/tst_mbstowcs.out + * localedata/tst_mbtowc.out + * localedata/tst_swscanf.out + * localedata/tst_wcrtomb.out + * localedata/tst_wcsrtombs.out + * localedata/tst_wcstombs.out + * localedata/tst_wctob.out + * localedata/tst_wctomb.out + * localedata/bug-iconv-trans.out + * localedata/tst-wctype.out + * math/test-float.out + * math/test-double.out + * posix/tst-vfork3-mem + * io/tst-mkdirat.out + +New: + + * A lot of `error while loading shared libraries: libmachuser.so.1: cannot + open shared object file: No such file or directory`. Is it perhaps picking + that library up from `$prefix/lib/`? + + New failures; likely due to that: + + * iconvdata/iconv-test.out + * iconvdata/tst-tables.out + * malloc/tst-mtrace.out + * grp/tst_fgetgrent.out + * posix/globtest.out + * posix/wordexp-tst.out + * io/ftwtest.out + * elf/tst-pathopt.out + + Changed failures; likely due to that: + + * debug/tst-chk4.out / debug/tst-chk5.out + + -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory + +--- + +Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. + +--- + +Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. + +New failures: + + * posix/bug-glob3.out (SEGFAULT; but also on Linux) + * wctype/bug-wctypeh.o (compile error; but also on Linux) + +Other things noticed: + + * Running `make -k check` for the second time: + + -i486-gnu-gcc tst-timer2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o + -tst-timer2.c: In function ‘do_test’: + -tst-timer2.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) + -tst-timer2.c:33: error: (Each undeclared identifier is reported only once + -tst-timer2.c:33: error: for each function it appears in.) + -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o] Error 1 + +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + +make[2]: *** [/usr/include/pthread.h] Error 1 + + -i486-gnu-gcc tst-thrlock.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o + -i486-gnu-gcc -nostdlib -nostartfiles -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock -Wl,-dynamic-linker=/usr/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crt1.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crti.o `i486-gnu-gcc --print-file-name=crtbegin.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn/libdl.so.2 -Wl,-rpath-link=/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/math:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nss:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nis:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/resolv:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/crypt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc.so.0.3 /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `i486-gnu-gcc --print-file-name=crtend.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crtn.o + -/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o: In function `do_test': + -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:38: undefined reference to `pthread_create' + -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:48: undefined reference to `pthread_join' + -collect2: ld returned 1 exit status + -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock] Error 1 + +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + +make[2]: *** [/usr/include/pthread.h] Error 1 + + * Not all tests are re-run in a `make -k tests; make tests-clean; make -k + tests` cycle. diff --git a/public_hurd_boxen/installation/snubber.mdwn b/public_hurd_boxen/installation/snubber.mdwn index f9542a9f..dbbade9f 100644 --- a/public_hurd_boxen/installation/snubber.mdwn +++ b/public_hurd_boxen/installation/snubber.mdwn @@ -30,6 +30,24 @@ License|/fdl]]."]]"""]] $ mkdir tmp/backup && chmod 0733 tmp/backup +# `/var/www/robots.txt` + +This file used to contain: + + User-agent: * + Disallow: /gitweb/ + Disallow: /cgi-bin/ + +... which I've now changed to: + + User-agent: * + Disallow: / + +The goal is that robots rather index the official pages, +<http://www.gnu.org/software/hurd/>, instead of the staging area on +<http://www.bddebian.com:8888/~hurd-web/>. + + # Restore Backup ## `/etc/apache2/mods-enabled/` diff --git a/sidebar.mdwn b/sidebar.mdwn index 7d71cd28..159104fc 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,8 +9,7 @@ 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]]."]]"""]] -Welcome to... [[!img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU -Hurd! +Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd! * **[[Home|/index]]** * **[[Community]]** diff --git a/tag/stable_URL.mdwn b/tag/stable_URL.mdwn new file mode 100644 index 00000000..af17a58a --- /dev/null +++ b/tag/stable_URL.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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="stable_URL"]] + +These pages are tagged as having a *stable URL*. That is, they're linked to on +external pages, and should not be changed just for the sake of it. + +[[!map pages="tagged(stable_URL)" +show=title]] diff --git a/user.mdwn b/user.mdwn new file mode 100644 index 00000000..9c965af2 --- /dev/null +++ b/user.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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="User Pages"]] + +[[!inline +pages=none +show=-1 +feeds=no +actions=yes +rootpage="user" postformtext="Add a new user page titled:"]] + +[[!map pages="user/* and !user/*/*" +show=title]] diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn new file mode 100644 index 00000000..14e40bf6 --- /dev/null +++ b/user/jkoenig.mdwn @@ -0,0 +1,99 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +## Hurd Debian-Installer + +My [proposal](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig) +to work on porting d-i on Hurd +as a [Google Summer of Code](http://code.google.com/soc/) student +has been accepted by the Debian project. + +I will be keeping track of my progress on this page. + +### Latest news + + * *busybox*: + patches [posted](http://lists.debian.org/debian-bsd/2010/05/msg00048.html). + I need to test them on kFreeBSD, + then submit them upstream and to #323670. + * installation images boot with the following changes: + * rebuild hurd-udeb from with the latest pkg-hurd patches + * use busybox from my osports-debian branch (see link above) + * tweak the d-i image build scripts + * the symlink /lib/ld.so -> ld.so.1 needs to be created somehow + (youpi mentionned it being the job of libc0.3-udeb I think) + * fix the poll() issue in libdebian-installer + (patch to be submitted soon), + also there is some hurd doxygen short-circuiting stuff + there which does not apply any more and prevents is to build. + * initrd support coming soon (BTW gnumach does not like gcc-4.4), + for the time being it needs to be fed to qemu as a hard drive + (with some more space added to avoid it from becoming full) + +### Roadmap + +#### Week 2 (2010-05-31 to 2010-06-06) + +* see what breaks in the installer and fix the problems one by one + (install-time netcfg, cdrom detection, whatever) +* start working on mach initrd support + +#### Week 3 (2010-06-07..13) + +* try to get the busybox changes merged upstream + and integrated into the debian package +* tweak the hurd debian package to handle + what native-install used to be required for + +#### Week 4 (2010-06-14..20) + +* Hurd-specific partitionning (use supported fs types and options). + NB: we will need support in mach to reload the partition tables, + or alternatively use the parted support in libstore somehow. +* grub2 installation + +#### Week 5-6 (2010-06-21..07-04) + +* unexpected stuff +* cleanup +* call for testing +* fix bugs + +At this point we would have a basic but working installer. +Hopefully the summer would not be over yet... + +#### Week 7-8 (2010-07-05..18) + +* hurd console +* better DHCP support during and after installation +* support more types of installation images + +#### Week 9-10 (2010-07-19..08-01) + +* give a shot at the graphical installer ? + +#### Week 11-12 (2010-08-02..15) + +* test, fix, document + + +### Mostly done + +#### Week 1 (2010-05-24) + +* genext2fs: patches [submitted](http://bugs.debian.org/562999) + which add support for all block sizes and choosing them at runtime. +* busybox: started porting the upstream and Debian package to Hurd and FreeBSD +* rebuilding hurd-udeb from the pkg-hurd version + and adding a ld.so link to the initrd + fixes the exec translator crashing on startup. + (BTW would there be a mean to detect this from the libdiskfs bootstrap code + and report it ?) + diff --git a/user/kam.mdwn b/user/kam.mdwn new file mode 100644 index 00000000..da820f62 --- /dev/null +++ b/user/kam.mdwn @@ -0,0 +1,115 @@ +[[!meta copyright="Copyright © 2008 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="Karim Allah Ahmed"]] + +<karim.allah.ahmed@gmail.com> + +Egypt. + +--- + +#GSoC: 2010 Project +Goal: + +--- +#Roadmap + +##Progress + +###Preparation Phase: + +Understanding how gnumach ticks [ at least the parts related to the project ] + +--- + +####28th of April - 5th of May: + +* Reading the paging in code in gnumach. +* Reading the libpager code, and the multipage patch. +* Reading the translators code, only the part implementing the external pager interface. + +####5th of May - 12th of May: + +* Reading the paging out code in gnumach. +* Understanding IPC in gnumach and reading some code. +* Reading "[gnu_src]/kern/sched_prim.c" + +####12th of May - 19th of May: + +* Finishing the leftover code in some of the previous phases. +* Building a big and a more clear picture of how gnumach ticks [ wiring things together ]. + +####19th of May - 23th of May: + +* Off [College related-activities]. + +--- + +###Coding Phase: + + +####24th of May - 26th of May: + +* Read the freeBSD multipages implementation. +* Basic Modifications of gnumach's code. +* err.. scratch this step. It's easier to work on porting OSF Mach's implementation of multi-pages. + +####26th of May - 28th of May: + +* port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c ) +* port "cluster_size" attribute of memory objects from OSF Mach. +* port "behavior" attribute of vm_map entries from OSF Mach. + +####29th of May - 2nd of June: + +* Off ( Oral Exams ) + +--- + +####2nd of May - 4th of June: + +* Finish the port of the previous phase. + +--- + +####5th of June - 11th of June: + +* Modify the API of the libpager to support multipages. + +--- + +####12th of June - 26th of June: + +* Modify the of the translators code to implement the new libpager interface. + +--- + +####27th of June - 30th of June: + +* port OSF Mach's clustered pageout ( [src]/vm/vm_pageout.c ) + +--- + +####1st of July - 4th of July: + +* Fix the bootmem_allocator patch along with my proposal. + +--- + +### Testing Phase: + +--- + +### Exams Schedule: + +#### Final exams : + +Starts at 12th of June for two weeks [maybe 2 or 3 days longer than this , not sure] diff --git a/user/pochu.mdwn b/user/pochu.mdwn new file mode 100644 index 00000000..164f8900 --- /dev/null +++ b/user/pochu.mdwn @@ -0,0 +1,94 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +# Emilio Pozuelo Monfort + +Email: pochu27@gmail.com + +--- + +# GSoC 2010: Hurd: Fix Compatibility Problems Exposed by Testsuites + +Mentor: Carl Fredrik Hammar + +## Abstract + +This project will consist of identifiying some projects' test suite +failures when executed on GNU/Hurd, debugging them, and if they are +truly GNU/Hurd issues (and not problems in the projects themselves), +fixing them. + +## Timeline +* May 24th: Students begin coding for their GSoC projects +* May 31st: GLib and GNU coreutils done +* June 8th: End of classes +* June 28th: Python done +* July 9th: End of exams +* July 12th: Perl done +* July 16th: Mid-term evaluations deadline +* August 1st: DebConf +* August 16th: Firm 'pencils down' date + + +## TODO +* Send copyright paperwork back to the FSF. +* Bug 28934: Address comments on the patches. +* Bug 29655: Submit to libc-alpha when the copyright assignment is on file. +* Implement getsockopt() in hurd/pflocal/socket.c +* Send a summary to bug-hurd explaining the O_NOFOLLOW & O_NOTRANS problem. +* Investigate why coreutils' nice test fails. + + +## Documentation +* [Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG](http://www.gnu.org/software/hurd/hurd-paper.html) +* [The Hurd, a presentation by Marcus Brinkmann](http://www.gnu.org/software/hurd/hurd-talk.html) +* [The Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) +* [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) + +## Log + +### May 19 - May 26 +* Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) +* Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. +* Requested GNU libc copyright papers to the FSF again since they didn't arrive the first time. + +### May 12 - May 19 +* Read http://www.gnu.org/software/hurd/hurd-talk.html +* Half read http://www.gnu.org/software/hurd/hacking-guide/hhg.html +* Read many Hurd interfaces (fs.defs, auth.defs, fsys.defs, io.defs, + password.defs). + +### May 5 - May 12 +* Read http://www.gnu.org/software/hurd/hurd-paper.html +* Improved the linkat() patch +* Fixed the issues mentioned in bug 28934, but after doing so I realized + that wouldn't work well. The only good solution is to pass file_name + from execve() to the exec server, so we need new RPCs. + +### April 28 - May 5 +* Submitted a talk proposal on Hurd with Michael Banck for DebConf +* Sent request to assign copyright to the FSF for Hurd/Mach/libc + +### Before April 28 +* Investigated the glib's gtester problem and tracked it down: + [bug 28934](https://savannah.gnu.org/bugs/?28934). Prepared a patch + but it's not good. +* [glib's garray test timeouts on Hurd](https://bugzilla.gnome.org/show_bug.cgi?id=568760). + The tests passes if the timeout is increased. The current upstream timeout + (10s) is quite small (it fails on many Debian builds for some Linux arches). + However on Hurd it needs a very big time it seems (like more than 100s). + Maybe do an allocation benchmarch? +* Investigated glib's unix-fd test failure: getsockopt() isn't implemented + on Hurd. Need to implement it in hurd/pflocal/socket.c. +* Investigated coreutils' ln EIEIO, with Samuel's help. linkat() is buggy. + Reported as [bug 29655](https://savannah.gnu.org/bugs/?29655). Prepared a + patch for it. +* Investigated coreutils' cp EACCES. Test case: 'mkfifo a && cp -R --copy-contents a b'. + Problem is that O_NOFOLLOW adds O_NOTRANS. diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index d64ac133..017936e5 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -13,6 +13,49 @@ Sergiu Ivanov Mail: <mailto:unlimitedscolobb@gmail.com> +# Current Activity + +I am currently busy finishing the university semester, this is why I +am rather passive. + +## Roadmap + +* **Build `nsmux` under the Hurd tree** -- **antrik** has been urging + me to do this for a long time, so I definitely have to give it a + try. + +* **Try Thomas's `nsmux-notify` branch** -- To support his stance + against including `nsmux` in the Hurd source tree, Thomas added to + `nsmux` the ability to listen to port notification (as I understand + it). I have to try that, too. + +* **Make proxy nodes go away when the proxied translator goes away** + -- This should be done by listening to notifications on the ports to + the proxied translators. A similar functionality is already + implemented in `unionmount`, but it was decided that `nsmux` should + use standard notification interfaces, as opposed to the custom + demuxer and handler implemented in `unionmount`. + +* **Don't attach anonymous translators** -- There is no special point + in attaching anonymous (formerly known as dynamic) translators to + specific nodes. Keeping them orphan should simplify the design of + `nsmux` by eliminating the need for shadow nodes, whose main purpose + was to serve as virtual locations to attach translators to. + +* **Setup a list of nodes proxying static translators** -- This list + is needed when for the filter, which should also be able to go down + the static translator stack, not only the stack of anonymous + translators. + +* **Cleanup `nsmux`** -- When I was writing `nsmux` my acquaintance + with good coding and code formatting practices was very basic, which + resulted in messy and sometimes ugly code. + +* **Implement recursive propagation of translators down directories** + -- This task was planned long ago and is fascinating, but I won't be + working on it in the near future. + +--- # Google Summer of Code: 2009 Project diff --git a/user/zhengda.mdwn b/user/zhengda.mdwn index dd8e6bac..39af5699 100644 --- a/user/zhengda.mdwn +++ b/user/zhengda.mdwn @@ -13,7 +13,7 @@ porting DDE developed by DROPS to the Hurd, and it will still run in the user sp The introduction of DDE/DDEKit can be found in [here](http://wiki.tudos.org/DDE/DDEKit) and more information can be found [here](http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html). DDE/DDEKit is a library, and it should be compiled with the code of Linux or FreeBSD drivers. DDE Linux26 is still under development and it can now support network and block devices (but doesn't support SCSI). ## My work -I separate DDE Linux26 to 2 parts: libddekit and libdde_linux26. I also provide a library called libmachdev on the top of the Linux code to provide the Mach device interface, so it is easy for the user to compile a Linux driver and run it in the Hurd. The latest code can be found in the dde branch of the incubator repository. +I separate DDE Linux26 to 2 parts: libddekit and libdde_linux26. I also provide a library called libmachdev on the top of the Linux code to provide the Mach device interface, so it is easy for the user to compile a Linux driver and run it in the Hurd. The latest code can be found in the dde branch of the incubator repository. The current status: the pcnet32 driver can work very well in DDE Linux26 now. I hope someone can try other NIC drivers. Please run DDE with GNUMach in the [master-user_level_drivers](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) branch. @@ -21,7 +21,9 @@ There is a minor problem when we compile a Linux driver. Linux drivers use jiffi ## Build and run DDE drivers -To build a Linux driver with DDE Linux, the easiest way is to use dde_pcnet32 (also in the dde branch) as a template. The directory of dde_pcnet32 has Makefile, Makeconf.local, default.ld, pcnet32.c and main.c. If we need to build a new driver file, we only need to replace pcnet32.c with the new file and change Makefile accordingly. +It is better to disable the corresponding kernel drivers in GNU Mach. For example, if we use the pcnet card, we'd better disable lance and pcnet32 drivers while building GNU Mach. DDE requires the pfinet with the modification during my GSoC project in 2008 and that pfinet requires libpcap-dev. To build DDE, we have to first install libpciaccess. libdde_linux26 has to be compiled manually (building dde_pcnet32 doesn't compile libdde_linux26 automatically). + +To build a Linux driver with DDE Linux, the easiest way is to use dde_pcnet32 (also in the dde branch) as a template. The directory of dde_pcnet32 has Makefile, Makeconf.local, default.ld, pcnet32.c and main.c. If we need to build a new driver file, we only need to replace pcnet32.c with the new file and change Makefile accordingly. You also need to change DDEKITLIBDIR, DDEKITINCDIR, DDE26LIBDIR and OBJ_BASE in Makeconf.local to indicate the path to ddekit and dde_linux26. To run a DDE NIC driver: |
