Libc patch no longer applies

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

Re: Libc patch no longer applies

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

Re: Libc patch no longer applies

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

Re: Libc patch no longer applies

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

Re: Interface for SCSI transactions ?

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

Re: Interface for SCSI transactions ?

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

Re: Interface for SCSI transactions ?

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

Re: Interface for SCSI transactions ?

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

poke_pages function in ext2fs:truncate.c

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.

Should diskfs_file_update be called in every io_write?

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

Re: Should diskfs_file_update be called in every io_write?

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

Re: Should diskfs_file_update be called in every io_write?

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