Hi, On Mon, Mar 28, 2011 at 10:44:29PM +0300, Esa-Matti Mourujärvi wrote:
> I'm interested in applying for Hurd in GSoC. I am a second year CS > student in University of Oulu, Finland. Welcome :-) > I have knowledge of C to some extend, but I have never developed > anything big with it on my own. On another note, I have used > non-windows operating systems only for a year, but I am eager to learn > more. These could be problems... Though your patch seems to indicate that you already know the ways pretty well :-) > What I am particularly interested in GSoC is the idea for implementing > libcap for Hurd. I have managed to compile it on qemu Hurd by doing > dummy patch. The main purpose of the mentioned patch (can be found > from the bottom of this mail) is to prove it is easy and possible to > port libcap to Hurd. Well, it doesn't exactly prove that... But it's certainly a start :-) > The solution I made is not most likely the elegant one possible. Actually, I considered proposing something like that myself... It's the most pragmatical approach for now -- though I guess a more elegant one might be necessary for getting it upstream. > I do realise, that another solution could be to change every variable > type to the ones defined in stdint.h and send a patch to libcap's > owner. Yeah, I think that would be the *right* way of doing it. I'm not sure however how __le32 could be handled properly in this case. Also the question is whether the libcap maintainers want it... If we have to maintain our own fork, the pragmatic solution is probably preferable. > Unfortunately I have not been able to actually test libcap by using > capget/ capset functions, because gcc fails to link against them. I don't understand. Aren't these what libcap is actually supposed to provide?... > My next plan is to study more about capabilities and about how user > authentication currently works in Hurd. I also should learn somehow > where exactly should one implement the missing capabilities. Any > suggestions what else should I study in order to be able to send a > proper application? That should get you started pretty well I'd say :-) > -#include <linux/types.h> > +#include "typeswrapper.h" Alternatively, perhaps we could just provide a pseudo linux/types.h with the contents of typeswrapper.h? > +#ifdef __CHECKER__ > +#define __bitwise__ __attribute__((bitwise)) > +#else > +#define __bitwise__ > +#endif > +#ifdef __CHECK_ENDIAN__ > +#define __bitwise __bitwise__ > +#else > +#define __bitwise > +#endif > + > +typedef __u32 __bitwise __le32; OK, this part is a bit tricky... Could you try to explain it? AIUI, it defines __le32 equal to __u32, except that it adds __attribute__((bitwise)) if both __CHECKER__ and __CHECK_ENDIAN__ are defined, so that sparse can warn on mismatches. However, I'm not sure whether the intemediate __bitwise__ and __bitwise symbols are used anywhere else? Otherwise, the multi-step definition seems circuitous... Or did you take it directly from the real linux/types.h? -antrik-