Re: It says HURD 0.6 should be released somewhere in 2013. It's not
Andrew Staunder, le Wed 01 Oct 2014 18:55:51 -0700, a écrit : > 2013-XX-XX > Version 0.6 That only means 0.5 was released in 2013. Nothing more. > Are there a list of improvements or anything that have happened since the > last release? That has just been added to the NEWS file a few days ago. Samuel
It says HURD 0.6 should be released somewhere in 2013. It's not
Hey guys, I've recently learned about GNU HURD, I'm a linux user. But not a programmer. So I'm sorry I can't help :(. But I do have a question. I was looking up the source code of the HURD on savannah, even though I dont know how to read it, I still like to look at it XD. But something that struck me as peculiar was this http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS Notice how it says : 2013-XX-XX Version 0.6 Though 0.6 has never been released. The latest release that Debian HURD uses is 0.5. Why is that? Is there going to be another release this year? Are there a list of improvements or anything that have happened since the last release? I hope this isn't too overwhelming or a waste of time for you.
mtab and firmlink loop
Hello, We're having issues with schroot and mtab on exodar. Looking a bit at rpctrace, one can see things like this: /home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/srv/chroot/schroot-unpack/youpi/home/schroot/mount/youpi/srv/chroot/schroot-unpack/youpi/servers I have indeed made a bunch of firmlinks: /srv is a firmlink to /home/srv, and /home/srv/chroot/schroot-unpack/youpi/home is a firmlink to /home, thus forming a loop. Can mtab properly cope with this? Samuel
Re: [PATCH,Hurd] Fix F_*LK* fcntl with __USE_FILE_OFFSET64
> 2014-08-31 Samuel Thibault
>
> struct flock64 uses 64bit values. This introduces other values for
> F_GETLK, F_SETLK, F_SETLKW to distinguish between both.
>
> * sysdeps/mach/hurd/bits/fcntl.h (F_GETLK64, F_SETLK64, F_SETLKW64):
> New
No blank line between the (optional) overview description of the paragraph
and the first (required) file line. Use tabs rather than spaces for the
indentation of the log entry.
> * sysdeps/mach/hurd/flockconv.c: New file.
> * sysdeps/mach/hurd/fcntl.c (__libc_fcntl): Include "flockconv.c",
> handle F_GETLK64, F_SETLK64, F_SETLKW64 cases.
More bad indentation.
> +#ifdef __USE_FILE_OFFSET64
> +#define F_GETLK F_GETLK64
> +#define F_SETLK F_SETLK64
> +#define F_SETLKWF_SETLKW64
> +#else
> #define F_GETLK 7 /* Get record locking info. */
> #define F_SETLK 8 /* Set record locking info
> (non-blocking). */
> #define F_SETLKW9 /* Set record locking info (blocking).
> */
> +#endif
"# define" when inside "#ifdef".
> + case F_GETLK64:
> + result = fcntl (fd, F_GETLK, &fl);
If you're actually going to have it call itself recursively, then call
__libc_fcntl, not the alias name. But that's not the right thing to do
anyway. Instead, break out the locking cases into a subroutine that you
can call for both versions.
> + if (sizeof *buf == sizeof *buf64
> + && sizeof buf->l_start == sizeof buf64->l_start
> + && sizeof buf->l_len == sizeof buf64->l_len)
> +{
> + *buf = *(struct flock *) buf64;
> + return 0;
> +}
For paranoia's sake, test offsetof matches for each field too.
Why is this a separate file #include'd if it has only the one use?
Just put it directly into fcntl.c instead.
But given the actual implementation in fcntl, I don't think this generic
conversion layer is actually the useful thing to use. You can just make
the new subroutine take the few individual fields that are used as
individual parameters instead of using any struct. You can just do the
EOVERFLOW checks directly before calling the subroutine. Since we don't
actually support F_GETLK, there is no conversion to do in the opposite
direction.
Thanks,
Roland
Re: [PATCH 7/7] procfs: provide magic retry response for /proc/self
> > + "proc/self/..." means replace `proc/self' with the PID of the current > > +process and then retry as for FS_RETRY_NORMAL. > > Roland, does it look OK to use a FS_RETRY_MAGICAL for implementing > /proc/self? FS_RETRY_MAGICAL is appropriate. But the string itself should more generally describe what it means rather than referring to a specific use case, and should definitely not contain a slash. I'd use just "pid" or perhaps "self-pid" (but it's not "self-tty", so "pid" is probably right). The description should be complete and not leave details to the imagination or presumption: here the omitted detail is the formatting of the number; you can say "in minimal decimal" or you can say "in %u format" to unambiguously mean the same thing. Thanks, Roland
Re: [PATCH gnumach] Add protected payloads to NEWS
Richard Braun, le Wed 01 Oct 2014 16:59:57 +0200, a écrit : > On Wed, Oct 01, 2014 at 03:57:14PM +0200, Justus Winter wrote: > > +A protected payload can now be associated with capabilities. This > > +payload is attached by the kernel to delivered messages and can be > > +used to speed up the object lookup in the receiving task. > > Very good job, looking forward to seeing this in the Debian packages :). Yep, definitely :D Samuel
Re: [PATCH gnumach] Add protected payloads to NEWS
On Wed, Oct 01, 2014 at 03:57:14PM +0200, Justus Winter wrote: > +A protected payload can now be associated with capabilities. This > +payload is attached by the kernel to delivered messages and can be > +used to speed up the object lookup in the receiving task. Very good job, looking forward to seeing this in the Debian packages :). -- Richard Braun
Re: [PATCH gnumach] Add protected payloads to NEWS
Ack. Justus Winter, le Wed 01 Oct 2014 15:57:14 +0200, a écrit : > --- > NEWS | 4 > 1 file changed, 4 insertions(+) > > diff --git a/NEWS b/NEWS > index 9a9f620..357b23f 100644 > --- a/NEWS > +++ b/NEWS > @@ -5,6 +5,10 @@ Numerous cleanups and stylistic fixes of the code base. > Several > problems have been identified using static analysis tools and > subsequently been fixed. > > +A protected payload can now be associated with capabilities. This > +payload is attached by the kernel to delivered messages and can be > +used to speed up the object lookup in the receiving task. > + > The kernel debugger can now parse ELF symbol tables, can be invoked > over serial lines, gained two new commands and has received usability > improvements. > -- > 2.1.0 > -- Samuel ***e trouve un .xls ***e passe un moment à se demander quelle version de xml c'est ça, le .xls e: donc j'ai fait un file -+- #sos - on n'a pas forcément les mêmes références que tout le monde -+-
[PATCH gnumach] Add protected payloads to NEWS
--- NEWS | 4 1 file changed, 4 insertions(+) diff --git a/NEWS b/NEWS index 9a9f620..357b23f 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,10 @@ Numerous cleanups and stylistic fixes of the code base. Several problems have been identified using static analysis tools and subsequently been fixed. +A protected payload can now be associated with capabilities. This +payload is attached by the kernel to delivered messages and can be +used to speed up the object lookup in the receiving task. + The kernel debugger can now parse ELF symbol tables, can be invoked over serial lines, gained two new commands and has received usability improvements. -- 2.1.0
