Hi,
Adding more memory to kernel mapping is indeed a good idea (stomach
has a rough hack that does the same almost).
Just another bothering question:
On 1/9/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> - kernel_virtual_end = phys_last_addr + morevm;
> + kernel_virtual_end = phys_
Here is the patch inline. The "15" factor is somewhat arbiratry...
[gnumach]/Changelog
2006-01-09 Samuel Thibault <[EMAIL PROTECTED]>
* i386/i386at/model_dep.c(mem_size_init): Limit memory to what gnumach
is able to use (minus a little extra for virtual mappings).
Follow-up Comment #3, bug #7118 (project hurd):
Hi,
There were two problems, which the attached patch addresses.
- The area for kernel mappings was limited to an arbitrary limit of 40MB.
This is enough for managing up to ~700MB, but not more (because of some
memory management structures), so I
Gianluca Guida, le Sun 08 Jan 2006 19:39:14 +0100, a écrit :
> I guess you should put a proper copyright comment. Included the real
> GPL comment.
Like this?
gnumach/ChangeLog
2006-01-08 Samuel Thibault <[EMAIL PROTECTED]>
* Makefile.in: Always compile-in new io.c file.
* devic
Hey,
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> Agreed. Here is an updated patch
That's quite cool. Thanks.
Just another thing:
Index: device/io.c
===
RCS file: device/io.c
diff -N device/io.c
--- /dev/null 1 Jan 19
Gianluca Guida, le Sun 08 Jan 2006 19:18:52 +0100, a écrit :
> On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> > The problem is that when opening a device (device_open), the port that
> > is returned to the user is &device->dev: see
> > device/ds_routines.c:device_open():
>
> Ok. The patch
Gianluca Guida, le Sun 08 Jan 2006 18:56:21 +0100, a écrit :
> My only 0.02 euro here is that since io_port_create and
> io_port_destroy are both exported function, it would be nice to have
> the device code (ioopen and ioclose) in a separate, architecture
> independent file, since it is an archite
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> The problem is that when opening a device (device_open), the port that
> is returned to the user is &device->dev: see
> device/ds_routines.c:device_open():
Ok. The patch is functionally OK. Only thing I ask is that you add
some comment at eac
Gianluca Guida, le Sun 08 Jan 2006 18:40:45 +0100, a écrit :
> On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> > I was not sure about this indeed. The caller here is actually all
> > drivers that call io_port_create()...
>
> What drivers and where?
./i386/i386at/kd.c: io_port_create(
Looks ok to me.
My only 0.02 euro here is that since io_port_create and
io_port_destroy are both exported function, it would be nice to have
the device code (ioopen and ioclose) in a separate, architecture
independent file, since it is an architecture independent device.
G.
--
It was a type of p
Just for reminding what's on the bts:
Trying to apply [ patches
http://savannah.gnu.org/patch/download.php?item_id=4737&item_file_id=5662 (user
tss fixup) ,
http://savannah.gnu.org/bugs/download.php?item_id=15295&item_file_id=3237 (no
io perms by default), and
http://savannah.gnu.org/bugs/dow
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> I was not sure about this indeed. The caller here is actually all
> drivers that call io_port_create()...
What drivers and where?
Can you be more precise about it? The more I look at the patch the
less I understand what it is for.
Thanks,
Gianluca Guida, le Sun 08 Jan 2006 18:21:09 +0100, a écrit :
> I am not actually happy with this patch, since it will break for
> example stomach, and since I guess it's trying to fix an error on the
> callers (that should give the proper parameter) by modifying the
> called function.
I was not su
Alfred M. Szmidt, le Sun 08 Jan 2006 18:14:15 +0100, a écrit :
> Several things with this patch, generic-speaker.c is from what I know
> non-arch dependant, so adding IA-32 seem to be wrong without taking
> into account what system one is compiling things on. Also, much code
> in the Hurd doesn't
Alfred M. Szmidt, le Sun 08 Jan 2006 18:06:37 +0100, a écrit :
> Once again, explanation behind the patch. We are a bit lazy, so such
> things help alot. :-)
Well, from the changelogs I read, long explanations weren't given. For
this patch, the BTS has explanations:
http://savannah.gnu.org/bugs/?
On 1/8/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> Alfred M. Szmidt, le Sun 08 Jan 2006 17:57:27 +0100, a écrit :
> > Looks ok. Why the ifdef i386 though?
Because this patch assumes the i386 device emulation that Mach's i386
subsection uses. That is actually architecture independent, and for
Hi,
Alfred M. Szmidt, le Sun 08 Jan 2006 18:03:17 +0100, a écrit :
> Could you gives some explanation about this patch? I haven't looked
> at it yet, and I don't recall any discussion about it.
I explained in the bts[1] why we need i/o permissions per task. And for
implementing this, threads of
Several things with this patch, generic-speaker.c is from what I know
non-arch dependant, so adding IA-32 seem to be wrong without taking
into account what system one is compiling things on. Also, much code
in the Hurd doesn't care what system one is running on, so adding
IA-32 specific code shoul
Alfred M. Szmidt, le Sun 08 Jan 2006 17:57:27 +0100, a écrit :
> Looks ok. Why the ifdef i386 though?
Cf all ifdef i386 along device/ds_routines.c for instance. I don't know
the deep reason for all these defines, it's another issue anyway.
Regards,
Samuel
_
Has my blessing, I fixed the ChangeLog (we don't mention why a include
is included).
gnumach/ChangeLog:
2005-12-26 Samuel Thibault <[EMAIL PROTECTED]>
* iopb.c: Include "vm_param.h".
(io_tss_init): Fix address and limit of user TSS.
diff -urp gnumach-20050801/build-dbg/machine/
Looks ok. Why the ifdef i386 though?
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* iopb.c (i386_io_port_add): Get the device parameter properly.
(i386_io_port_remove): Likewise.
diff -urp gnumach-mine-2-default_noio/i386/i386/iopb.c
gnumach-mine-3-device_port_fix/i386/i386
This should be merged with `gnumach, new device' from the looks. No
need to make lots of small patches that all depend on each other.
Explanation as always is needed (if there was one already, smack us
over the head with it).
2006-01-07 Samuel Thibault <[EMAIL PROTECTED]>
* conf.c: New
Once again, explanation behind the patch. We are a bit lazy, so such
things help alot. :-)
2006-01-07 Samuel Thibault <[EMAIL PROTECTED]>
* iopb.c: Include for io_req_t. New "io" device.
(ioopen): New function.
(ioclose): Likewise.
(io_bitmap_set): Treat speci
Could you gives some explanation about this patch? I haven't looked
at it yet, and I don't recall any discussion about it. I only touched
the ChangeLog in a couple of places, since I'm more interested in a
discussion behind why this patch is needed, etc.
2006-01-02 Samuel Thibault <[EMAIL PROTE
Looks good, fixed ChangeLog (you forgot to mention i386_io_port_add).
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* iopb.c (iopb_create, i386_io_port_add): Set default IO
permissions to none.
* ktss.c (ktss_init): Likewise.
diff -urp gnumach-mine-1-user_tss/i386/i386
Has my blessing, though, I think that this patch should be merged with
`gnumach, timer controller'; it touches the same stuff, etc, so having
seperate patches for them doesn't make much sense.
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* kd.c (vga_port_list): Rename to...
(k
Same here, explanation behind the changes, why etc.
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* task.c (task_init): Call new machine_task_module_init() function.
(task_create): Call new machine_task_init() function.
(task_deallocate): Call new machine_task_terminate
Has my blessing.
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* iopl.c (iopl_port_list): Added timer controller port.
diff -urp gnumach-mine-3-device_port_fix/i386/i386at/iopl.c
gnumach-mine-4-more_ports/i386/i386at/iopl.c
--- gnumach-mine-3-device_port_fix/i386/i386at/iopl.c 2006
This I assume is related to the `gnumach, task based IO ports'.
Explanation behind the changes, why etc are needed. I haven't looked
at the patch yet.
2006-01-02 Samuel Thibault <[EMAIL PROTECTED]>
* iopl.c (iopl_emulate): TSS is now task-based. Fix TSS and
locking accordingly
Hi,
Here is the patchset inline, for review:
2005-12-26 Samuel Thibault <[EMAIL PROTECTED]>
* iopb.c: Include "vm_param.h" for kvtolin().
(io_tss_init): Fix address and limit of user TSS.
diff -urp gnumach-20050801/build-dbg/machine/iopb.c
gnumach-mine/build-dbg/machine/iopb.c
30 matches
Mail list logo
