It's worth keeping in mind that there are very likely important security
bugs far more dangerous than rowhammer-style attacks in Mach, let alone the
Hurd. Security-critical applications should be pretty cautious.
On Sat, Feb 3, 2018 at 7:18 AM Samuel Thibault
wrote:
>
Or just http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/fs.defs#n59
.
On Thu, Mar 5, 2015 at 8:14 AM A. Fleckenstein afl...@inventati.org wrote:
On Thu, Mar 05, 2015 at 08:20:16PM +1300, Philip Charles wrote:
Where can I find this - I have tried.
Phil.
git clone
Where can you find what, exactly?
On Wed, Mar 4, 2015 at 11:21 PM Philip Charles phil...@copyleft.co.nz
wrote:
On Thu, 2015-03-05 at 04:22 +, Thomas Bushnell, BSG wrote:
It's not *quite* an excerpt.
On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein afl...@inventati.org
wrote
It's not *quite* an excerpt.
On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein afl...@inventati.org wrote:
In the hurd sources, hurd/hurd/fs.defs, line 59 begins a comment, the
contents of which are an excerpt from the prologue of Geoffrey Chaucer's
Canterbury Tales. Anyone know why this is?
A wired thread (vm_wire) has special vm rules inside the kernel. It's got
nothing to do with what you might expect (tying a cthread to a kernel
thread).
Thomas
On Mon, Apr 30, 2012 at 4:30 PM, Thomas Thomas ricinw...@yahoo.com wrote:
So, mach-defpager wires all of its threads. What exactly
2011/12/30 Jérémie Koenig j...@jk.fr.eu.org
On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault
samuel.thiba...@gnu.org wrote:
[...], but I believe it's still a bit revealing: I had already noticed
that ext2fs spends most of its time in the kernel (like 90%), and it
here seems we're spending
Programs which depend on the special suspend-the-parent behavior of vfork
were always regarded as buggy...
Thomas
On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge tho...@schwinge.namewrote:
Hallo!
On Thu, 24 Nov 2011 15:59:55 -, Planet GNU tschwinge+n...@gnu.org
wrote:
Many articles
I think the fear is of resource exhaustion, but there are so many of those
problems, this would not be the first place to look IMO.
Thomas
On Thu, Sep 22, 2011 at 4:29 PM, Roland McGrath rol...@hack.frob.comwrote:
The whole point of OOL data is that it is relatively cheap to transfer huge
I think this could also create extra churn, by scheduling a lot of disk
writes when a series of writes are done all at once to a single file.
Traditionally, this is addressed by the every-30-seconds update task; there
is no expectation of an indefinitely postponed write.
However, much could be
I agree with Samuel. The use of NULL for pointers in C can lead people to
forget that C does not protect the types in this case.
Thomas
On Sat, Aug 20, 2011 at 9:24 AM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
Jonathan Neuschäfer, le Mon 15 Aug 2011 22:10:06 +0200, a écrit :
*
It's what Linux does at least. And Posix likely requires it.
On Tue, Jul 26, 2011 at 4:52 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
Hello,
I've noticed that term/users.c calls set_atime/mtime for each and
every io_write/read performed on a tty. This means for instance that
each
Cheroot isn't supposed to change the namespace of Unix domain sockets in the
case where the chroot shares a file with the main system.
On Jun 2, 2011 6:56 PM, olafbuddenha...@gmx.net wrote:
Hi,
On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote:
You just need another partition,
Yes. Timers do create new threads to wait for the event in question, and
then they send the signal in the normal way.
On May 10, 2011 11:18 AM, Richard Braun rbr...@sceen.net wrote:
Now you're just talking in crazy fantasy land.
On Wed, Mar 23, 2011 at 3:39 AM, Michael Banck mba...@gmx.net wrote:
On Tue, Mar 22, 2011 at 05:06:40PM -0500, Oz wrote:
awsome sounds like i'll be playing some quake 3 mods in the near
future on the hurd.
I suggest you wait for Duke Nukem
On Sun, Mar 13, 2011 at 7:25 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
olafbuddenha...@gmx.net, le Mon 14 Mar 2011 03:21:43 +0100, a écrit :
There, the
rendez-vous port is thus the same as the reply port obtained above,
with the *same name*.
- reauth() destroys the
I think the second call to reauth should use a second, newly-created,
rendezvous port. Why doesn't it?
Thomas
On Mar 13, 2011 5:44 PM, Samuel Thibault samuel.thiba...@gnu.org wrote:
Hello,
I've investigated a duplicate port destroy in ext2fs, what apparently
happens is this:
-
This is not a bug. The headers are also not usable in pascal or fortran
programs.
Thomas
On Mar 6, 2011 2:00 PM, Samuel Thibault invalid.nore...@gnu.org wrote:
URL:
http://savannah.gnu.org/bugs/?32693
Summary: GNU/Hurd headers don't pass c++
Project: The GNU Hurd
Submitted by: sthibaul
Yes, it's allowed. All names beginning with st_* are reserved if you include
the relevant header files. rdfind has no business using such names.
Thomas
On Sun, Jan 9, 2011 at 4:11 PM, Pino Toscano toscano.p...@tiscali.itwrote:
Hi,
just looking at a recent build failure in Debian, rdfind.
The idea of migrating threads is that it happens automatically on a
synchronous rpc.
Thomas
On Sunday, December 26, 2010, Richard Braun rbr...@sceen.net wrote:
Hello.
From what I understand of the Hurd history, GNU Mach is based on Mach 4.
I read that this version was intended to include the
Agreed.
On Tue, Nov 2, 2010 at 7:52 AM, Michael Banck mba...@debian.org wrote:
On Tue, Nov 02, 2010 at 11:30:28AM +0100, Manuel Menal wrote:
On 02/11/2010 11:29, Samuel Thibault wrote:
Manuel Menal, le Tue 02 Nov 2010 11:20:27 +0100, a écrit :
“Macros that begin with E and a digit or E
On Sun, Oct 31, 2010 at 7:49 AM, Pino Toscano toscano.p...@tiscali.itwrote:
Although having a reserved, generic error code macro might be
useful(?), `ED' is a very generic identifier. For example, clang
uses it in many parts of its code, which makes the build fail on
GNU/Hurd. I think
Good catch. As Roland notes the old code here has the restart race
bug. Also it was probably a leak because I think nothing here wa
counting he new make send instance the way we normally wrap all uses
of make send.
On Sunday, September 19, 2010, Manuel Menal mme...@hurdfr.org wrote:
On
Right. this is why it's tricky. You don't want to force an interrupt every
microsecond just because sometimes people might be sleeping with that
granularity (because it would be too often). But the delay is long enough
that a busy-wait is also wrong. You need to dynamically change the clock
Special casing is what I had in mind, but it's very tricky. The normal
wakeup-queue method is simply not adequate.
On Thu, Aug 12, 2010 at 11:42 PM, olafbuddenha...@gmx.net wrote:
Hi,
On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote:
The current technique is to use
The current technique is to use a blocking mach_msg which will never
complete, and with a timeout. The reason that nanosleep and usleep don't
work is because 10ms is the granularity of the Mach clock. Changing the
interface here isn't the issue so much as changing the implementation.
Thomas
On
On Mon, 2009-07-06 at 21:01 +0800, Da Zheng wrote:
Samuel Thibault wrote:
Da Zheng, le Mon 06 Jul 2009 14:23:20 +0800, a écrit :
Thomas Schwinge wrote:
Zheng Da asked me to tell him about previous work that has been done on
supporting and using Berkeley Packet Filters. Here
On Fri, 2008-10-31 at 23:56 +0100, Adam Tkac wrote:
if (mode O_WRONLY)
die();
That was never correct code.
Thomas
On Thu, 2008-08-28 at 08:42 +0200, Neal H. Walfield wrote:
At Wed, 27 Aug 2008 15:05:59 -0700,
Thomas Bushnell BSG wrote:
On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
I know boot fails and gets EPERM when it calls store_parsed_open, but I
need to know what operations inside
On Thu, 2008-08-28 at 23:48 +0200, Da Zheng wrote:
If the non-user can access /dev/hda1, it means he can operate the hda1
device directly without the help of the file system.
Is the user really allowed to do it? In Linux or other Unix, this kind
of operation is forbidden, I think.
It
On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
I know boot fails and gets EPERM when it calls store_parsed_open, but I
need to know what operations inside store_parsed_open() fail. Otherwise,
I don't know how to fix it.
Boot assumes that it is run as root, and assumes that quite
On Thu, 2008-08-28 at 00:21 +0200, Da Zheng wrote:
Thomas Bushnell BSG wrote:
On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
I know boot fails and gets EPERM when it calls store_parsed_open, but I
need to know what operations inside store_parsed_open() fail. Otherwise,
I don't
On Tue, 2008-08-26 at 13:09 +0200, Da Zheng wrote:
The purpose of the translator is to help other programs get the port to
the device, so I suggested if it was OK that file_name_lookup() returns
the port to the device directly.
antrik said it was quite confusing for him because
On Wed, 2008-08-27 at 03:38 +0200, Da Zheng wrote:
Thomas Bushnell BSG wrote:
On Wed, 2008-08-27 at 01:56 +0200, Da Zheng wrote:
Yes, but the point here is that *you* are opening that file and
expecting something to happen. I thought you were writing the program
which would *serve
On Wed, 2008-08-27 at 03:48 +0200, Da Zheng wrote:
It sounds as if you got EPERM from store_parse_open, but
proc_getprivports is not being called, so you are having trouble
understanding why you got an error message at all.
Yes, exactly.
This will depend much on what the store
On Mon, 2008-08-25 at 13:20 +0200, Da Zheng wrote:
Yes, these ports have the receive rights.
They are used for the user program, and I want to make sure they have
all been destroyed before the translator exits, so the translator knows
all user programs connected to it have all exited and it
On Mon, 2008-08-25 at 19:31 +0200, Da Zheng wrote:
I don't want to destroy the port. I just want to check if all ports have
already been destroyed before the goaway routine is called.
To check, you use the counting routines provided.
The device file is created by a translator to help other
On Sun, 2008-08-24 at 19:36 +0200, Da Zheng wrote:
As I said above, I have to make sure all ports created for the user
program have been destroyed before the translator exits.
Are these ports that the translator has the receive rights to? If so,
then when the translator exits, they will all
On Sat, 2008-08-23 at 13:25 +0200, Da Zheng wrote:
I have to make sure every ports has been destroyed so when the
translator exits, it can check if there are still users.
Huh? When the translator exits, all the ports are going to be destroyed
anyway.
OK, maybe I should make the things more
On Sat, 2008-08-23 at 09:36 -0700, Thomas Bushnell BSG wrote:
So you have two ports. When the one going to the user is destroyed, you
need to tell the device not to send any more packets.
And we have a way to do that: by calling device_set_filter, and clearing
out the port
On Fri, 2008-08-22 at 01:49 +0200, [EMAIL PROTECTED] wrote:
Hi,
On Tue, Aug 19, 2008 at 11:29:28PM -0700, Thomas Bushnell BSG wrote:
On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
I'd agree on the principle to not leave a nul port for stdin/stdout,
any other opinion
On Fri, 2008-08-22 at 02:54 +0200, zhengda wrote:
When a port_info object is created by ports_create_port() and
ports_get_right() hasn't been called,
we have to call ports_port_deref() to destroy the port_info object.
You are still organizing things wrongly, and that's what's messing you
up.
On Thu, 2008-08-21 at 11:26 +0200, zhengda wrote:
In eth-filter, I define a structure
struct proxy_info
{
/* For receiving packets from pfinet. */
struct port_info *pfinet_pi;
hurd_ihash_locp_t p_pfinetpi_hashloc;
/* For receiving packets from the network interface. */
struct
On Fri, 2008-06-06 at 00:12 +0100, Samuel Thibault wrotekfs/dir-lookup.c:478
dir-lookup.c:478 is as follows:
469 if (! error)
470 {
471 if (flags O_EXLOCK)
472 error = fshelp_acquire_lock (np-userlock, newpi-po-lock_status,
473np-lock,
On Mon, 2008-06-09 at 21:52 +, Samuel Thibault wrote:
CVSROOT: /cvsroot/hurd
Module name: hurd
Changes by: Samuel Thibault sthibaul 08/06/09 21:52:12
Modified files:
libdiskfs : ChangeLog dir-lookup.c
Log message:
2008-06-06 Samuel Thibault [EMAIL
On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
Hello,
I'd agree on the principle to not leave a nul port for stdin/stdout,
any other opinion on this?
I disagree. Translators don't have such ports, and making them null
encourages programs to write on them, possibly expecting that
On Tue, 2008-06-10 at 12:59 +0400, A.Salatov wrote:
No, you correct me if I'm wrong, but when I think about 'settrans' my
mind always going to compare it to 'umount' and I started to think about
a reasons why 'umount' is 'umount' and not 'unmount'. The simplest
reason for it, that I could
On Tue, 2008-06-17 at 00:18 +0100, Samuel Thibault wrote:
Hello,
Madhusudan C.S, le Tue 17 Jun 2008 04:12:42 +0530, a écrit :
1. Is it better to free all those nodes as soon as they are displayed and
create them whenever they are required?
Just do that. No need to cache anything. Just
On Wed, 2008-08-20 at 22:47 +0200, zhengda wrote:
I want to get the confirmation from you about the usage of
ports_get_right(), ports_destroy_right() and ports_port_deref().
When I use ports_get_right() to get the receive right of the port, I
should always make a send right for the port. So
Perhaps someone can help out John?
Thomas
---BeginMessage---
Hi, Thomas.
I was looking for information on the current status of GNU Hurd,
to see if I can find someone to give a talk about it at our
Linux and Unix user group. You gave a talk on Hurd at our group
back in 1996, but I see you're
On Wed, 2008-03-19 at 21:48 +0100, [EMAIL PROTECTED] wrote:
Now the basic idea behind using one kernel thread to handle several
user threads is that when a user thread *would* block, you don't let
it block, instead you just take it away and run some other user
thread. That works very
On Tue, 2008-03-18 at 10:26 +0100, [EMAIL PROTECTED] wrote:
You need kernel memory for the memory maps, at least one for each user
thread.
No I don't. That's precisely where it is *not* equivalent.
In the model I described, the state structures for the blocked requests
(I prefer not to
On Tue, 2008-03-18 at 10:14 +0100, [EMAIL PROTECTED] wrote:
Hi,
On Mon, Mar 17, 2008 at 07:00:02PM -0400, Thomas Bushnell BSG wrote:
On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote:
We could move the servers one by one -- starting with the disk
filesystems
On Wed, 2008-03-19 at 17:56 +0100, Neal H. Walfield wrote:
At Wed, 19 Mar 2008 09:58:57 -0400,
Thomas Bushnell BSG wrote:
And throwing a big wrinkle into all that is that many architectures do
not make it *possible* for users to handle page faults. The processor
dumps a load of crap
On Sun, 2008-03-16 at 08:52 +0100, [EMAIL PROTECTED] wrote:
Hi,
On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
[EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
[I] suggested a more adaptive approach: Keep track of the existing
threads, and if none of
On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote:
Hi,
On Wed, Mar 12, 2008 at 03:56:47PM -0400, Thomas Bushnell BSG wrote:
The clever way is to identify the particular things in the stack which
must be saved, and throw the rest away, and then restart the
continuation
On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote:
What you are suggesting is essentially using a user-level thread
package. (Compacting a thread's state in the form of a closure is a
nice optimization, but the model essentially remains the same.) The
main advantage to user-level
On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote:
This thread is syncing everything, i.e. asking a lot of writes, which
triggers the creation of a lot of threads. Unfortunately the superblock
was paged out, so they all block on reading it. Unfortunately, since in
Debian there is a
Currently the plan (approved by RMS) is to keep the Hurd libraries at
GPLv2 or any later version so that they can be linked with
Linux-derived code such as ext2fs stuff, and more importantly,
networking stuff. The Hurd programs themselves (rather than just the
libraries) will be GPLv3, though the
On Mon, 2007-07-23 at 02:05 +0200, Thomas Schwinge wrote:
Getting non-invasive (read: bug-fixing and the like) changes into the
Hurd's code base is not an issue, as I can do (and actually do) all that.
For getting invasive (read: interface changes and the like) changes into
the Hurd we'd
On Wed, 2007-06-20 at 16:20 +0200, Neal H. Walfield wrote:
What is a pseudo-chroot?
I think what you are proposing is essentially filtering the global
name space via some fancy translator.
Yes, just that.
When we are just interested in
overriding a small parts of the environment and the
On Wed, 2007-06-20 at 11:11 +0800, Wei Shen wrote:
Hi,
On 6/20/07, Neal H. Walfield [EMAIL PROTECTED] wrote:
(1) Add a set of new environment variables, e.g.
PFINETSERVER for the pf_inet server and PFLOCALSERVER for the
pf_local server.
We
Ok, thanks Thomas.
First you list the files with the UU copyright, including advertising
clause. Roland is going to ask Utah about those.
Then you list some with BSG copyright, including advertising clause. We
already have permission from Berkeley to remove the clause from such
files. Can
On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:
The problem stems from the fact that the GPL is a project-wide
license, it's not per-file (the CDDL and MPL are per file; they aren't
viral licenses). Simply having it in one file binds the entire project
to that license which
On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:
* Permission to use, copy, modify and distribute this software and
its
* documentation is hereby granted, provided that both the copyright
* notice and this permission notice appear in all copies of the
* software, derivative
On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:
I had emailed Thomas in regards to this because I didn't want to start
a general panic over the license. Anyway, we have a few problems in
any regard (I'm a Savannah Administrator, and if we have to remove the
GPL later clause, then
On Sat, 2007-06-16 at 18:49 -0400, Michael Casadevall wrote:
I did cite one such case already, from cons.c (it appears in quite a
few other files as well), and Thomas cited one as well.
(3) all advertising
* materials mentioning features or use of this software display the
following
*
On Fri, 2007-05-11 at 23:45 +0200, Thomas Schwinge wrote:
Hello!
On Thu, May 10, 2007 at 07:32:31PM -0700, Thomas Bushnell BSG wrote:
Um, well, you could keep track of the relationship, and establish the
rule that a user of i386_io_perm_create sent to this special server must
keep
On Fri, 2007-05-11 at 00:06 +0200, Thomas Schwinge wrote:
Now, if Roland suggests to separate the i/o port and memory access
interfaces then we could (for example) simply have the suggested
`/servers/ioperm' and a `/servers/mem' (or `/dev/mem'? -- but our thing
is more advances than the usual
On Fri, 2007-05-11 at 00:50 +0200, Thomas Schwinge wrote:
[Remove hurd-devel.]
Hello!
In the server T (`/servers/ioperm') I essentially have...
#v+
kern_return_t
S_i386_io_perm_create (mach_port_t port, io_port_t from, io_port_t to,
mach_port_t *io_perm)
{
On Wed, 2007-05-09 at 17:53 +0200, Thomas Schwinge wrote:
Now, how about the following: we have a server sitting on
`/servers/machine' (or somewhere else) that accepts rpcs like
`io_perm_create' or `memory_map_create' and ``forwards'' (it need not
really be forwarding) them to the kernel after
On Wed, 2007-04-11 at 12:57 +0200, Thomas Schwinge wrote:
Hello!
On Tue, Apr 10, 2007 at 10:10:01PM -0700, Thomas Bushnell BSG wrote:
On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
We're still being again and again annoyed by programs that use `PATH_MAX'
unconditionally
On Tue, 2007-04-10 at 11:46 +0200, Neal H. Walfield wrote:
At Mon, 9 Apr 2007 20:02:32 -0700 (PDT),
Roland McGrath [EMAIL PROTECTED] wrote:
It is supposed to crash. Hopefully it does not hold locks while doing so,
and we should make sure that it doesn't. But anything that returns
On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
Hello!
We're still being again and again annoyed by programs that use `PATH_MAX'
unconditionally.
Why stop with this one? Let's just drop all the Hurd features and
implement the same interface as Linux, as exactly as we can make it.
On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
On Mon, Feb 19, 2007 at 03:38:04PM -0800, Thomas Bushnell BSG wrote:
The node doesn't belong to the user; the filesystem does not know or
care what access permissions are there in the upper-level filesystem.
It is in *that* filesystem
On Tue, 2007-02-20 at 12:10 +0100, Richard Braun wrote:
On Mon, Feb 19, 2007 at 05:21:29PM -0800, Thomas Bushnell BSG wrote:
On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
I understand the point. But calling file_getcontrol() on the upper-level
node won't allow us to update
On Mon, 2007-02-19 at 23:13 +0100, Richard Braun wrote:
On Mon, Feb 19, 2007 at 04:58:24PM -0500, Ben Asselstine wrote:
Hello,
I ran across this behaviour recently. It works if I do the same as
the root user. Is anyone else having this problem?
v+
[EMAIL PROTECTED]:/tmp/bing$
On Tue, 2007-02-20 at 00:23 +0100, Richard Braun wrote:
What makes you think that's a bug?
I don't know if it's a bug actually, I mentionned I wanted to study the
problem. Still, it seems weird that fsysopts isn't able to get the control
of a node which belongs to the user. Any reason for
On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
I understand the point. But calling file_getcontrol() on the upper-level
node won't allow us to update the options of the trivfs translator AIUI.
Isn't there a way to do that without being root ?
Yes it will; it will give you the fsys
On Sat, 2007-02-17 at 11:06 +0100, Thomas Schwinge wrote:
Looking at the source code, I see that it is used inside `pfinet' for
timing issues and a few times in the file system servers.
These few times are crucial; every single time a file access is
performed, a timestamp needs to be marked in
On Mon, 2007-02-05 at 21:45 +0100, Thomas Schwinge wrote:
Hello!
Mach files have copyright headers like this:
#v+
/*
* Mach Operating System
* Copyright (c) 1993-1987 Carnegie Mellon University.
* Copyright (c) 1993,1994 The University of Utah and
* the Computer Systems Laboratory
On Wed, 2007-01-31 at 19:13 +0200, Constantine Kousoulos wrote:
typo corrections... @!#$*!!
Thomas Bushnell BSG wrote:
I cannot see any reason why, once the system is up and running, even
proc cannot simply syslog just like anything else, provided it does not
hold internal locks
I see no reason why we should care about emulating klog.
Hurd translators can, in general, perfectly well simply write directly
to the regular /dev/log socket in the regular way. Heck, even the
filesystem and pflocal translators can do so, since they are properly
multi-threaded.
The only issue
On Mon, 2007-01-01 at 11:49 +0100, Samuel Thibault wrote:
Hi,
dev = (device_t) ns-not_header.msgh_remote_port;
How can this work? (I currently have a kernel fault here)
A device_t and a mach_port_t are exactly the same data type, both are
just integers, unless I am confused.
On Mon, 2007-01-01 at 20:08 +0100, Samuel Thibault wrote:
Richard Braun, le Mon 01 Jan 2007 17:47:32 +0100, a écrit :
On Mon, Jan 01, 2007 at 11:49:54AM +0100, Samuel Thibault wrote:
Ok, and how these two views may coexist? As I showed, they _are_ mixed
in the case of the linux block
On Mon, 2007-01-01 at 22:48 +0100, Samuel Thibault wrote:
Thomas Bushnell BSG, le Mon 01 Jan 2007 12:18:17 -0800, a écrit :
bd-port = ipc_port_alloc_kernel ();
ipc_port_nsrequest (bd-port, 1, notify, notify);
dev = (device_t) ns-not_header.msgh_remote_port
On Mon, 2007-01-01 at 23:05 +0100, Samuel Thibault wrote:
Ok, that I can understand, but the code snippet I showed doesn't pass
through MiG, it's just a function call:
kern/ipc_kobject.c:ipc_kobject_notify():
ipc_port_t port = (ipc_port_t) request_header-msgh_remote_port;
...
On Fri, 2006-12-01 at 15:03 -0300, Leonardo Pereira wrote:
I think he isn't, Mach Exceptions are just another aproach of signals,
they were used on Mach_US and Lites to implement Unix-compatible
signals. The unique 'problem' is that Mach Exceptions handle not only
process but also threads, so,
On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote:
All the above solutions aim to make Mach unaware of any memory
above 1 GB. Isn't it possible to utilise all the memory? I will
explain myself.
I think this is clearly right, but it may well require more substantial
changes to
On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote:
Hi folks, it's your favorite PITA again.. :-)
Index: i386/i386/trap.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v
retrieving revision 1.5.2.6
diff -u -p
On Wed, 2006-11-15 at 15:55 -0500, Barry deFreese wrote:
Thomas,
Thanks for the reply. Are you saying I should wrap those includes
around an #ifdef MACH_KDB up where the other includes are? If so, that
makes sense to me.
I did not check whether the MACH_KDB check is right. But on
On Mon, 2006-11-13 at 22:53 +0100, Samuel Thibault wrote:
Roland McGrath, le Mon 13 Nov 2006 13:43:10 -0800, a écrit :
Roland McGrath, le Sun 12 Nov 2006 16:50:48 -0800, a écrit :
Decls for copyin et al do not belong in a machine header.
Then why simple_lock_pause, spl*, for
On Fri, 2006-11-10 at 16:07 +0100, Samuel Thibault wrote:
Hi,
Barry deFreese, le Fri 10 Nov 2006 09:58:20 -0500, a écrit :
From my extremely limited knowledge of assembler, copyin and
copyinmsg look to be exactly the same.
They are not the same
On Fri, 2006-11-10 at 13:39 -0500, Barry deFreese wrote:
Hi again folks,
OK, I am confused by something else. (I know big surprise :-) ).
i386/i386/spl.h
#include ipl.h
i386/i386/ipl.h
#ifdef __ASSEMBLER__
#include i386/machspl.h
...
i386/i386/machspl.h
/* XXX
i386/i386/spl.h
#include ipl.h
i386/i386/ipl.h
#ifdef __ASSEMBLER__
#include i386/machspl.h
...
You had me all confused looking at your email. What I see in
i386/ipl.h is this:
#ifndef ASSEMBLER
#include machine/machspl.h
First question is, is this an issue? machspl.h
I think Roland's email was a little over-hasty, to be sure. Let's just
not fret about one message that was over-hasty and import too much to
it, ok?
As for the technical issue, Roland is mostly but not entirely right
about what gnumach/include is for.
It has both the interface files, and
As for the technical issue, Roland is mostly but not entirely right
about what gnumach/include is for.
It has both the interface files, and pseudo-clones of C library headers,
which don't get installed because the C library has better versions. In
that category are sys/types.h,
Why the change to add parentheses to printf.c:_doprnt? (If this is to
shut up a gcc warning, then it seems ok, I guess.)
We do not normally put comments on #include's saying why the file was
included for a couple reasons: it very quickly gets out of date, and it
doesn't really communicate
On Wed, 2006-11-08 at 22:40 +0100, Thomas Schwinge wrote:
[Please keep both bug-hurd@gnu.org and grub-devel@gnu.org in the
recipients list.]
Is it feasible to have the `-fstack-protector' functionality in GNU Mach
and GRUB2 (and how to do that, then) or shall we unconditionally pass
On Tue, 2006-11-07 at 10:26 +0100, Samuel Thibault wrote:
Hi,
Claudio Fontana, le Mon 06 Nov 2006 19:14:04 -0800, a écrit :
is this to be the regular header that application developers include
under your system to see all standard string functions declared?
Nope, that's only for kernel
On Tue, 2006-11-07 at 12:18 -0500, Barry deFreese wrote:
Here is a patch for another round of cleanup. This gets rid of warnings for
strcmp, strlen, and printf.
I don't think we should have a file called stdio.h unless it's going
to support all of stdio. printf.h is a much better name for a
1 - 100 of 528 matches
Mail list logo