Neal,
> My problem is not so much with setting the owner and changing the file
> mode, but rather, using the author field for the creator uid and the
> flags for the pid of the last operation, etc. Please understand that
> I was sloppy as it was not my intention to decide what to overload
> with
Neal,
Thanks for doing the cleanup. I'll try to study your changes and
improve
next time. I'll concede that there was probably a logic error or two
in there and I didn't throw any mutexes in for thread safety. My fault.
The file 'list.h' comes from the Linux source and I like to use it
becuase
Hi,
This probably belongs on bug-oskit or something instead of
here, but I just thought I'd point out a problem I found
in the oskit St. Patrick's day release (and prior releases)
dealing with the partition table reading. It manifested
itself when I began trying to use oskit-mach instead of
gnuma
Hi,
At the risk of being too abrasive, I'd like to weigh in on the
issues of performance characterization I saw during the course
of this thread and hope to clear up a potential misunderstanding.
I begin by examining an argument presented on CPU utilization and
move on to provide what I believe i
I noticed this activity as well quite a while back. It's not
limited to 'rm'. I also wrote a similar test script with 'mv'
and even a 'hello-world' with 'rename' to continuously rename
a file from 'foo.0' to foo.fff and the drive light just went
_crazy_. As you observed, the same sort of th
+ iskey = 1;
+ case 'm':
+ {
+ error_t err;
+ int id;
+ char *end;
+
+ id = strtol (arg, &end, 0);
+ if (! end || *end != '\0')
+ {
+ printf ("Invalid id
/
if (buf->shm_nattch == 1) {
err = unlink(shm->pathname);
}
break;
default:
errno = EINVAL;
err = -1;
}
return err;
}
Marcus Brinkmann wrote:
>
> On Thu, Mar 21, 2002 at 11:05:21PM -0700, Jon Arney wrote:
> > James,
> >
> > Tha
James,
Thanks for the links. One of the difficult things about coming up to
speed on the Hurd is that there are so many different websites with
lots of (sometimes conflicting) information. I didn't know that a
/proc filesystem already existed, but I did look for one. If I had
known, I might ha
Marcus,
Thanks for all your feedback. I've responded to most of the points
below.
> Do you know about Neal Walfields procfs which he wrote a couple years
> ago? He says it is broken but it might be worth looking into for you.
Actually, I didn't even know it existed. If you point me at the sou
Hi all,
I've been busy the last week or so putting together a first pass at
a Linux style /proc filesystem translator. It seems to have barely
enough smarts in it now to support the 'procps' package (not that
procps is better than the native Hurd utilities). The intent here
was to start with a L
Roland:
> I checked in the fix for that stupid libc bug (d'oh!).
No problem. Just glad I could help in some small way.
> As to gdb, did you test the gdb "gcore" command? Your patch didn't include
> any changes to the gnu_find_memory_regions function, but you also didn't
> say that it works. Si
Hurah!
At long last, I have succeeded in getting the following program
to produce and read a core file under the Hurd:
int main(int argc, char **argv){char *p = NULL; *p = '\0';}
This is not a done project, but I think enough is working to
upload some patches. There are some known issues/limita
Roland McGrath wrote:
>
> The proc server is not really much involved. You need to understand the
> structure of the system and what Mach tasks and threads are about in some
> detail before attempting to work on this.
I can always attempt. Whether I succeed or not depends on my
understanding.
I
>
> If sending something over a socket causes the socket server to log a
> message, then you have a serious problem anyway.
>
> The same problem exists in a more minimal model: If writing something to a
> file causes the filesystem server to log a message, then you are in big
> trouble.
I agre
Aparently I stand corrected. Apologies and thanks for your
patience.
>
> What do you mean by "its present state." And if syslogd is lacking,
> would it not, perhaps, be better to try to extend it?
As I said, I am not opposed to using syslogd and think starting there
is a good idea. If you bel
Neal H Walfield wrote:
>
> Can you justify why this is better than syslog?
It is not inherently better than syslogd. It does, however,
serve a slightly different class of process. I am not opposed in
principle to adapting syslog to handle Hurd/Mach ports as
opposed to Unix domain sockets or UD
Hello,
At the risk of beating a dead horse and annoying you all
terribly much, I would like to submit some of my thinking
on a Hurd logging facility. Feel free to tear this to
shreads, but I think the discussion should be started
and work begun on a solution to the problem of what to
do about a h
> Indeed. There are some bugs, either resource leaks in the Hurd system
> or in the kernel (or even some other bug). We are currently lacking data
> to give a good interpretation for the zalloc problems.
Good to know it's not just me!
>
> When we use oskit-mach we can get better data with gdb
n get information on the panic. Hindsight
is 20:20 in that I realize I should have enabled the debugger.
Nonetheless, I think my recommendation stands.
#if MACH_KDB
eplace these with 'off64_t'
but it seems that much care would be required in making these
changes. What I am most concerned about is the buffer interface
with 'vm_offset_t' which is also defined to be 'natural_t' and
thus the VM buffering of pages with offsets larger t
Hi,
I've been playing around with the Hurd on my Linux box
and sharing filesystems between the two of them. I have
one partition which I use as a repository for lots of GNU
and other free software I'm compiling under the Hurd.
I'm running into a problem, however, when I mount (set translator for
Marcus Brinkmann wrote:
>
> It should definitely fail with ELOOP.
I aggree.
>
> The bug is probably in glibc/sysdeps/mach/hurd/access.c, which is the
> implementation of access() on the Hurd. That would be a good place to
> start your research. (Could also be in the file name lookup itself,
Hi.
In the course of "building my own" hurd system from the
sources, I came across an interesting "feature" of the
access() call. It happened accidentally, and took me a little
while to figure out what caused it, but I have an easily
reproducable test-case for it. The upshot of the whole
thing i
23 matches
Mail list logo
