Thanks.
Is the following patch acceptable for checkin?
2001-10-02 Gordon Matzigkeit
* Makefile.in (clean): Don't remove acconfig.h and cpus.h.
From Daniel Wagner <[EMAIL PROTECTED]>.
diff -u -r1.22.2.12 Makefile.in
--- Makefile.in 2001/08/17 09:03:30 1.22.2.12
+++ Makefi
On Tue, Oct 02, 2001 at 10:54:40PM +0200, Marcus Brinkmann wrote:
> type mach_port_t = io_port_t;
Ugh, more something like
type io_port_t = mach_port_t
ctype: mach_port_t
#if KERNEL_SERVER
intran: io_port_t convert_port_to_io_port(mach_port_t)
On Tue, 02 Oct 2001, Gordon Matzigkeit wrote:
> cpus.h appears to be the only file that's being missed.
If you do 'make clean' it will be deletet because the
clean rule deletes all header files in the build directory.
I changed Makefile.in this way:
nr_headerfiles = config.h cpus.h
headerfil
Hi,
While compiling, I'm getting a lot of errors like:
kern/lock.h:37: cpus.h: No such file or directory
cpus.h appears to be the only file that's being missed.
Am I using the right oskit, is there something else I need to install,
or is this a bug to be resolved elsewhere?
The only relevant
On Tue, Oct 02, 2001 at 03:38:39AM -0400, Roland McGrath wrote:
> Perhaps we should have a capability-based interface, but just use special
> ports for this instead of device_t's. e.g., there could be a new call on
> the device master port to give you a capability port with the given bitmask
> of
On Tue, Oct 02, 2001 at 03:54:46PM -0400, Roland McGrath wrote:
> But that's already implemented! The existing iopb code works exactly this
> way. All we have to change is its use of device_t to use a generic
> ipc_port pointer instead.
Fair enough. And you already said that it can get a port
> I have thought about it a little, and although it certainly makes sense, it
> seems to be more complicated than necessary to me. After all, you then want
> the kernel to keep track of such ports, and free the associated info when it
> is destroyed etc.
But that's already implemented! The exis
On Tue, Oct 02, 2001 at 03:38:39AM -0400, Roland McGrath wrote:
> You got me. Try it. I think it should allow no io access, but that's what
> I would have thought about gnumach too.
No I/O access is the default as documented in the OSKit Manual.
> We need a new interface for enabling io ports,
On Tue, Oct 02, 2001 at 09:43:37AM -0500, Kevin Kreamer wrote:
> For anyone trying to build colortext, you have to grab pio.h from the
> gnumach/oskit-mach sources. screen.c tries to include it as
> , but the mach's (or machen or whatever) no longer
> install that header.
Yeah, my patch was v
On Tue, Oct 02, 2001 at 09:32:19AM -0500, Kevin Kreamer wrote:
> I noticed while building the Hurd, the $(MAKE) invoked in libstore/
> replaces /include/hurd/store.h. Is this a new bug, known problem,
> quick hack, misunderstood feature, or user error (quite possible)?
I've found this too, in
On Wed, Sep 26, 2001 at 03:04:22PM -0400, Robert J. Chassell said:
> The new version formats fine for @smallbook, except for the included
> `oskit.patch', one line of which is overly long, but not by much.
I've formatted it for @smallbook.
> For this kind of problem, I would simply insert an @
For anyone trying to build colortext, you have to grab pio.h from the
gnumach/oskit-mach sources. screen.c tries to include it as
, but the mach's (or machen or whatever) no longer
install that header.
Kevin
--
Kevin Kreamer
FsckIt on openprojects.net
___
I noticed while building the Hurd, the $(MAKE) invoked in libstore/
replaces /include/hurd/store.h. Is this a new bug, known problem,
quick hack, misunderstood feature, or user error (quite possible)?
Thanks,
Kevin
--
Kevin Kreamer
FsckIt on openprojects.net
_
Roland McGrath <[EMAIL PROTECTED]> writes:
> One annoyance that's not really a problem in practice is the inheritance
> (or lack thereof). The Linux `ioperm' model applies to all threads in the
> process (I think) and is preserved across exec (so the documentation says).
> Conversely i386_io_por
You got me. Try it. I think it should allow no io access, but that's what
I would have thought about gnumach too.
We need a new interface for enabling io ports, because the old CMU style
that gnumach has is just bogus. It's easy enough to implement a some more
sane RPCs into the kernel, and th
15 matches
Mail list logo
