I checked in some ds_mem.c changes that should robustify vs overflow.
Please try it out.
As to that special_mem_device call, I'm not sure exactly what I was
thinking. The comment makes sense, but the code doesn't match. It looks
like libstore uses size_t in place of dev_status_t, and so it will
Well, for one thing I've disabled the panic in place of returning
D_INVALID_RECNUM. That was just there for some debugging I was doing once
a long time ago.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Mon, Dec 10, 2001 at 03:38:17PM -0500, Roland McGrath wrote:
> > Here the mode is hard coded to read only.
>
> I checked in a fix for that. Please try a variety of operations on "mem"
> and verify that none of them crash or anything. Obviously the writing code
> has never been tested.
Yep,
> Ugh, except that I can't map a part of the mem device, because of libstore
> breakage:
Actually, it's right about the kernel being broken. The only thing that
actually works in gnumach or in oskit-mach is to device_map with an offset
of zero to get a memory object covering the entire address s
On Mon, Dec 10, 2001 at 03:38:17PM -0500, Roland McGrath wrote:
> > Here the mode is hard coded to read only.
>
> I checked in a fix for that. Please try a variety of operations on "mem"
> and verify that none of them crash or anything. Obviously the writing code
> has never been tested.
Yeah,
> Here the mode is hard coded to read only.
I checked in a fix for that. Please try a variety of operations on "mem"
and verify that none of them crash or anything. Obviously the writing code
has never been tested.
> I can not device_map with VM_PROT_WRITE, as the open mode is verified
> (D_WR
On Mon, Dec 10, 2001 at 08:20:15PM +0100, Marcus Brinkmann wrote:
> On Mon, Oct 01, 2001 at 05:12:17PM -0400, Roland McGrath wrote:
> > The keyboard and video questions are really quite separate,
> > so I am answering them in two separate threads.
> >
> > I believe that everything should already
On Mon, Oct 01, 2001 at 05:12:17PM -0400, Roland McGrath wrote:
> The keyboard and video questions are really quite separate,
> so I am answering them in two separate threads.
>
> I believe that everything should already be in place in Mach (both flavors)
> and in the Hurd for mapping physical de
On Sun, Oct 07, 2001 at 07:59:42PM +0200, Marcus Brinkmann wrote:
> On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> > First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> > is not really hard, and having extra flavors for machine-specific features
> > is fi
On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> is not really hard, and having extra flavors for machine-specific features
> is fine by me. But I was also thinking it might just be easiest to stick
> wit
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> MiG doesn't know unsigned short, so I am afraid that I have to use int.
> The conversion from signed shorts to unsigned shorts is implementation
> defined (or can raise a signal even), so I am out of luck here (unless we
> forbid ports higher than 7
> the first system uses two's complement and the other uses one's complement).
Send me mail from your one's complement system and we'll worry about it then.
> It's not even clear that the first conversion from unsigned short to signed
> short is valid on every platform. ISO C says that unsigned
On Wed, Oct 03, 2001 at 04:54:37PM -0400, Roland McGrath wrote:
> > On Wed, Oct 03, 2001 at 04:09:37PM -0400, Roland McGrath wrote:
> > > > The conversion from signed shorts to unsigned shorts is implementation
> > > > defined (or can raise a signal even), so I am out of luck here (unless we
> >
> On Wed, Oct 03, 2001 at 04:09:37PM -0400, Roland McGrath wrote:
> > > The conversion from signed shorts to unsigned shorts is implementation
> > > defined (or can raise a signal even), so I am out of luck here (unless we
> > > forbid ports higher than 7fff).
> >
> > Say what? Conversions from
You are thinking at least as clearly as I am about this, so certainly don't
apologize for doing it out loud!
On further thought I was unsure about some of the same details of my vague
plan that you brought up.
First, as to the kernel implementation issue. Adding a new IKOT_* flavor
is not rea
On Wed, Oct 03, 2001 at 04:20:25PM -0400, Roland McGrath wrote:
> I think a (partial) bitmask is the simpler interface. I'd think the most
> common case is setting up access for just one device, i.e. a small
> contiguous range of io ports, so supplying a starting port number and a
> word or less
On Wed, Oct 03, 2001 at 04:09:37PM -0400, Roland McGrath wrote:
> > The conversion from signed shorts to unsigned shorts is implementation
> > defined (or can raise a signal even), so I am out of luck here (unless we
> > forbid ports higher than 7fff).
>
> Say what? Conversions from one bitpatt
> So there are still some details to work out. Like, should ports be reused
> if they specify the same set if permission? I think that would be a good
> idea, but it is costly to make the comparison, and is probably overkill.
Definitely overkill.
___
I think a (partial) bitmask is the simpler interface. I'd think the most
common case is setting up access for just one device, i.e. a small
contiguous range of io ports, so supplying a starting port number and a
word or less of all-ones is very easy for the client side. And bottom
line, that's t
> MiG doesn't know unsigned short, so I am afraid that I have to use int.
MiG is indeed pretty unhelpful, though there is a MACH_MSG_TYPE_INTEGER_16
code.
> The conversion from signed shorts to unsigned shorts is implementation
> defined (or can raise a signal even), so I am out of luck here (u
On Tue, Oct 02, 2001 at 03:54:46PM -0400, Roland McGrath wrote:
> > 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
On Tue, Oct 02, 2001 at 10:54:40PM +0200, Marcus Brinkmann wrote:
> type io_reg_t = unsigned short;
> type io_reg_array_t = array[] of io_reg_t;
MiG doesn't know unsigned short, so I am afraid that I have to use int.
The conversion from signed shorts to unsigned shorts is implementation
defined (
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, 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,
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
On Mon, Oct 01, 2001 at 05:12:17PM -0400, Roland McGrath wrote:
> I believe that everything should already be in place in Mach (both flavors)
> and in the Hurd for mapping physical device memory such as the frame buffer.
> mmap on /dev/mem ought to dtrt already. If not, it's a bug.
>
> The only
The keyboard and video questions are really quite separate,
so I am answering them in two separate threads.
I believe that everything should already be in place in Mach (both flavors)
and in the Hurd for mapping physical device memory such as the frame buffer.
mmap on /dev/mem ought to dtrt alrea
31 matches
Mail list logo
