I think libc-lock.h's comments are pretty self-explanatory. It is the
interface for locks internal to the "generic" parts of libc.
In a full-fledged integrated pthreads implementation,
linuxthreads/sysdeps/pthread/bits/libc-lock.h is probably about right.
Note that the low-level hurd-specific
I found a header in glibc that defines a generic lock interface.
The file is sysdeps/generic/bits/libc-lock.h. There is a Mach
specific version of it in sysdeps/mach/bits. It is implemented
on top of cthread locks.
Was intended to be a high level or low level lock inteface?
So should I try to re
> It is Hurd convention not to presume that MACH_PORT_NULL==0.
Ok, how about the other half of the patch?
PGP signature
It is Hurd convention not to presume that MACH_PORT_NULL==0.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
How about this version? I don't like the looking up "." paradigm.
Index: dir-lookup.c
===
RCS file: /cvs/hurd/libdiskfs/dir-lookup.c,v
retrieving revision 1.46
diff -u -b -p -r1.46 dir-lookup.c
--- dir-lookup.c 2001/06/16 20:23
Two small clean ups:
libdiskfs/ChangeLog:
2001-06-20 Neal H Walfield <[EMAIL PROTECTED]>
* ifsock.c (pflocalserver): Elide superfluous initialization to
zero.
(diskfs_S_ifsock_getsockaddr): Don't use sprint when we can just
use the preprocessor.
Index: ifsock
Here is a new patch. A test run:
neal@desdemona:~/foo (0)$ ls -l
total 0
-rw-r--r--1 neal neal0 Jun 20 22:44 a
-rw-r--r--1 neal neal0 Jun 20 22:44 b
-rw-r--r--1 neal neal0 Jun 20 22:44 c
l
> I have a change that pleases me aesthetically. Can you tell me if this
> works? (The indentation in the patch is all messed up by cut&paste in this
> message.)
This does not work at all.
>
> Index: dir-lookup.c
> ===
> RCS file
On Wed, Jun 20, 2001 at 07:00:08PM -0400, Igor Khavkine wrote:
> On Wed, Jun 20, 2001 at 06:45:39PM -0500, Neal H Walfield wrote:
> > > I don't think the danger (or lack thereof) presented by these warnings
> > > is being dsiputed. It is simply very annoying. I have a patition
> > > for developmen
Package: gnumach
Version: 1:1.2-10
Severity: important
The gnumach package expects to be built via dpkg-buildpackage, and doesn't
cope with good ole "debian/rules build". Naughty.
Patch follows. I've changed the make var names for consistency, so that
"debian/rules build DEB_BUILD_GNU_TYPE=foo"
On Wed, Jun 20, 2001 at 06:45:39PM -0500, Neal H Walfield wrote:
> > I don't think the danger (or lack thereof) presented by these warnings
> > is being dsiputed. It is simply very annoying. I have a patition
> > for development that I use both in linux and Hurd.
>
> I think it was; Roland mentio
> I don't think the danger (or lack thereof) presented by these warnings
> is being dsiputed. It is simply very annoying. I have a patition
> for development that I use both in linux and Hurd.
I think it was; Roland mentioned this earlier.
> And when I run
> a build from that partition while in
On Wed, Jun 20, 2001 at 04:56:20PM -0500, Neal H Walfield wrote:
> > Would you accept a patch to add a configure option that removes the
> > annoying 'free inode' warning messages? I can set it on by default,
> > if you'd like.
> >
> > My final preference would be to leave it disabled until e2fs
> Would you accept a patch to add a configure option that removes the
> annoying 'free inode' warning messages? I can set it on by default,
> if you'd like.
>
> My final preference would be to leave it disabled until e2fsck is
> willing to fix the problem when the FS is checked with -f, but havi
Roland, et al.,
Would you accept a patch to add a configure option that removes the
annoying 'free inode' warning messages? I can set it on by default,
if you'd like.
My final preference would be to leave it disabled until e2fsck is
willing to fix the problem when the FS is checked with -f, but
15 matches
Mail list logo
