That looks fine to me.
Hi,
Alle venerdì 20 luglio 2012, Roland McGrath ha scritto:
> > Ok, I see that its `buf' argument is marked nonnull. I added that
> > check because I saw the gnulib test for it explicitly checking
> > that ptsname_r(fd, NULL, 0) would be properly failing with EINVAL
> > (and the man page even expl
That is fine as is, though it's preferable to use C99-style inline
declarations.
Alle lunedì 19 novembre 2012, Roland McGrath ha scritto:
> That change is good but it needs a comment. You don't need to go
> into great detail, just say that we call fprintf+fclose after
> clearing the hooks to match how mtrace called fopen+fprintf before
> setting them.
A bit of comment added.
I don't think losing __UL_GETMAXBRK is really a problem. The reason for
removing it was not specific to Linux, just to the implementation being in
a shared library. It could be implemented in a shared library, at the cost
of a GOT reloc for _etext to get the main executable's value (or
conversely
That's fine.
Hi,
Alle lunedì 19 novembre 2012, Pino Toscano ha scritto:
> simple implementation of the Linux-ish syncfs on Hurd.
Updated patch according to Roland's and Christoph's comments (thanks!)
--
Pino Toscano
Hurd: implement syncfs
2012-11-19 Pino Toscano
* sysdeps/mach/hurd/syncfs.c: New file.
Alle lunedì 19 novembre 2012, Roland McGrath ha scritto:
> sysdeps/posix is appropriate because it's implemented in terms of
> POSIX interfaces.
OK.
> It's bad to lose any functionality, though __UL_GETMAXBRK actually
> being used seems a bit unlikely. But it's easy enough to add it.
Please no
> +/* Make all changes done to all files on the file system associated
> + with FD actually appear on disk. */
> +int
> +syncfs (int fd)
> +{
> + /* This is not actually synchronous; we don't wait. */
> + error_t err = HURD_DPORT_USE (fd, __file_syncfs (port, 0, 0));
Note that syncfs in Linu
That change is good but it needs a comment. You don't need to go into
great detail, just say that we call fprintf+fclose after clearing the
hooks to match how mtrace called fopen+fprintf before setting them.
Thanks,
Roland
sysdeps/posix is appropriate because it's implemented in terms of POSIX
interfaces.
It's bad to lose any functionality, though __UL_GETMAXBRK actually being
used seems a bit unlikely. But it's easy enough to add it. So I'd do:
First commit: move file verbatim to sysdeps/posix/.
Second commit: ad
> > +/* Make all changes done to all files on the file system associated
> > + with FD actually appear on disk. */
> > +int
> > +syncfs (int fd)
> > +{
> > + /* This is not actually synchronous; we don't wait. */
> > + error_t err = HURD_DPORT_USE (fd, __file_syncfs (port, 0, 0));
>
> Note t
Hi,
simple implementation of the Linux-ish syncfs on Hurd.
Thanks,
--
Pino Toscano
Hurd: implement syncfs
2012-11-19 Pino Toscano
* sysdeps/mach/hurd/syncfs.c: New file.
--- /dev/null
+++ b/sysdeps/mach/hurd/syncfs.c
@@ -0,0 +1,33 @@
+/* Copyright (C) 2012 Free Software Foundation, Inc.
+
The top line of every new file is a descriptive comment.
You don't need #include in that file.
Hi!
Welcome Matthew to GNU Hurd development! :-)
On Mon, 19 Nov 2012 15:02:52 +, Matthew Leach wrote:
> Some versions of gcc will error if you define a type twice (even if
> the definition is the same). The ncr53c8xx scsi driver defines
> 'vm_offset_t', this is also defined in mach_types.h
Some versions of gcc will error if you define a type twice (even if
the definition is the same). The ncr53c8xx scsi driver defines
'vm_offset_t', this is also defined in mach_types.h and will therefore
cause a compilation error depending on the gcc version.
* linux/src/drivers/scsi/ncr53c8xx.c: ex
Hi!
As discussed on IRC already, the 'diff != 0' GNU Mach assertion failure
(vm/vm_map.c:1002), that came in with the recent allocator improvement
patch, is as easy as follows to reproduce:
vm_map(mach_task_self(), 0, 0, 0, 1, 0, 0, 0, 0, 0, 0);
Before that patch, GNU Mach accepted such a ca
17 matches
Mail list logo
