[EMAIL PROTECTED] (Niels Möller) writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Is it intentional that unlink() on GNU/Hurd does not handle
directories?
Yes.
How will this work for nodes that are both directories and files
Alfred M. Szmidt [EMAIL PROTECTED] writes:
Is it intentional that unlink() on GNU/Hurd does not handle
directories?
Yes.
It seems that unlink() (a syscall from the looks) on GNU/Linux does
handle directories. But POSIX doesn't say anything if unlink() must
handle them.
Quite right.
Michael Koch [EMAIL PROTECTED] writes:
I tried ti build current hurd pachage with current gcc 3.2.1. I needed
the attached patch to make it compile. Please review and apply it.
I have no objection to this; it's annoying in the extreme that gcc has
broken compatibility here, but so be it.
James Morrison [EMAIL PROTECTED] writes:
Looking at [hurd]/hostmux/hostmux.h I noticed a strange comment.
/* The state associated with a host multiplexer translator. */
struct hostmux
{
/* The host hodes in this mux. */
struct hostmux_name *names;
struct rwlock names_lock;
Robert Millan [EMAIL PROTECTED] writes:
On Thu, Oct 24, 2002 at 11:05:56AM -0700, Thomas Bushnell, BSG wrote:
Robert Millan [EMAIL PROTECTED] writes:
According to documentation of BSD Unix [1], the uname command appeared
in 4.4BSD distribution, and the -s option is suposed to:
Oy
Tom Hart [EMAIL PROTECTED] writes:
Doesn't a lot of this confusion come from:
1. No enforced standardization of terminology.
The GNU project uses the term operating system to refer to the
complete *usable* system, ie. GNU, GNU/Hurd, GNU/Linux, and kernel
to refer to the kernel, ie.
Robert Millan [EMAIL PROTECTED] writes:
According to documentation of BSD Unix [1], the uname command appeared
in 4.4BSD distribution, and the -s option is suposed to:
Oy, it gets even more confusing. BSD has always used the term
operating system to refer to the kernel.
In any case, the
Moritz Schulte [EMAIL PROTECTED] writes:
Just curious; was there something wrong with that patch?
Nothing that pops out at first, but perhaps nobody has had a chance to
look at it in detail.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
Petri Koistinen [EMAIL PROTECTED] writes:
I think uname -s should print: GNUmach.
uname -s prints the kernel, but it's the kernel in Unixspeak, that
is, the thing that interprets the system calls where the system
calls are read/write/open.
In other words, the canonical case is a monolithic
Your mailer bounces valid mail for no reason; you need to fix it if
you are going to continue to post on bug-hurd.
A sample message was returned thus with the message:
[EMAIL PROTECTED]
SMTP error from remote mailer after RCPT TO:[EMAIL PROTECTED]:
host joo.ath.cx [80.222.59.131]: 554
Moritz Schulte [EMAIL PROTECTED] writes:
was there ever a plan to make Hurd servers support configuration
files? Right now the only way to configure them is via command line
options. I think it could be convenient in the future to have them
support configuration files; there could be
Marcus Brinkmann [EMAIL PROTECTED] writes:
Now, it seems to be rather easy to me to implement the retry magic for tcp
and udp in glibc/hurd/lookup-retry.c as well. Roland, is this worth punting
to a volunteer or would that be more trouble than just doing it yourself
right quick? For me it's
Thomas Sippel - Dau [EMAIL PROTECTED] writes:
o are not formally static libraries (/lib) or shared objects (/lib)
The conceptual difference between a directory and a library
escapes me, essentially, libraries are more efficient to read
than directories, and more
Thomas Sippel - Dau [EMAIL PROTECTED] writes:
o are not formally static libraries (/lib) or shared objects (/lib)
The conceptual difference between a directory and a library
escapes me, essentially, libraries are more efficient to read
than directories, and more
lilachaze [EMAIL PROTECTED] writes:
Hi.
libdiskfs has a nasty bug moving directories in a special case:
If the source dir's parent is not writable by you, but the dir itself is, and
you try to move it, the ext2fs server crashes leaving your fs corrupted. The
cause is that it doesn't
Wolfgang Jaehrling [EMAIL PROTECTED] writes:
On Mon, Oct 07, 2002 at 04:34:07PM -0500, Graham Wilson wrote:
what is this cancellation stuff? is there documentation about it
somewhere?
And more importantly, is this also the case when writing new servers
with pthreads? (Ignoring that we
Bryan Wagstaff [EMAIL PROTECTED] writes:
But basically, yeah, if someone opens for O_WRONLY, writes, and
closes, it would be nice if the old contents were cleanly saved as a
version.
That could get really nasty when it comes to large files that are
opened/closed frequently. It also
[EMAIL PROTECTED] (Niels Möller) writes:
My main concern is that the file update pattern open, write, close,
should be atomic when seen by other processes. I.e if some other
process opens the file for reading in the middle of the update, it
should see the previous version, independently of
[EMAIL PROTECTED] (Niels Möller) writes:
I hope you mean putting it into glibc, so that the rm program won't be
special?
I have no particular preference here. It's a user-interface feature,
as I see it.
I can see two reasons to put the versioning features in the filesystem
rather than in
[EMAIL PROTECTED] (Niels Möller) writes:
Could be. I think it would make sense to start by outlining the
filesystem interface (rpc:s for listing old versions/deleted files,
opening or recovering an older version (probably, linking it to a new
name should be an optional part of the process?),
Marcus Brinkmann [EMAIL PROTECTED] writes:
I wonder, should undeletion (aka the Windows trash can) better be done at a
per-filesystem level (like, in diskfs), or with an extra-filesystem that is
stacked (like shadowfs)?
Undeletion, without exact semantics, is a mistake, wherever it is
Marcus Brinkmann [EMAIL PROTECTED] writes:
I think that might just have been an oversight, and it seems entirely
reasonable for filesystems to refuse to do anything synchronous (let the
message queuing do it).
If Thomas agrees, I will change it to simpleroutines, because I agree.
This
Marcus Brinkmann [EMAIL PROTECTED] writes:
BTW, Thomas, while we are chatting about pagers. I remember Roland
told me the thread explosion in the server is a known problem with
the Mach virtual memory management. Can you briefly wrap up an
example for a typical behaviour that can cause it?
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Wed, Jun 12, 2002 at 10:32:21AM -0700, Thomas Bushnell, BSG wrote:
Map a big region, start modifying pages. Eventually you will trigger
pageout. The kernel will now proceed to start paging things out: all
at once.
Ok, I see. How about
Marcus Brinkmann [EMAIL PROTECTED] writes:
Ok ;) I do this in my current version, and it seems to work fine. I will
check in the code right now, but I have one more question. When using
libpager, I must provide my own backing store, right? At any time, it can
happen that pager_write_page
Marcus Brinkmann [EMAIL PROTECTED] writes:
the way I read the diskfs code, requesting file notifications doesn't
add a reference to the node. So when you request notifications as a
user, you have to keep the port around to receive notifications.
Is this how it is intended to be?
Seems
Roland McGrath [EMAIL PROTECTED] writes:
I am confused as to why using default_pager_object_create is not working.
That's what tmpfs does.
Me too; I think it should work...
___
Bug-hurd mailing list
[EMAIL PROTECTED]
Marcus Brinkmann [EMAIL PROTECTED] writes:
First I tried to use libpager. This worked out ok, but what I did was
probably wrong. I allocated anonymous pages in pager_read_page, and
filled those with the display information. The information could then
be read by the client, allright. But
David Walter[EMAIL PROTECTED] writes:
This assignment is prior to the assertion.
msgid = m-request.msgh_id
The assertion is testing for msgid+100 == m-header.msgh_id
Is there a protocol that defines why this value should be 100 than
the assigned value?
Yes. MiG reply
Roland McGrath [EMAIL PROTECTED] writes:
ids -- Does pid2task to query arbitrary processes auth ports.
Seems like a questionable need. If that info should be public,
we could just have the proc server publish the id lists it got
in its auth transactions (which
Marco Gerards [EMAIL PROTECTED] writes:
I thought about an other solution for the problem, although it is a stange
solution it might solve the problem. The thread in fatfs will deadlock
because that thread already locked the node, what if the function that locks
the node check if the node
Marcus Brinkmann [EMAIL PROTECTED] writes:
how am I supposed to get the openmodes in netfs callbacks like
netfs_attempt_read?
This is critical to implement O_NONBLOCK behaviour correctly.
But the interface is giving me user-user and user-po-np,
but I need user-po-openmodes.
Netfs
Marcus Brinkmann [EMAIL PROTECTED] writes:
how am I supposed to get the openmodes in netfs callbacks like
netfs_attempt_read?
To echo Roland's comments, and call for something new:
netfs is being stretched *way* beyond its intentions here. I would
much rather see a *new* library, parallel
[EMAIL PROTECTED] (Niels Möller) writes:
I'm not sure you're really asking about the C details, but if you are,
the answer is something like
#define COMPARE(type) \
int \
ps_cmp_##type(type a, type b) { ... }
Note that there must be no space between COMPARE and (, and that you
Wolfgang Jährling [EMAIL PROTECTED] writes:
Thomas Bushnell, BSG [EMAIL PROTECTED] wrote:
One idea is just a straightforward file somewhere in the filesystem
that holds an index of inode numbers and UIDs.
Will we use 64-bit UIDs on 64-bit systems? If so, we should use 64 bit
wide UID
Wolfgang Jährling [EMAIL PROTECTED] writes:
This overflow UID can be set with sysctl(8) and defaults to the value
65534 (not 65535, as one might expect). It seems to be good enough for
Linux, but I'm not sure if it is good enough for us, so how should we
handle this situation? Storing the
Jeroen Dekkers [EMAIL PROTECTED] writes:
But they don't use it because they are lazy?
No, the diacritical marks were never necessary.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Lionel Elie Mamane [EMAIL PROTECTED] writes:
E.g. hair would be pronounced approx. like english hair, but haïr
(ha\ir) is ha-yir.
Ah, that's roughly the same meaning that a diaeresis has in English.
Many English speakers have failed to note that English actually has
diacritical marks. The
Patrick Stasser, mail to you from me bounces. I get the following:
553 5.3.0 [EMAIL PROTECTED]... We do not accept SPAM therefore your mail was
rejected - see http://www.dnsrbl.net/
And oh-so-helpfully, that URL gets nothing but an empty under
construction message.
If you want to be on this
Marcus Brinkmann [EMAIL PROTECTED] writes:
So, what you do is you have a special translator on /dev. What does it do?
Does it provide a virtual filesystem hierarchy, a bit like the mux
filesystems do, or would it be more like fakeroot translator, passing most
accesses through, but catching
Roland McGrath [EMAIL PROTECTED] writes:
We have to implement
netfs_S_dir_lookup ourselves, so that it can return partial results using
FS_RETRY_MAGICAL to the user.
I think this is generally true for weird things like fakeroot. Back
when, this was my general intention for weird things,
Roland McGrath [EMAIL PROTECTED] writes:
But isn't this connected to the case of whether the /dev/fd method
works? If we make that method work, then the io_identity check isn't
necessary, right?
The other method is still preferable.
Hrm, I'm beginning to wonder whether the mere fact
Roland McGrath [EMAIL PROTECTED] writes:
Hrm, I'm beginning to wonder whether the mere fact that fakeroot can
fake this doesn't mean that the io_identity check isn't sufficient for
the security that #! execution needs...
It only needs security for EXEC_SECURE, in which case a) it
Roland McGrath [EMAIL PROTECTED] writes:
I'm pretty sure that fakeroot should *not* override identity--for the
reason at least that it is *NOT* the same node.
But it's pretending to be.
It is either indistinguishable, in which case it doesn't need to
exist, or it has *some* difference in
Marcus Brinkmann [EMAIL PROTECTED] writes:
Well, we are not really talking about file_chmod, but about
netfs_attempt_chmod. However, I have not found it to be used by anything
but netfs_S_file_chmod.
The original comment is in libnetfs/netfs.h
Ok, that internal interface is used to set
Roland McGrath [EMAIL PROTECTED] writes:
However, I think diskfs should not return EOPNOTSUPP for this case. On
Unix systems I have tried, trying to execute a device file (that has
execute bits set) fails with EACCES. That seems like the appropriate error
for attempting to open a symlink
[EMAIL PROTECTED] (Niels Möller) writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Right, but that's already a Hurd-specific extension. So it's fine to
expect it to use another Hurd-specific extension to get a reliable PID
or other identification.
What would such an extension
Marcus Brinkmann [EMAIL PROTECTED] writes:
There is another problem with fakeroot, and that is chmod. It doesn't work
at all :) I always get EOPNOTSUPP. Your comment:
Unlike the normal Unix
and Hurd meaning of chmod, this function is also used to attempt to
change files into
Roland McGrath [EMAIL PROTECTED] writes:
Duh. The file_exec to the underlying node calls exec_exec with a port to
the underlying node, but the INIT_PORT_CRDIR used to start the lookup is
the fakeroot one. We should probably override netfs_S_io_identity to lie
and return the underlying
Roland McGrath [EMAIL PROTECTED] writes:
The only drawback I see is in the case when svuid!=euid or svgid!=egid, and
you are executing an sugid file. The user will reauthenticate everything
for the svuid=euid, svgid=egid change and then the filesystem will
reauthenticate everything again to
Marcus Brinkmann [EMAIL PROTECTED] writes:
It seems that the shared I/O code is not really tested and a bit dated.
Thomas, do you remember any unresolved issues about it?
Only that it's essentially untested, and really deprecated. Roland,
do you think it's worth keeping around? Is there
Marcus Brinkmann [EMAIL PROTECTED] writes:
For shared libraries, we use MAP_COPY. Maybe we can use this for
executables, too?
That is what we do, but the present issue is different; we're talking
only about atomicity: that is, if you write the file, then your exec
is either the pre-write
Roland McGrath [EMAIL PROTECTED] writes:
Yes, that seems to be a bona fide bug based on a misreading of the
standard. The language is not really all that clear, but the
behavior of other systems is consistent so we can tell how to read
it. That is, svuid=euid and svgid=egid are done *on
Roland McGrath [EMAIL PROTECTED] writes:
Oh this is horrible. Sigh. However, in the normal case, the ids
don't change. Is there a security reason we should not allow the user
to decide for themselves?
Allow the user to decide for themselves does not have a precise meaning
to me in
Roland McGrath [EMAIL PROTECTED] writes:
To make cases like the current state less confusing, perhaps netfs (and
diskfs) should do something special for an EOPNOTSUPP return from
*_get_translator in lookup/getroot. It will only come up there if
S_IPTRANS is set, which the *_validate_stat
Marcus Brinkmann [EMAIL PROTECTED] writes:
I think it is absolutely mandatory that we establish the PID in a
trustworthy way rather than let the user provide some unique ID on its own.
I think there is already a place in the Hurd where we should do that but
don't (wasn't that term's
Marcus Brinkmann [EMAIL PROTECTED] writes:
Mmh, we could restrict the monitor to trusted filesystems (eg /).
Right, but that's already a Hurd-specific extension. So it's fine to
expect it to use another Hurd-specific extension to get a reliable PID
or other identification.
I am not really
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Thu, May 09, 2002 at 07:39:57PM -0700, Thomas Bushnell, BSG wrote:
Marcus Brinkmann [EMAIL PROTECTED] writes:
Note that there is no way to get levels inbetween if the translators don't
provide them.
This has long been noticed; you
Marcus Brinkmann [EMAIL PROTECTED] writes:
Note that there is no way to get levels inbetween if the translators don't
provide them.
This has long been noticed; you can always go one at a time if you are
the owner.
___
Bug-hurd mailing list
[EMAIL
Roland McGrath [EMAIL PROTECTED] writes:
Probably the right thing to do is unlock the directory node while doing the
lookups.
This is certainly what diskfs does, and it's pretty important.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Niels Möller) writes:
Does anybody have any idea how often this case occurs with typical
activities like compilation?
What's the point of the question: to decide if we can ignore the
issue, or to decide if the solution has to be terribly efficient?
With the current code,
[EMAIL PROTECTED] (Niels Möller) writes:
I guess I should have asked for the ratio B/A. If that's small, as you
claim, there should be a significant gain. _If_ it turned out that A
and B were of the same size, then the gain would be quite small,
decreasing the number of required syncs at
Jeroen Dekkers [EMAIL PROTECTED] writes:
The bugs that happen are *not* merely that you lose occasional object
files. You can get arbitrary corruption.
And then fsck can repair that in the case of a crash, right?
No.
The normal rules--the ones that I describe as bug free keep things
[EMAIL PROTECTED] (Niels Möller) writes:
Right, it would improve the speed significantly, but it wouldn't get
rid of the harddisk is thrashing hard all the time while I'm
compiling, even if I have plenty of RAM and all the source files are
cached-behaviour.
I have found that compiling is a
Jeroen Dekkers [EMAIL PROTECTED] writes:
Sorry for my stupidity, but I don't see why fsck can't remove the
corrupted part and replace it with some sane stuff. It knows how the
filesystem should look like, so it can change it so that it will look
like that. Could you please explain why that
Jeroen Dekkers [EMAIL PROTECTED] writes:
But I was talking about a filesystem where it doesn't matter if there
is data loss in the case of a crash. For example, I wouldn't care if
the data of my glibc build is lost or corrupted. In that case we don't
need it and providing an option which
Roland McGrath [EMAIL PROTECTED] writes:
You are atypical. On my system, for any given build I do, all the files
fit in core and are already in the cache if I've done a previous compile
recently, and the only disk activity is writing of new bits that the
computation rarely blocks on.
Ok,
Oystein Viggen [EMAIL PROTECTED] writes:
* [Thomas Bushnell, BSG]
Yes, group 0 is the wheel group. HOW DOES THIS CAUSE A SECURITY
ISSUE? Please be specific and not vague.
Combined with umask 002 (suggested by yourself), this gives members of
the wheel group write access to all
Marcus Brinkmann [EMAIL PROTECTED] writes:
I think that I prefer Linux's behaviour.
I think, too, esp because of the sgid flag. I wonder what Thomas thinks.
The reason why the copy-gid-from directory behavior is better:
Imagine a rich set of groups on your computer--representing
[EMAIL PROTECTED] (Paul Jarc) writes:
This works with the SysV (aka Linux) behavior as well: if a directory
is setgid, any files created within it inherit the group id, and any
directories created within it inherit both the group id and the setgid
bit.
As long as the setgid bit is inherited
Oystein Viggen [EMAIL PROTECTED] writes:
The difference is that the SysV way won't work for more than one level
of directories. Once you start making dirs within dirs[1], your sgid is
not inherited, and group ownership falls back to your default group,
instead of what you want.
I was just
[EMAIL PROTECTED] (Paul Jarc) writes:
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
(You only inherit gid if you are a member of the group.)
False.
Sorry, you're correct. It is, however, no security hole of the sort
that was being implied
Roland McGrath [EMAIL PROTECTED] writes:
Sure there is. The basic requirement here is that the the OPEN_MAX limit
be enforced as specified, on the total of fopen+tmpfile + open and other
POSIX.1 calls (and probably some other ISO C call I am forgetting).
Ah, quite right, blech. I had
Marcus Brinkmann [EMAIL PROTECTED] writes:
I don't have my copy of POSIX around, but I also remember a vague
requirement (or expectation) that the file descriptor allocated
is always the smallest file descriptor available.
No, that's no requirement. It's the way Unix historically worked,
Roland McGrath [EMAIL PROTECTED] writes:
Roland McGrath [EMAIL PROTECTED] writes:
I think the Hurd libc implementation of tmpfile is at fault.
POSIX.1 says there must be a file descriptor. Try this libc patch.
Why do it this way? I would prefer having fileno generate the file
Marcus Brinkmann [EMAIL PROTECTED] writes:
Uh, I have now rebooted and the standard (the draft7 from the Austin
group) in front of me. Let's look at the details:
About open():
The open( ) function shall return a file descriptor for the named file that
is the lowest file descriptor not
Roland McGrath [EMAIL PROTECTED] writes:
I think the Hurd libc implementation of tmpfile is at fault.
POSIX.1 says there must be a file descriptor. Try this libc patch.
Why do it this way? I would prefer having fileno generate the file
descriptor, since most uses of tmpfile will probably
[EMAIL PROTECTED] writes:
FAT doesn't have inodes, so fatfs has to lock the node of the
directory that contains the node for which diskfs_cached_lookup is
called.
This is the root misconception. FAT *does* have inodes. What it
doesn't have is *disk inodes*. Or rather, it *does* have disk
Roland McGrath [EMAIL PROTECTED] writes:
This might be a known kernel problem, I'm just a bit sketchy on the details.
That is, the Hurd code that does wiring (libshouldbeinlibc/wire.c) makes
the pages writable and pokes them before doing vm_wire.
This is because there were kernel bugs if
Roland McGrath [EMAIL PROTECTED] writes:
It occurs to me that without this change, if a directory in a ufs or ext2fs
filesystem contains a link to itself by a name other than .., then a
lookup of that name will deadlock the directory node. (That is probably an
invalid state that fsck would
Neal H Walfield [EMAIL PROTECTED] writes:
I think we should certainly use vm_copy for whole-page copies in
pager_memcpy because of the badly suboptimal behavior you've described.
I have cooked up the attached implementation. I checked everything
but a few border cases -- I need to write
Ludovic Courtès [EMAIL PROTECTED] writes:
This kind of observation is quite normal I guess, due to the extensive use of
RPCs and so on, but are there still some optimizations that could be
implemented in order to reduce CPU consumption?
Where do you think the processor should be spending its
[EMAIL PROTECTED] (Niels Möller) writes:
Perhaps idling, waiting for disk i/o requests to complete?
Do a big tar extraction on Linux and note that your tar process soaks
up plenty of CPU time.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Niels Möller) writes:
The numbers depend a lot on the actual hardware, and the relative
speed of the cpu and disks, I think. I just tried extracting
gcc-3.0.4.tar (note, no .gz, unzipping would soak up most of the idle
time). top reported that the tar process consumed
Marcus Brinkmann [EMAIL PROTECTED] writes:
causes a lot of disk activity. Further tests showed that the disk is
activated for each rm. Is this a hard requirement? In Linux, the loop
above does not cause any disk activity (except at the beginning and
maybe at the end), it seems to be done
Atle [EMAIL PROTECTED] writes:
When running a telnet session from my Linux PC to a BSD box, I see the
disk lamp go on, and I hear the disk go 'chack' each time I press a key
on the keyboard!
It's updating the mtime on the terminal node.
___
[EMAIL PROTECTED] (Niels Möller) writes:
Is it not good enough to maintain the order of the writes, updating
diskblocks in the same order as the corresponding write by the client?
Yes, that's enough. But you cannot skip any writes.
One problem is that if the filesystem modifies block A,
[EMAIL PROTECTED] (Niels Möller) writes:
How hard would it be to create a new store type that basically
implements only a write-cache: It would have store_write put the
modified block into a queue, from which blocks are written to the
underlying store later by a separate syncing thread.
James A Morrison [EMAIL PROTECTED] writes:
init:
* init.c (reboot_mach): Use err, not errno.
(run): Likewise.
(lauch_core_servers): Likewise.
(run_for_real): Check against MACH_PORT_NULL instead of not(!) for
failure.
(start_child): Likewise.
It's
James Morrison [EMAIL PROTECTED] writes:
Previously netfs_make_protid set errno, no matter what. So to keep this
behaviour the patch would look like this.
There is no need to always set errno (though you should check all the
callers to make sure--which needed to be done first anyway).
Marcus Brinkmann [EMAIL PROTECTED] writes:
The implementation is using the Hurd's IO interface. It seems I was not
clear enough in my original mail. The translator creates a pipe to the
forked program, and translates io_read into a pipe read and io_write
into a pipe write. The translator
James Morrison [EMAIL PROTECTED] writes:
On around line 93 of fstests/fstests.c, there is a malloc of size 0, what
would
be the point of that?
Beats me. The program is just for testing, that is, it was there so
that we could easily have any random bit of code easily compiled to be
run.
James A Morrison [EMAIL PROTECTED] writes:
Ok, I've grep'd through the hurd source looking for instances of errno being
assigned directly. These seem to be the places where setting errno isn't
right.
What's the reason for this?
I've also changed !var to var == MACH_PORT_NULL where
Roland McGrath [EMAIL PROTECTED] writes:
What's the reason for this?
Getting at the thread-local errno tends to be rather a pain in gdb. And
the overhead of locating the thread-local errno slot is pretty spurious in
these cases when compared to a local variable that's just a register.
James Morrison [EMAIL PROTECTED] writes:
I've also changed !var to var == MACH_PORT_NULL where
appropriate because some documentation, mach.texi, says
MACH_PORT_NULL is not assumed to be 0 in the Hurd system.
This is always fine.
Yes, but I wanted to be consistant with the
Neal H Walfield [EMAIL PROTECTED] writes:
But, since the user, in this case, is in the same task, we can do some
black magic. Do you think that that is reasonable?
No, it seems like a bad way to spend effort right now. It would
seriously warp the structure of the thing, and we don't havy
Roland McGrath [EMAIL PROTECTED] writes:
And then the way to change that dynamically is to, well, do a setopts
call.
If there is some error and it can't read the file, then it returns an
error and leaves the previous keymap in place.
That seem utterly unacceptable to me based on
Roland McGrath [EMAIL PROTECTED] writes:
An alternative strategy (for the dynamic case) is to have the client
hand a port for the file to the console server, which can then read
from it exactly as if it were a file (which it normally will be).
Yeah, maybe. But that is certainly more of
Daniel Wagner [EMAIL PROTECTED] writes:
Calling device_write with an invalid data_count, device_write will return
an error (D_INVALID_SIZE). I didn't checked the return value, instead
I tested for the bytes_written and of course there's only a bogus
value.
This is a general rule for MiG
Roland McGrath [EMAIL PROTECTED] writes:
libstore uses device_map with size and offset being null.
Urmph. To my mind, this just illustrates that the current io_map interface
model is really wrong and that an io_map call that takes offset and size
parameters is the way to go (as is
301 - 400 of 528 matches
Mail list logo
