2011/9/13 Thomas Bushnell, BSG :
> 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.
This is mitigated due to competition for the pager's lock between
data_requests and data_returns.
> Traditionally, thi
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 im
Hi,
Currently, libdiskfs:io_write.c only calls "diskfs_file_update(struct
node *np, int wait)" if the node has been opened with O_FSYNC or if
the entire translator is operating synchronously (diskfs_synchronous
== 1). I think calling diskfs_file_update (with wait == 0) when
working asynchronously
Hi,
Does somebody know the reasoning behind the function "poke_pages" in
ext2fs:truncate.c? I suppose it's there to work around some kind of
memory object paging error in GNU Mach, but I'm not sure about it's
real purpose, or if it's still needed nowadays.
Hi,
i had to learn that a kvm emulated CD-ROM appears as /dev/hd2.
I suspect this means it is not controlled by an SCSI driver but by
gnumach/linux/src/drivers/block/ide.c
gnumach/linux/src/drivers/block/ide-cd.c
Is this correct ?
If so then i will try to use ATAPI commands. E.g via
int
Thomas Schmitt, le Tue 13 Sep 2011 13:01:45 +0200, a écrit :
> Please ignore this sentence in my previous mail:
>
> > Where was this assigned to mach_port_array_t resp. to init_port_set ?
>
> It is a residue from obsoleted reasoning. I first found "^ array[]"
> in gnumach/include/mach/mach.defs b
Hi,
Please ignore this sentence in my previous mail:
> Where was this assigned to mach_port_array_t resp. to init_port_set ?
It is a residue from obsoleted reasoning. I first found "^ array[]"
in gnumach/include/mach/mach.defs but later noticed that
device_set_status() itself has a variable leng
Hi,
current state of MIG definition (stop me when i go astray):
routine device_transact_native(
device : device_t;
infunction_code : unsigned int;
inin_data : ^ array[] of unsigned char;
out out_data: ^ array[] of unsigned c
Thomas Schwinge skribis:
> On Tue, 13 Sep 2011 10:46:01 +0200, l...@gnu.org (Ludovic
> =?iso-8859-1?Q?Court=E8s?=) wrote:
>> Should we rebase Savannah’s libc on top of the current upstream libc and
>> then update the topic branches accordingly?
>
> Yes, and I'm AT THE MOMENT :-) working towards
Hi!
On Tue, 13 Sep 2011 10:46:01 +0200, l...@gnu.org (Ludovic
=?iso-8859-1?Q?Court=E8s?=) wrote:
> Should we rebase Savannah’s libc on top of the current upstream libc and
> then update the topic branches accordingly?
Yes, and I'm AT THE MOMENT :-) working towards this. This time for real.
Real
Ludovic Courtès, le Tue 13 Sep 2011 10:46:01 +0200, a écrit :
> The libc patch from Savannah’s repo no longer applies to upstream libc [0].
> This is a consequence of the removal of lack-of-TLS support:
>
>
> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d063d164335938d557460bebaa7cfe38
Hi,
The libc patch from Savannah’s repo no longer applies to upstream libc [0].
This is a consequence of the removal of lack-of-TLS support:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d063d164335938d557460bebaa7cfe388157b627;hp=3ce1f2959437e952b9db4eaeed2407424f11a4d1
Should we reb
12 matches
Mail list logo
