Re:
úÄÒÁ×ÓÔ×ÕÊÔÅ! ôÅÐÅÒØ ÷Ù ÓÁÍÉ ÓÍÏÖÅÔÅ ÒÅÄÁËÔÉÒÏ×ÁÔØ Ó×ÏÊ ÓÁÊÔ É ÉÎÔÅÒÎÅÔ-ÍÁÇÁÚÉÎ ÎÅ ×ÌÁÄÅÑ ÓÐÅÃÉÁÌØÎÙÍÉ ÚÎÁÎÉÑÍÉ É ÐÒÏÇÒÁÍÍÎÙÍ ÏÂÅÓÐÅÞÅÎÉÅÍ! ðÒÅÄÌaÇÁÀ ÒÁÚÒaÂÏÔËÕ ÐÏÌÎÏÓÔØÀ ÉÎÔeÒÁËÔÉ×ÎÏÇÏ, ÄÉÎÁÍÉÞeÓËÉ ÏÂÎÏ×ÌÑeÍÏÇÏ ÓaÊÔÁ c ÉÎÔÅÒÎÅÔ - ÍÁÇaÚÉÎÏÍ ÷ÎÉÍÁÎÉÅ! òÅÄÁËÔÉÒÏ×ÁÎÉÅ É ÉÚÍeÎÅÎÉÅ ÓÔÒÕËÔÕÒÙ ÍÏÖÅÔ ÐÒÏÉÚ×ÏÄÉÔØ ÌÀÂÏÊ ÎÅÐÏÄÇÏÔÏ×ÌeÎÎÙÊ ÞÅÌÏ×ÅË ÞÅÒÅÚ ×ÅÂ-ÉÎÔÅÒÆÅÊÓ. óÁÊÔ ÂÕÄÅÔ ÓÄeÌÁÎ Ó ÐÒÉÍÅÎÅÎÉÅÍ ÔÅÈÎÏÌÏÇÉÊ ÄÉÎaÍÉÞÅÓËÏÇÏ ÒÅÄaËÔÉÒÏ×ÁÎÉÑ ÓÏÄeÒÖÉÍÏÇÏ, ÓÔÒyËÔÕÒÙ É ÉÎÔÅÒaËÔÉ×ÎÙÈ ÜÌÅÍÅÎÔÏ× (ÏÐÒÏÓÏ×, ÆÏÒyÍÏ×, ÄÏÓÏË ÏÂßÑ×ÌÅÎÉÊ, ÐÏÄÐÉcËÉ ÎÁ ÎÏ×ÏÓÔÉ É ÄÒ.). çÉÂËÁÑ ÎÁcÔÒÏÊËÁ É ÒÁÓÞÅÔ ÉÎÄÉ×ÉÄyÁÌØÎÙÈ É ÇÒÕÐÐÏ×ÙÈ cËÉÄÏË. éÎÔÅÇÒÁÃÉÑ ÓÏ ÓËÌÁÄÓËÉÍÉ ÐÒÏÇpÁÍÍÁÍÉ. éÎÓÔÒÕÍeÎÔÙ ÄÌÑ ÏÒÇaÎÉÚÁÃÉÉ ÒaÂÏÔÙ Ó ÄÉÌÅÒaÍÉ É ÐÁÒÔÎÅÒÁÍÉ. óÒÏË ÉÚÇÏÔÏ×ÌÅÎÉÑ 2 ÎeÄÅÌÉ. úÁÄa×ÁÊÔÅ ÐÏÖaÌÕÊÓÔÁ ×ÏÐÒÏÓÙ ÐÏ 8-(501) 222-5564 íoÓË×Á. ó Õ×ÁÖÅÎÉÅÍ, éÇÏÒØ. äÌÑ ÏÔ×ÅÔÏ× ÐÏÌØÚÕÊÔÅÓØ ÔÏÌØËÏ ÜÔÉÍ ÁÄÒÅÓÏÍ - [EMAIL PROTECTED] [O86X101J91R93B77W94X93X93B71T88Z93D74W90R87N79D70R82H73] ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
RE: Программ
МЕЖДУНАРОДНЫЕ КОНФЕРЕНЦИИ В МАЕ-ИЮНЕ 2004 года МЕЖДУНАРОДНЫЙ ИНФОРМАЦИОННЫЙ КОНСАЛТИНГОВЫЙ ЦЕНТР КИЕВ РАЗВТИЕ ВНЕШНЕЙ ТОРГОВЛИ МЕЖДУ УКРАИНОЙ И РОССИЕЙ В УСЛОВИЯХ НОВЫХ ТАМОЖЕННЫХ КОДЕКСОВ 22 мая 2004 года КИЕВ ** ВНЕШНЕЭКОНОМИЧЕСКАЯ ДЕЯТЕЛЬНОСТЬ- ТАМОЖЕННЫЕ ПРОЦЕДУРЫ И ТАМОЖЕННОЕ РЕГУЛИРОВАНИЕ. ТАМОЖЕННЫЙ КОНТРОЛЬ И ТАМОЖЕННОЕ ОФОРМЛЕНИЕ ГРУЗОВ. РЕЗУЛЬТАТЫ РАБОТЫ В УСЛОВИЯХ НОВОГО ТАМОЖЕННОГО КОДЕКСА УКРАИНЫ. 28 мая - 30 мая 2004 года КРЫМ ** ЕВРОПЕЙСКАЯ ЛОГИСТИКА. Работа Центральных складов (супермаркетов и гипермаркетов) ЕВРОПЕЙСКИЕ ТОРГОВЫЕ СЕТИ В ВАРШАВЕ. УПРАВЛЕНИЕ. МЕРЧЕНДАЙЗИНГ. 2-8 июня 2004 года ПОЛЬША ** РЕГИСТРАЦИЯ УЧАСТНИКОВ (044) 233 23 27 _ Cпециализированная конференция "РАЗВТИЕ ВНЕШНЕЙ ТОРГОВЛИ МЕЖДУ УКРАИНОЙ И РОССИЕЙ В УСЛОВИЯХ НОВЫХ ТАМОЖЕННЫХ КОДЕКСОВ" 22 мая 2004 года ВНИМАНИЮ: генерального директора, руководителей таможенных служб и отделов, руководителей экспортно- импортных и логистических подразделений, таможенных брокеров, а также представителей частного бизнеса. Организаторы конференции Международный Информационный Консалтинговый Центр "ICIC" Компания НПО "Поверхность" MDOffice На конференции выступят с докладом : Ведущие специалисты Представительства ГТК России в Украине Представители компании НПО "Поверхность" MDOffice Юрист-практик Программа семинара: 1Содействие развитию внешней торговли – приоритетная задача таможенных служб Российской Федерации и Украины. 2Новый Таможенный Кодекс РФ – новые возможности: 2.1 Ускорение и упрощение таможенных процедур: - использование информационных технологий; - дифференцированный подход в применении упрощенных процедур для различных категорий участников ВЭД; - сокращение сроков выпуска товаров - выборочность и разумная достаточность контроля. 2.2 Таможенные режимы - новые возможности. 2.3 Вопросы уплаты таможенных платежей. 2.4 Выпуск товаров до подачи таможенной декларации. 3 Обязанность и ответственность таможенных органов по вопросам консультирования в области таможенного дела. 4 Практическое использование отдельных положений Таможенного кодекса: предварительное решение о классификации товаров в соответствии с Товарной номенклатурой ВЭД, о стране происхождения товара. 5 Соглашение о свободной торговле. Условия преференциального (льготного) налогообложения при ввозе товаров в Украину. 6 Условия применения режима свободной торговли со странами СНГ. Правила определения страны происхождения. 7 Антидемпинговые мероприятия - как средство защиты отечественного товаропроизводителя от демпингового импорта. 8 Особенности поставки товаров по договорам о производственной кооперации. 9 Развитие взаимодействия таможенных органов Украины и России по обмену информацией о товарах и транспортных средствах. 10 Нетарифные барьеры. Договора о признании результатов сертификации, исследований и контроля. 11 Ответы на вопросы Участников. В ходе СЕМИНАРА у Вас будет возможность задать вопросы компетентным специалистам, узнать больше о нюансах применения новых норм украинского законодательства, на основе полученных знаний определить перспективы и стратегию развития Вашего предприятия. СТОИМОСТЬ УЧАСТИЯ В КОНФЕРЕНЦИИ: 590.00 грн. без НДС (единый налог) - за одного участника. В стоимость участия входит: информационно-консультационное обслуживание на семинаре, кофе-брейк, обед в ресторане, обсуждение докладов и обмен мнениями с лектором, сборник ” Митний Кодекс – питання та відповіді”, Презентационный CD диск MDОffice, журнал «Дистрибуция и Логистика». Регламент семинара: 9.30 - 17.00 Перерыв 13.00-14.00 Регистрация с 9.00 в Конференц-зале Заполнение анкет и получение бухгалтерского комплекта при регистрации. Зарегистрироваться и получить более подробную информацию о семинаре Вы можете по телефону: (О44) 233 23 27 ВНИМАНИЮ: генерального директора, руководителей таможенных служб и отделов, руководителей экспортно - импортных и логистических подразделений, таможенных брокеров, а также представителей частного бизнеса. Организаторы семинара Международный Информационный Консалтинговый Центр "ICIC" Компания НПО "Поверхность" MDOffice На семинаре выступят с докладом: Ведущие специалисты Государственной таможенной службы Представители компании НПО "Поверхность" MDOffice РЕГИСТРАЦИЯ УЧАСТНИКОВ (044) 233 23 27 _ Cпециализированная конференция "ВНЕШНЕЭКОНОМИЧЕСКАЯ ДЕЯТЕЛЬНОСТЬ- ТАМОЖЕННЫЕ ПРОЦЕДУРЫ И ТАМОЖЕННОЕ РЕГУЛИРОВАНИЕ. ТАМОЖЕННЫЙ КОНТРОЛЬ И ТАМОЖЕННОЕ ОФОРМЛЕНИЕ ГРУЗОВ. РЕЗУЛЬТАТЫ РАБОТЫ В УСЛОВИЯХ НОВОГО ТАМОЖЕННОГО КОДЕКСА УКРАИНЫ." 28-30 мая 2004 года на Южном побережье Крыма для украинских и иностранных фирм В програ
Re: hurd-2000072 crosscompilation
On Fri, Aug 04, 2000 at 04:39:34PM +0200, agx wrote:
> This is the error i get in serverboot
>
> gmake[1]: Entering directory
> `/usr/home/agx/src/hurd-2726/serverboot'
> i586-gnu-gcc -O
> -Wl,-rpath-link=.:../libdiskfs/:../libfshelp/:../libftpconn/:../libhurdbugaddr
>
>/:../libihash/:../libiohelp/:../libnetfs/:../libpager/:../libpipe/:../libports/:../libps/:../l
> ibshouldbeinlibc/:../libstore/:../libthreads/:../libtrivfs/ -g -O3
> -static -uargp_program_b
> ug_address -o serverboot \
> bootstrap.o ffs_compat.o load.o wiring.o def_pager_setup.o
> ffs_file_io.o minix_f
> fs_compat.o default_pager.o file_io.o minix_file_io.o ext2_file_io.o
> kalloc.o strfcns.o ./../e
> xec/exec.o panic.o elf-load.o gunzip.o bunzip2.o boot_script.o
> memory_objectServer.o default_p
> agerServer.o excServer.o bootstrapServer.o memory_object_defaultServer.o
> ./../exec/unzip.o ./.
> ./exec/inflate.o ./../exec/util.o ./../exec/do-bunzip2.o \
> '-Wl,-(' ../libhurdbugaddr/libhurdbugaddr.a
> ../libthreads/libthreads.a \
> \
> '-Wl,-)'
> load.o: In function `boot_script_exec_cmd':
> /usr/home/agx/src/hurd-2726/serverboot/load.c:375: undefined
> reference to `set_regs'
> ./../exec/exec.o: In function `check_elf':
> /usr/home/agx/src/hurd-2726/exec/exec.c:864: undefined reference to
> `elf_machine_matches_h
> ost'
> ./../exec/exec.o: In function `do_exec':
> /usr/home/agx/src/hurd-2726/exec/exec.c:1402: undefined reference to
> `check_hashbang'
> /usr/home/agx/src/hurd-2726/exec/exec.c:1493: undefined reference to
> `ports_create_port'
> /usr/home/agx/src/hurd-2726/exec/exec.c:1876: undefined reference to
> `ports_get_send_right
> '
> /usr/home/agx/src/hurd-2726/exec/exec.c:1927: undefined reference to
> `ports_port_deref'
> ./../exec/exec.o: In function `S_exec_startup_get_info':
> /usr/home/agx/src/hurd-2726/exec/exec.c:2167: undefined reference to
> `ports_lookup_port'
> /usr/home/agx/src/hurd-2726/exec/exec.c:2171: undefined reference to
> `ports_port_deref'
> collect2: ld returned 1 exit status
> gmake[1]: *** [serverboot] Error 1
> gmake[1]: Leaving directory `/usr/home/agx/src/hurd-2726/serverboot'
> gmake: *** [serverboot] Error 2
>
The symbols that are missing can be found in the files serverboot/exec.c,
exec/hostarch.c, exec/hashexec.c, libports/create-port.c,
libports/port-deref.c, libports/lookup-port.c. The makefile might have not
picked them up because they might not have compiled properly and didn't have a
.o extension. Make sure those object files are there and try again. Otherwise
you are free to flame the people who wrote the makefiles. :-)
Igor
Re: hurd-2000072 crosscompilation
On Sat, Aug 05, 2000 at 02:13:16PM +0200, Marcus Brinkmann wrote: > On Fri, Aug 04, 2000 at 10:17:22PM -0400, Igor Khavkine wrote: > > Otherwise > > you are free to flame the people who wrote the makefiles. :-) > > I would think twice. I have not these problems, and I just compiled the Hurd > two days ago. > > H eshould make sure he builds in a different directory than the source, and > that his cross cmpilation environment is proper. > > Marcus That's an excellent suggestion. But I do find the hurd Makefiles rather more complicated then neccesary. The topdirectory's Makeconf is just a mess to make sense of. I'm not really sure this approach is better then just having a Makefile in each directory which defines it's own rules instead of just including the topdir's Makeconf. Igor
More questions on gnumach internals
Hi, I have more questions about the internals of gnumach (oskit-mach to be more precise). I have either not been able to find answers to them, or it's very difficult to deduce them from the sourcecode. 1. Where, if anywhere, does gnumach change into virtual 8086 mode? If it does then what purpose does it serv? If it doesn't and and if only the kernel code has high enough privelege level to change to vm86 mode, why is it even mentioned in the code (in a few placed deep in i386/i386/)? 2. I've noticed that the `copyin' routine (defined in i386/i386/locore.S) does no checking as to whether it's accessing valid memory from user space. Where is the user space address checked for validity before invoking `copyin'? If it's not in principly a user can generate a page fault by supplying an invalid pointer which ends up as an argument for this routine. 3. And what *does* happen if there is a page fault from kernel space while accessing user space memory? `kernel_trap()' in i386/i386/trap.c seems rather pessimistic and panics a lot. If the user supplied an invalid address would it not be appropriate to raise an access violation exception? Thanks in advance. Igor
FPU emulation support for gnumach
Hi, for some time now I've been trying to incorporate the Linux FPU emulation code into gnumach (oskit-mach to be more precise). I'll be moving in the next few days and won't really be able to work on it in the mean time. So I decided to release a *very* preliminary patch for anyone who wants to look at what I've done. You can get it at http://alcor.concordia.ca/~i_khavki/, please read the description and the instructions on that page before downloading it. As I said, it's *very* preliminal and I intend to go through all the relevant code with fine toothed comb a couple of more times to make sure everything works. But I will need help testing it. Thanks. Igor
Problems with oskit-mach
I tried testing my patch for fpu emulation for oskit-mach in the last coupla days. The first step was to actually boot with the oskit-mach kernel. However that's where my problems started, and I haven't been able to get past that. The first problem was that my computer generated a general protection fault in the i386/intel/pmap.c::pmap_boostrap() function where the code was trying to modify the %cr4 register. I have a K6-III which pretends to support the PGE extension (judging from the cpuid output), the code was trying to enable the flag for this feature in the %cr4 register and that generated the GPF. However the same code did not produce any errors while booting with the same kernel image inside Bochs, which claims to be a Pentium emulator. I'm not sure if it's a bug or simply an undocumented feature of my K6 cpu, becuase K6's claim to be Pentium (i586) compatible, but my book on Intel microprocessors claims that the PGE extension was only added in Pentium Pro's (i686). So I don't even know if my cpuid output is correct. Has anyone else been able to run oskit-mach on a K6 cpu? And another thing, to the best of my knowledge the cr4 register did not appear in the ix86 family before the Pentium (i586) CPU, so why isn't that code in pmap_bootstrap() in an #if defined(i586) || defined(i386) ? Once, I kludged around that problem What I got was a page fault in the main emulation function i386/i386/math-emu/fpu_entry.c::math_emulate() which I identified and tried to fix. However upon subsequent attempts to boot with a recompiled image of the kernel, I no longer get the same error. Infact I can't even determine what kind of error I get because once the boot messages get past the detection of my IDE hardrives and cdrom, my computer just reboots faster then the eye could catch the error message. Would anyone care to suggest a place where to put a convenient `while(1);' statement so that I could actually see what the problem is? The same problem does not occur while with the Bochs emulator but the problem there is actually trying to get enough code to do the tests on a floppy image. I have to say I've found it quite problematic trying to create a hardrive image and to put stuff on it. I'll try to work on it a bit more and see what I can do. Oh, and that raises another question, what is a multiboot module supposed to look like? In other words what do I have to do if I want to plug something in instead of serverboot? Any suggestions and comments are very welcome. Even just to tell me if I'm talking crazy talk. :-) Thanks. Igor
Oskit-mach followup
Hi, after a prolonged absence I'm finally back online. But I've falling behind on the mailing list a bit. My current priority is to try and get oskit-mach to boot on my machine. As I've mentioned before, on my machine when oskit-mach boots it basically crashes and/or instantly reeboots, first when it gets to enabling the PGE feature in my K6. If that part is commented out, it goes past that point but after it detects the HDs and possibly something else, and reboots in the blink of an eye, infact so fast that I can't even read any messages that might have appeared on the screen. Has there been any followup on these problems? If anyone has any suggestions as to what parts of the code might cause this annoying reboot and how to disable it, please don't hold them back. :-) If that's not possible, I could put a break point just before the reboot, but I'm still at a loss as to where exactly it occurs. Oh, and another thing. I've done a lot of looking through mach's code and some if it looks like a holy mess. I'd just like a show of hands, who thinks that some parts of gnu/oskit-mach should be reviewed and cleaned up? Another question I have is, who actually likes mig and it's interface definitions? Or more people think that it should be changed/replaced? I remember there was some talk about switching to CORBA semantics for RPCs, is that idea still alive? Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
I've got it! (Re: oskit-mach)
Finally, I've been able to find the source of my mysterious
reboots when booting oskit-mach.
The reboot comes from a `panic' call from the `free_for_oskit' routine
in [gnumach]/oskit/osenv_mem.c. Here's that piece of code:
--- snip ---
if (in_oskit_interrupt)
{
/* oy */
panic ("free_for_oskit of virtual memory from interrupt level");
/* If this ever happens, make a little free list and have the
pageout daemon run over it doing kfree. */
}
else
kfree ((vm_offset_t) block, size);
--- snip ---
Well it did happen, the linux floppy driver from oskit wanted to free some
memory for dma. So Roland (or whoever wrote that code), why is this a
special case and what was your plan exactly?
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: I've got it! (Re: oskit-mach)
On Sat, Sep 30, 2000 at 09:41:55PM -0400, Roland McGrath wrote: > > The reboot comes from a `panic' call from the `free_for_oskit' routine > > in [gnumach]/oskit/osenv_mem.c. Here's that piece of code: > > Interesting. Can you show me the stack trace? The oskit panic routine > should print out a stack trace. You can feed the addresses to addr2line to > get the functions and source locations from your kernels debug symbols. > (Or if you are using gdb over the serial line to debug oskit-mach, just do > "bt" in gdb.) Hmm, if only I had a spare serial terminal lying around. :-) It's a neat thing this addr2line, except that I didn't know about. I used the old `nm kernel | sort | less' trick. But here's the my stack dump: 0016e5fa (from oskit) 001002fb-+_ [gnumach]/oskit/osenv_mem.h 001007af -+ 00151604 -+ 0014cd6d | 0014a14a |- in Oskit 001536cd | 00153742 | 001513fd -+ 00100d2a [gnumach]/i386/i386at/interrupt.S 00103789 ??? I can't give more info because, I don't have the image that gave this stack dump anymore. I simply commented out the part of the code that panicked and just used kfree anyway. From what you said below this is not totally safe, but it did work and I was finally able to boot with oskit-mach. I haven't tried using the floppy drive though. Now I can proceed with testing my FPE code additions. Igor > > > Well it did happen, the linux floppy driver from oskit wanted to free some > > memory for dma. So Roland (or whoever wrote that code), why is this a > > special case and what was your plan exactly? > > It's an issue of atomicity. The Mach kernel memory allocator (kalloc and > kfree) are called with interrupts enabled, meaning that a kalloc call from > some kernel code might be interrupted e.g. to run a device driver's > interrupt handler. Since this is a possibility, it's not safe for any code > called from an interrupt handler to use kalloc/kfree. The check in this > function is to make sure that it's not a call from inside an interrupt > handler when it decides to use the kernel memory allocator. > > It might well be that I need to handle this case, as described in the > comment you cited. But I am a bit suspicious and would be inclined to > investigate what the circumstances are in fact. For the piece of memory in > question (something allocated by the floppy driver, I gather from what you > said), what is it used for, where is it allocated and freed? The > alloc_for_oskit function decides what flavor of memory to allocate based on > the parameters in the oskit interface, which are less than perfectly > communicative. It might be the case that this thing really ought to be > allocated in contiguous physical memory. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
gnumach and oskit headers
I've looked through gnumach's machine dependent headers trying to see where they could be replaces by equivalet oskit headers to eliminate redundancy. So now I've eliminated most of the redundancy and removed the unneeded headers from my local copy of gnumach (oskit-mach) rather. Now I'm just wondering if there are certain .h files that just HAVE to be there and are maybe exported to user programs (in /usr/include/mach/) for example. Also a lot of oskit headers are simply taken from mach and are identical except a few subtle cases. For example oskit/x86/base_gdt.h defines USER_CS to be 0x43 and i386/i386/ldt.h defines it to be 0x17. The macro names are the same and i've never seen a hardcoded value used it it's place, so is there a particular preference to either numerical value? Or is this question too trivial to be answered? :-) Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: gnumach and oskit headers
On Wed, Oct 18, 2000 at 02:05:38AM -0400, Roland McGrath wrote: > > I've looked through gnumach's machine dependent headers trying to see > > where they could be replaces by equivalet oskit headers to eliminate > > redundancy. So now I've eliminated most of the redundancy and removed the > > unneeded headers from my local copy of gnumach (oskit-mach) rather. > > Please be specific about which files you are hacking on. I have avoided > unnecessary diddling of the user-visible headers, to keep the gnumach-devel > package compatible between gnumach and oskit-mach. The user-visible > headers are in include/ and i386/include/. I believe there are files in > those directories that are in fact not used outside the kernel, and it > would be good to get rid of these so the user-visible Mach headers are a > minimal set providing just the actual kernel interfaces proper. Ok, I've attached a listing of the old sate and the new state of [gnumach]/i386/. > > > Also a lot of oskit headers are simply taken from mach and are > > identical except a few subtle cases. For example oskit/x86/base_gdt.h > > defines USER_CS to be 0x43 and i386/i386/ldt.h defines it to be 0x17. > > The low three bits of those values are flag bits to the hardware. > So which set of flags has advantage over the other? Igor gnumach.old/i386/: CVS/ Files Makefrag Subdirs i386/ i386at/ include/ intel/ gnumach.old/i386/CVS: Entries Repository Root Tag gnumach.old/i386/i386: CVS/ ast.h ast_check.c ast_types.h cpu_number.h cswitch.S eflags.h fpe_linkage.c fpu.c fpu.h gdt.c gdt.h hardclock.c i386asm.sym idt-gen.h idt.c idt_inittab.S io_emulate.c io_emulate.h io_port.h iopb.c iopb.h ipl.h ldt.c ldt.h lock.h locore.S mach_i386.srv mach_param.h machine_routines.h machspl.h mp_desc.c mp_desc.h pcb.c phys.c pic.c pio.h pit.c pmap.h sched_param.h spl.S spl.h thread.h time_stamp.h trap.c trap.h user_ldt.c user_ldt.h vm_param.h vm_tuning.h zalloc.h gnumach.old/i386/i386/CVS: Entries Repository Root Tag gnumach.old/i386/i386at: CVS/ idt.h int_init.c interrupt.S pic_isa.c gnumach.old/i386/i386at/CVS: Entries Repository Root Tag gnumach.old/i386/include: CVS/ Makefile.in mach/ gnumach.old/i386/include/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach: CVS/ i386/ machine/ proc_ops.h sa/ setjmp.h gnumach.old/i386/include/mach/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/i386: CVS/ asm.h bios.h boolean.h code16.h cthreads.h debug_reg.h disk.h dpmi.h eflags.h exception.h exec/ far_ptr.h fp_reg.h ioccom.h kern_return.h mach_i386.defs mach_i386_types.h machine_types.defs* multiboot.h paging.h pio.h pmode.h proc_reg.h rpc.h seg.h syscall_sw.h thread_status.h time_stamp.h trap.h tss.h vcpi.h vm_param.h vm_types.h gnumach.old/i386/include/mach/i386/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/i386/exec: CVS/ elf.h gnumach.old/i386/include/mach/i386/exec/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/machine: CVS/ asm.h bios.h boolean.h code16.h cthreads.h debug_reg.h disk.h dpmi.h eflags.h exception.h exec/ far_ptr.h fp_reg.h ioccom.h kern_return.h mach_i386.defs mach_i386_types.h machine_types.defs* multiboot.h paging.h pio.h pmode.h proc_reg.h rpc.h seg.h syscall_sw.h thread_status.h time_stamp.h trap.h tss.h vcpi.h vm_param.h vm_types.h gnumach.old/i386/include/mach/machine/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/machine/exec: CVS/ elf.h gnumach.old/i386/include/mach/machine/exec/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/sa: CVS/ stdarg.h sys/ gnumach.old/i386/include/mach/sa/CVS: Entries Repository Root Tag gnumach.old/i386/include/mach/sa/sys: CVS/ varargs.h gnumach.old/i386/include/mach/sa/sys/CVS: Entries Repository Root Tag gnumach.old/i386/intel: CVS/ pmap.c pmap.h read_fault.c gnumach.old/i386/intel/CVS: Entries Repository Root Tag gnumach.new/i386/: CVS/ Files Makefrag Subdirs i386/ i386at/ include/ intel/ gnumach.new/i386/CVS: Entries Repository Root gnumach.new/i386/i386: CVS/ ast.h ast_check.c ast_types.h cpu_number.h cswitch.S eflags.h fpu.c fpu.h gdt.c gdt.h hardclock.c i386asm.sym idt.c idt_inittab.S io_emulate.c io_emulate.h io_port.h iopb.c iopb.h ipl.h ldt.c ldt.h lock.h locore.S mach_i386.srv mach_param.h machine_routines.h math-emu/ mp_desc.c mp_desc.h pcb.c phys.c pic.c pio.h pit.c pmap.h sched_param.h spl.S spl.h tags thread.h time_stamp.h trap.c trap.h user_ldt.c user_ldt.h vm_param.h vm_tuning.h zalloc.h gnumach.new/i386/i386/CVS: Entries Repository Root gnumach.new/i386/i386/math-emu: CVS/ Makefile README control_w.h div_Xsig.S div_Xsig.o div_small.S div_small.o errors.c errors.o exception.h fpu_arith.c fpu_arith.o fpu_asm.h fpu_aux.c fpu_aux.o fpu_emu.h fpu_entry.c fpu_entry.i fpu_entry.o fpu_entry.s fpu_etc.c fpu_etc.o fpu_proto.h fpu_system.h fpu_tags.c fpu_ta
Re: gnumach and oskit headers
6/intel/read_fault.c > > So which set of flags has advantage over the other? > > It's not a question of "better flags". The flags need to be appropriate > for the segmentation setup the kernel is using. Mach sets up its own > segments for user mode. Point taken. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Update on FPU emulation
Ok, I've improved and actually tested my patch for FPU emulation in oskit-mach. You can get it at http://alcor.concordia.ca/~i_khavki/. Now there are still problems like some instructions are not interpreted properly and generate an illegal instruction exception. I'm still not sure why that's happening and whether the emulator's instruction decoder or my changes are at fault. Also note that it's a fairly big patch, that's because I've also been messing with my oskit-mach tree trying to eliminate redundancy with respect to what's provided by oskit. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: reviving oskit-mach
On Thu, Oct 26, 2000 at 05:19:00PM -0400, Roland McGrath wrote: > I bought some computers and I am now almost back in the saddle. I am not > quite ready to set up my Hurd yet, but I'm starting to hack on getting > oskit-mach to build cleanly again (I'm building on Linux). So I would like > to hear anew any reports of people to build or use oskit-mach (I don't care > about gnumach), and I will try to look into them starting this weekend. It > would be nice if we could use the Debian BTS for this, but I don't think > there is an entry for oskit-mach and I don't want to intermingle the > reports with gnumach's reports. So just send your bugs to bug-hurd. > I've been working with oskit-mach all this thime that I've been trying to get FPU emulation to work. At the same time I hacked my source tree a bit to clean it up. Earlier I posted a list of headers that I deleted because they seemed redundant, you seemed to agree with most of them. You might want to check out the patch I produced with my source tree against the one pulled from CVS. http://alcor.concordia.ca/~i_khavki/ Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)
On Sun, Oct 29, 2000 at 06:57:41PM -0500, Roland McGrath wrote: > Perhaps there should just be another mailing for wild speculations about > random development ideas tangentially related to the Hurd development > effort. Then I would read that one when I was in that kind of mood. These > lists really exist for concrete discussion of real problems with the > existing code base and new code we expect to write in the immediate short > term to solve specific problems people are having with using the Hurd in > its current context. That is the kind of discussion I am usually in the > mood for when I have a little spare time to think about the Hurd. > I agree, I myself don't have much time to spend on Hurd development. And I have to learn as I go along, and that slows me down as well. But I do have ideas that I'm not willing/can't work on right away (that's the hacking part) but that would profit from some discussions (that's the talking part). So that kind of list would be a good idea. For example it would redirect threads like the "filesystem-mimetypes extensions" that we had on debian-hurd a while back. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PPP port: Code for setting gateway
On Sat, Nov 25, 2000 at 01:50:37AM -0600, Daniel E Baumann wrote:
> Here is the code I wrote for setting the gateway in bundle.c, I welcome any
> comments. Some of this I borrowed from fsysopts.c.
>
I hope this is prototype code because there is a couple of obvious
blunders.
> int
> bundle_SetRoute(struct bundle *bundle, int cmd, struct in_addr dst,
> struct in_addr gateway, struct in_addr mask, int bang,
> int ssh)
> {
> #ifdef __GNU__
> int result = 1;
> error_t err;
>
> /* The file we use as a handle to get FSYS. */
> char *node_name;
> file_t node;
>
> /* The filesystem we're passing options to. */
> fsys_t fsys;
> char *opt = strcat("--gateway=", inet_ntoa(gateway));
Hmm, you can't really append a string to a literal string,
most often you'll get a segfault. Try:
char opt[sizeof("--gateway=255.255.255.255")] = "--gateway=";
strcat(opt, inet_ntoa(gateway));
>
> sprintf(node_name, "%s/%d", _SERVERS_SOCKET, PF_INET);
Well, that's another segfault right there, you're trying to write
to a wild pointer. Try:
asprintf(&node_name, _SERVERS_SOCKET "%d", PF_INET);
Actually you don't even have to use asprintf(), just allocate an array
large enough to hold _SERVERS_SOCKET + largest integer. Too bad
you can't embed a constant integer into a string at compile time.
> node = file_name_lookup (node_name, 0, 0666);
> if (node == MACH_PORT_NULL)
> {
> log_Printf(LogERROR, "HURD: Can't open port to pfinet server,
> file_name_lookup
> failed with %s.\n", strerror(errno));
> error (1, errno, "%s", node_name);
> }
>
>/* Get the filesystem for NODE. */
> err = file_getcontrol (node, &fsys);
> if (err)
> {
> log_Printf(LogERROR, "HURD: Can't get the filesystem for node %s.",
> node_name);
> error (2, err, "%s", node_name);
> }
>
> err = fsys_set_options (fsys, opt, 1, 1);
> if (err)
> {
> log_Printf(LogERROR, "HURD: Failed to set option %s for node %s.", opt,
> node_name);
> error(5, err, "%s: %s", node_name, opt);
> }
>
> log_Printf(LogDEBUG, "HURD: The pfinet server's gateway is set to %x\n",
> (unsigned)gateway.s_addr);
>
> return result;
>
> #else
> ...
>
> Dan
Otherwise looks good.
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Small bug in libnetfs
I came across a potential segfault in the libnetfs code.
Here's the patch.
Igor
Index: libnetfs/make-node.c
===
RCS file: /cvs/hurd/libnetfs/make-node.c,v
retrieving revision 1.4
diff -u -r1.4 make-node.c
--- libnetfs/make-node.c1996/07/03 15:55:32 1.4
+++ libnetfs/make-node.c2000/12/19 08:11:19
@@ -25,7 +25,9 @@
netfs_make_node (struct netnode *nn)
{
struct node *np = malloc (sizeof (struct node));
-
+ if (!np)
+return NULL;
+
np->nn = nn;
mutex_init (&np->lock);
Re: oskit-mach vs PGE
On Thu, Dec 21, 2000 at 11:52:07PM -0500, Roland McGrath wrote: > Someone in the Utah group just noticed that the oskit's header file > defines CR4_PGE with the wrong value (0x20 should be 0x80). Maybe that's why I had those problems booting with oskit-mach unless I disabled setting the PGE flag. I'll try compiling the kernel again after the holidays. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
On Thu, Feb 08, 2001 at 09:14:57AM +1100, Brian May wrote: > >>>>> "Mridul" == Mridul Jain <[EMAIL PROTECTED]> writes: [snip] > Mridul> protocol is that It is the Corba standard.If I want a > Mridul> "TRUE" Corba implementation in GNUMach/HURD then the > Mridul> protocol should be IIOP compliant.Also if we have strict > Mridul> CORBA implementation we can write the HURD servers in > Mridul> other languages too. There are also a bunch of other > > Agreed, I think this is an advantage. > > Multi-language support might already be possible with MIG(?), but > since CORBA is more standard, it is likely to be available for more > languages. > As far as I know MIG only supports C. Modifying MIG to support other languages would probably not be worth the effort. Even the C code that it generates isn't that great either. > Mridul> reasons which can be discussed in subsequent mails. > Mridul> Although I had a bit of success with some Hurd Server Eric > Mridul> had said that there might be problems in some cases as > Mridul> there are many MIG IDL notions that don't map well onto > Mridul> IIOP, e.g., the various flavors of port rights. It would > Mridul> take some effort to emulate these features while avoiding > Mridul> Mach IPC. > > I am not really familiar with these issues, but I think it would still > be worth it even if it led to short term breakage and/or > incompatibilities. The more obscure featres of MIG support the more obscure features of Mach IPC. Not only is it not worth to incorporate it into OMG's IDL, it would be a mistake. HURD shouldn't rely on obscure Mach features if it wants to be micro-kernel independent. And in any case the ability to support multiple languages and communication protocols through OMG's IDL would outweigh all other arguments. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
On Thu, Feb 08, 2001 at 11:34:26AM +0200, Eray Ozkural (exa) wrote: > Mridul Jain wrote: > > > > hi, > > As I was preparing to work on the topic - Corba > > replacement for MIG ; > > Make sure it doesn't turn out to yield a Java level performance. ;) > > That standard called Corba was not tailored for microkernel > message passing. > > I can notice the messages as they are being sent on this GNOME > desktop. That would not make a good bet for a hurd server. CORBA is only a source level standard. It is not restricted to IIOP or any other message passing protocol, the so to say "backend" can be changed according to need. For example regular IPC on the same machine can be done through the Mach message passing facilities, like MIG does now, however the same code that uses CORBA can easily be adapted to use IIOP for remote machines by changing the "backend". The details depend on the ORB (object request broker). Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
On Wed, Feb 14, 2001 at 03:21:16AM +0100, Farid Hajji wrote: > > We're talking about a microkernel arch, but still I'm > > not sure if turning hurd into gnome is a good idea. > [...] > > Interoperability is a good idea, but if you bloat the > > whole code with interoperability stuff then it blows up. > You can add as much interoperability stuff between apps. > if you wish. But please keep the overhead to a minimum > when it comes to hurd servers!! > > 1. Porting the Hurd to non-Mach kernels (L4 is being one of >the candidates) would be IMHO easier if the interfaces >use plain C and are as simple as possible. > >The problem here is not the interoperability or adding >yet another abstraction layer on top of what is already >there. On the contrary: There is currently too much >communications overhead already in the ports library. > > I'd humbly suggest that before we seriously consider Corba > as a MiG replacement, we simplify the existing interfaces > as much as possible. Trying to port the Hurd to L4 is a > hard enough task and I'd prefer to have to _simplify_ MIG > (requirements) and provide an L4 backend to it, rather than > having to fight with yet more complex interfaces. [Sure, > L4 has completely different characteristics as Mach, like > synchroneous IPC and lack of port-rights, so a port to L4 > requires much more work than just adapting MiG, but why > make it even harder?] CORBA is not a runtime library, so if you "add CORBA" support to something does not necessarily mean bloat. CORBA is mainly a standard to aid in development, I think that's the best light that IDL could be cast in. If you know that you'll know that the interfaces you're dealing with are Mach ports (or whatever L4 uses), you can implement the actual message passing with inline stubs that use Mach's (or L4's) proper messaging protocols. Hence no performance is lost, and you've just saved yourself a whole lot of typing effort. Also microkernels do not need to have anything to do with CORBA at all, infact it would be a mistake to tie the former with the latter. The best way CORBA can be used is as a development aid to superimpose uniform interface types on otherwise very different backends, Mach and L4 for example. [ snip ] > > 2. The Hurd is intimately tied to glibc (sysdeps/hurd, sysdeps/mach/*) >and unthinkable with another libc. If you want to port the Hurd, >you _must_ currently also port glibc. This actually makes perfect sense. Hurd and glibc are part of the same larger project, GNU. And Hurd was specifically designed to be integrated with glibc, it didn't happen because of some fluke or because people were lazy. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Interaction of pthreads and cthreads
On Thu, Apr 26, 2001 at 03:57:53PM -0400, Roland McGrath wrote: > I had never anticipated anyone trying to implement pthreads for the Hurd > in any way but by a substantial rewrite of the libc hurd code. When pthreads will actually be implemented. Do you think it would be a good idea to rewrite the parts of glibc and hurd that use cthreads now? It seems that there should be no reason to have two competing thread implementations used in the same applications. Or is it too much work for little gain? Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: page fault in mach_msg_trap
On Sun, May 13, 2001 at 02:54:14PM -0700, Thomas Bushnell, BSG wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > The time it pauses is too short to write down all registers. We should > > consider increasing it. > > The time is a rapid spinning loop, IIRC, and has gotten shorter as > processors have gotten faster; it should be timed to bogomips or > something like that. Why should there be a finite delay? I think a much better option is wait for the user to press a key before rebooting. When I was working with oskit-mach I was lazy so I just put a "hlt" instruction in panic so I would have to manually reset the machine to reboot. But it did give me unlimited time to examine the error messages. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
oskit-mach won't boot
I've just pulled the oskit-mach source from CVS build it and tried to
boot it. Unfortunately, it didn't work. That wasn't totally unexpected
given my rotten luck with trying new kernels.
Once the boot process gets to a certain point the computer just
restarts. That means it's some sort of unhandled fault.
I've managed to track down the problem to spl0() (defined in
i386/i386/spl.S). Here's how it happens:
main -> setup_main -> cpu_launch_first_thread ->
load_context -> Load_context -> Thread_continue ->
thread_continue -> spl0
And then the computer just restarts. spl0() is an assembly routine
that means I can't just put debug printf's in the middle of it, like
I didn in other places along the way. And after looking at the code
I fail to see where the problem could lie. (Partly because my
assembly skills are rather limited.)
Any input and suggestions are very welcome.
Igor
P.S.: I came up with a new way to provide debug information while booting
the kernel. "Debug by ear," just define these simple routines somewhere
and whenever debug_beep() is used, it produces a PC speaker sound
and a short delay.
void volatile spin_loop (unsigned long n) {
unsigned long i;
for (i=0; ihttp://mail.gnu.org/mailman/listinfo/bug-hurd
vm_offset_t type
I just noticed that when tracing back the type of `vm_offset_t' we get back to `natural_t' which is defined with this comment in /include/mach/i386/vm_types.h: /* * A natural_t is the type for the native * integer type, e.g. 32 or 64 or.. whatever * register size the machine has. Unsigned, it is * used for entities that might be either * unsigned integers or pointers, and for * type-casting between the two. * For instance, the IPC system represents * a port in user space as an integer and * in kernel space as a pointer. */ typedef unsigned int natural_t; But isn't it true that most modern 64bit compilers still use a 32 bit `int', but have a 64 bit `long'. The comment says that natural_t should be wide enough to accomodate a whole register or pointer. In that case, shouldn't it be defined as typedef unsigned long natural_t; since `long' is still 32 bits on 32bit architectures. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: posix_spawn
On Sat, Jun 16, 2001 at 05:53:52AM -0400, Roland McGrath wrote: > It has been noted that the slowness of fork on the Hurd may be a > substantial factor in uses like large builds. One way to avoid this > problem is to avoid fork. In glibc we have providing posix_spawn > and related functions; most common cases where a program uses fork and exec > directly can be replaced by calls to posix_spawn et al. Just out of curiosity, is posix_spawn a standard interface? And is it reasonable for programs to expect to have it available on a system that say, doesn't use glibc? Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Internal library naming conventions
This is just a curiosity question and could be a bit of topic. Why is it that most libraries (like glibc) prefix all their functions with __. Even the ones that will eventually be exported. I've come up with two possible reasons: 1) avoid global namespace polution. This can also be avoided by grouping more functions into files and declaring some of then static. 2) avoid problems with interposing. So that when a user defines a function of the same name the internals of the library are not affected because it uses the same function but with __ in front of it. Which one of these reasons most relevant? Are there other ones? Thanks. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Annoying free inode warnings
On Wed, Jun 20, 2001 at 04:56:20PM -0500, Neal H Walfield wrote: > > Would you accept a patch to add a configure option that removes the > > annoying 'free inode' warning messages? I can set it on by default, > > if you'd like. > > > > My final preference would be to leave it disabled until e2fsck is > > willing to fix the problem when the FS is checked with -f, but having > > a reasonable way to disable it for now would be enough. > > I think that we can, if fact, safely ignore these warnings. I have four > partitions that I use actively. Only one of them has ever been touched > by Linux -- the root filesystem and it is the only one that ever > produces these warnings. I don't think the danger (or lack thereof) presented by these warnings is being dsiputed. It is simply very annoying. I have a patition for development that I use both in linux and Hurd. And when I run a build from that partition while in Hurd, an inane amount of these warnings floods the screen rendering it impossible to use even in another terminal provided by `screen'. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Annoying free inode warnings
On Wed, Jun 20, 2001 at 06:45:39PM -0500, Neal H Walfield wrote: > > I don't think the danger (or lack thereof) presented by these warnings > > is being dsiputed. It is simply very annoying. I have a patition > > for development that I use both in linux and Hurd. > > I think it was; Roland mentioned this earlier. I won't argue with experts but in my experience they are harmless. > > And when I run > > a build from that partition while in Hurd, an inane amount of these > > warnings floods the screen rendering it impossible to use even in > > another terminal provided by `screen'. > > It writes directly to the console and screen never sees it (try > refreshing the console ^L). That works quite well, except that ext2fs is much more efficient at outputing those warnings than I am at pressing ^L to refresh the screen. :-) Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Internal libc lock interface
I found a header in glibc that defines a generic lock interface. The file is sysdeps/generic/bits/libc-lock.h. There is a Mach specific version of it in sysdeps/mach/bits. It is implemented on top of cthread locks. Was intended to be a high level or low level lock inteface? So should I try to reimplement it on top of spin_lock's or pthread_mutex's? In the former case, how do I deal with rwlocks (what are these btw?) or recursive locks. In the latter I have to come up with a lower level generic interface to locks. Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Internal libc lock interface
On Thu, Jun 21, 2001 at 06:32:12AM -0400, Roland McGrath wrote: > rwlock is to mutex as pthread_rwlock is to pthread_mutex I see. It's just a simple abstraction for the Readers-Writers problem. I also found a stub in sysdes/generic for machine-lock.h. It defines the atomic __spin_lock operations and there are non stub implementations for severa arch's. It contains very few definitions. So I think I'll add more definitions and use __spin_lock's throughout pthreads. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Passive versus active translators
On Thu, Jun 21, 2001 at 06:01:00PM -0500, Neal H Walfield wrote: > Using settrans to start an active translators sets up a completely > different enviornment than that created when a file system launches a > passive translator. There are three main differences: > > o File descriptors > - settrans: stderr is the user's tty > - libfshelp: nothing You're right this difference is justifiable. > o Current working directory > - settrans: user's current working directory > - libfshelp: the directory in which we find the > translator. In the case of settrans it is logical to set the cwd of the translator to the user's current cwd like for any other program the user runs. And as for the second case, there's not much chioce but to start the translator in the directory of the node. And it also makes sense, think relative symlinks. > o User ids > - settrans: The euid and egid of the user that lauched > settrans. > - libfshelp: The uid and gid of the node. The user might not always (unlike root) have the ability change the euid and egid of a process to those of an arbitrary node. So the translator has to be started with the priviliges of the user. And if a passive translator is started up with the priveleges of the user that wakes it up it, it would be impossible to implement some things that translators do already. For example a filesystem translator has to run with the priveleges of the underlying node, otherwise it would be unable to write any data to store-nodes which have root-only write permissions. > > o emit a warning if the translator is a relative path, e.g. > `settrans foo bar'. That's a reasonable suggestion. > o use fshelp_start_translator_long instead of > fshelp_start_translator and sets the uid and gid to that of > the underlying node. Like I mentioned above that's not always possible unless you're root. > o set the current working directory of the translator to that of > the directory of the translator. It is usually the case that a translator resides in a directory full of binaries (like /hurd). If it expects to find any sort of data files in its cwd, it will certainly not find them in there. I think that the differences between the use of settrans and the waking of a passive translators differ in natural and necessary ways. The differences are akin to the startup of any program by a user, as opposed to automatic startup of a background daemon. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Passive versus active translators
On Thu, Jun 21, 2001 at 11:48:02PM -0500, Neal H Walfield wrote: > My point is that whether a translator is started by the filesystem or by > settrans, the behavior should be basically the same. > > > > o Current working directory > > > - settrans: user's current working directory > > > - libfshelp: the directory in which we find the > > > translator. > > In the case of settrans it is logical to set the cwd of the translator > > to the user's current cwd like for any other program the user runs. And > > as for the second case, there's not much chioce but to start the > > translator in the directory of the node. And it also makes sense, > > think relative symlinks. > > I do not see how this makes sense. I see how it is logical, however, it > is misleading. Consider the following: > > # settrans -cap ~/foo /hurd/isofs cdimage > > The active translator will start, however, once it is stopped, the > filesystem will to be able to restart it. In this scenario, guessing > from the `-ap', the user likely wants to make sure that the translator > is setup and correctly and then wants to forget about it. You're confusing the behavior of settrans with mount. If you do: # cd /dev; mount -t iso9660 hdd ~/foo Then even though hdd was indicated as with a relative path, the full location of the device file is communicated by mount to the kernel. and thus will work. That's because mount knows that hdd is a special argument that is a file and has to be resolved to a full pathname. But you run into problems with fstab and automount because to get it to work you still have to specify the full path name of the devices. Settrans is inherently different from mount, it knows only about two special arguments the node and the translator. The node's full path is resolved when the translator is started. But settrans knows nothing about the arguments to the translator. It doesn't even have to be a filename. In case of, lets say, a random number generator translator its argument could be the random seed. So it has to be the translator's responsibility to resolve all of its arguments properly. Since settrans can't do anything about the arguments to the translator, it's important to realize that they will work like arguments to the translator if it was started by the user like a regular program. > > > o User ids > > > - settrans: The euid and egid of the user that lauched > > > settrans. > > > - libfshelp: The uid and gid of the node. > > The user might not always (unlike root) have the ability change > > the euid and egid of a process to those of an arbitrary node. > > So the translator has to be started with the priviliges of the > > user. > > Not true; make settrans suid root. This would open up a whole flood of security risks. > > And if a passive translator is started up with the > > priveleges of the user that wakes it up it, it would be impossible > > to implement some things that translators do already. For example > > a filesystem translator has to run with the priveleges of the > > underlying node, otherwise it would be unable to write any data > > to store-nodes which have root-only write permissions. > > I am not suggesting this at all. This is what I am trying to > communicate: > > # cd > # sudo settrans -acp foo /hurd/ext2fs /dev/hd0s2 > > ext2fs is launched as root.root. However, the passive translator will > run as root.neal (as my home directory is neal.neal). Now, because the > Hurd has group leaders, I will be considered an owner of the translator. > > The active translator should be started with the same ids that the > passive translator will be started with. I think you're getting off the wrong foot when you start assuming that any user can `sudo settrans' anytime. If someone who has root priveleges puts a translator on a node with permissions root.neal they should know what they are doing just like with suid executables. But I do agree that settrans should have options to set the uid and gid of a translator if you have the authority, but by no means should the default ones be the same as the underlying node. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Passive versus active translators
Neal H Walfield wrote: > > > > I do not see how this makes sense. I see how it is logical, however, it > > > is misleading. Consider the following: > > > > > > # settrans -cap ~/foo /hurd/isofs cdimage > > > > > > The active translator will start, however, once it is stopped, the > > > filesystem will to be able to restart it. In this scenario, guessing > > > from the `-ap', the user likely wants to make sure that the translator > > > is setup and correctly and then wants to forget about it. > > > > You're confusing the behavior of settrans with mount. If you do: > > My argument is that this will work when setting the active translator, > however, it will not work with a passive translator. Why? Only because > of the current working directory -- this has nothing to do with parsing > the arguments to the translator. Your argument rests on the fact that you want settrans and passive translators to behave the same. I want settrans to be equivalent to launching a program and a passive translator to be equivalent to an automatic daemon starting up. With settrans you can lauch a translator and have it's cwd be your cwd. You can achieve the effect of a passive translator startup with: # cd ~; settrans -cap ~/foo /hurd/isofs cdimage; cd $OLDPWD But if you make the default behavior to do this automatically you would not be able to do some things that you could before. Like: # cd ~; settrans -ca stuff/foo /hurd/logging_translator --logfile=foo.log > > > Not true; make settrans suid root. > > > > This would open up a whole flood of security risks. > > If the filesystem already has root privleges then no; you have the same > problems setting the passive translator. Refresh my memory, is a user with read only access to a file able to set up an active translator on that node? > > but by no means should the default ones be > > the same as the underlying node. > > This is how a passive translator works. I still think there might be security risks involved. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: glibc/io/fts.c, MAXPATHLEN issue
On Fri, Jun 29, 2001 at 03:49:01PM -0500, Marcus Brinkmann wrote: > Hi, > > io/fts.c has a MAXPATHLEN issue. > The Debian glibc build of 2.2.3-6 (CVS 6-9-2001) fails because > of that. > > Sorry, no more info as I can't send mail from my local machine > right now. This is the relevant code snipet from the source of 2.2.3-5: /* * Start out with 1K of path space, and enough, in any case, * to hold the user's paths. */ #ifndef MAXPATHLEN #define MAXPATHLEN 1024 #endif if (fts_palloc(sp, MAX(fts_maxarglen(argv), MAXPATHLEN))) goto mem1; First of all this shouldn't fail whether MAXPATHLEN is defined or not. I think the macro is misnamed, from the code it looks like it should be called MINPATHLEN. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Serial console and gnumach/oskit-mach
Hi, I've been trying setup hurd on my second PC (which is not easy because it doen't have a separate monitor, keyboard or a network card that works with gnumach). I've worked out all the problems with the serial connection. But when I tried to look for documentation on how to set up gnumach/oskit-mach with a serial console, I was surprised by the lack thereof. I've managed to find out that GNUmach does not support serial console. Oskit-mach supports serial console, and even debugging over it, but there is next to no documentation on how to set it up. Roland mentioned that there are some explanations in the oskit docs, but I've only found information on how to add serial console debugging to a kernel (I assume that has already been done for oskit-mach). So what are the command line options for oskit-mach to turn on these features? Roland also mentioned that the oskit distribution contains example kernels with gdb serial debugging support. I guess they weren't clearly labeled, which ones are they? Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
failure notice
Hi, I've started fixing up the thread creation stuff in pthreads, and I've come upon a dilema. According to SUSv2, the programmer is allowed to create a thread with specified stack location and size. If that information is not provided, then a stack of some default size is allocated with an extra page at the end of the stack to create a "red zone" to detect overflows. How is it possible to create a "red zone" if the stack has already been allocated by the programmer. It is not garanteed that we can snag a page of memory located contiguously after the provided stack space. And we can't take off the last page from the user provided stack because he's garanteed at least the provided stack size. In this case, should the creation of the "red zone" be the programmer's responsibility, or is there a way to create it with the library? It is also possible that I'm misinterpreting the standard, if so, please let me know. Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: failure notice (bad subject)
The above is a misnamed subject, ignore it. It should read Subject: Thread creation and stack allocation ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Thread creation and stack allocation
On Sun, Jul 01, 2001 at 08:27:17PM -0400, Igor Khavkine wrote:
>
> In this case, should the creation of the "red zone" be the programmer's
> responsibility, or is there a way to create it with the library?
>
> It is also possible that I'm misinterpreting the standard, if so, please
> let me know.
I've looked further in the standard and found the functions
pthread_attr_{get,set}guardsize(). These control the size of the
"red zone" or guard zone at the end of the stack. However the
documentation is moot and does not specify whether the guard area
is part of STACKSIZE set by the user with ptread_attr_{get,set}stacksize().
Clarifications, are more then welcome.
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Conflict between glibc and Mach headers
Glibc has a header which goes into /usr/include/mach_init.h and Mach has a header which goes into /usr/include/mach/vm_param.h. Both of them define the macros `round_page' and `trunc_page'. The former in terms of the variable `__vm_page_size' and the latter in terms of the constant macro `PAGE_SIZE'. Was it intended for these headers not to be used together? And why is there a variable for the page size, is it not a constant which can be known at compile time? Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: a recursive lock prototype
On Thu, Jul 05, 2001 at 10:51:21AM -0500, Marcus Brinkmann wrote:
> On Wed, Jul 04, 2001 at 06:13:23PM -0700, Thomas Bushnell, BSG wrote:
> >
> > Maybe I missed something, but what specifically is this for?
>
> You are missing out the LSM, a great event. Many greetings from Bordeaux!
>
> Moshe asked about recursive locks today, which we don?t have. He said
> it is easy to implement them ("five minutes"), but it turned out to take
> a bit longer when doing it right :)
>
> The C library needs recursive locks for the dynamic linker (loading object
> files at run time), and they might be quite useful in libraries, too
> (for better modularization).
Ideally, all the locking semantics would be implemented by the
system thread library. Right now for Hurd, that is cthreads,
and I assume your implementation is designed for that library.
The pthreads library has recursive locks in its specification. I
have implemented that feature in the pthreads code that I'm
working on right now. You're all welcome to examin it by going
to http://sf.net/project/hurd and from the CVS repository
look at pthreads/libc/pthread/pt-mutex.h. Any comments and
especially critiques are welcome.
The state of the code is the most of the functionality is already
implemented, except for the part of the thread instantiation code
that deals with signals. I'm once again, faced with a lack of
documentation reguarding `hurd_sigstate' and friends. I don't mind
reading the relevant bits of code (from glibc? hurd?). But I'm
not sure where to start.
The next state after that is to deal with global initialization (the
part that runs before main) and testing.
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Signals, messages and exceptions
I've been looking through the glibc code that handles signals for Hurd. At the same time I'm writing up a some docs on that so someone else won't have to do it again. What I'm surprised by is that signals are passed between processes using simple RPC messages. Mach has an exception facility for threads and tasks, so I thought that exceptions would be mapped to signals and vice versa. If a thread receives an exception, it is mapped to a signal. But this seems really strange, why have two ways of getting signals? It just duplicates the amount of code that needs to handle them. Both ways require a system call, so one is not more efficient then the other. The only reason I can see is that exceptions do not map directly to signals, but that's a very weak argument. Maybe it's one of those things that was done very long ago, no-one knows why, and no-one wants to change it? Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Signals, messages and exceptions
On Sat, Jul 07, 2001 at 02:57:09PM -0400, Roland McGrath wrote: > I think you are confused about what Mach exceptions are. This is also possible. The Mach kernel interfaces docs are a bit thin on the subject. Could you enlighten me? Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Signals, messages and exceptions
On Sat, Jul 07, 2001 at 05:40:03PM -0400, Roland McGrath wrote: > Yes, sorry for the short response. That was before the coffee. > > I don't really know how to answer your message, since it wasn't quite clear > what the question was. Were you suggesting that Hurd signals should work > by sending exception_raise messages to task or thread exception ports? Yes, that is what I was getting at. Signals and interrupts are a very old concept, and I've always thought that exceptions are a more evolved version of the same concept. So it would make sense to use a more versatile feature to implement a less versatile one, if they are of similar nature. You suggested, that I was confused about the purpose of exceptions in Mach. Maybe I am, what is your take on this topic? Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Signals, messages and exceptions
On Sat, Jul 07, 2001 at 09:04:56PM -0400, Roland McGrath wrote: > > Yes, that is what I was getting at. Signals and interrupts are > > a very old concept, and I've always thought that exceptions are > > a more evolved version of the same concept. So it would make > > sense to use a more versatile feature to implement a less versatile > > one, if they are of similar nature. > > Uh, you are pretty lost in the vague here. :-) You'll do better with me if > you just talk about specific technical parallels and what precisely it > would look like if it were different. > > > You suggested, that I was confused about the purpose of exceptions > > in Mach. Maybe I am, what is your take on this topic? > > The purpose of the microkernel is to provide interfaces to the basic > functions of the machine. In Mach, most (nearly all) interfaces are in the > form of some kind of RPC. The exception_raise RPC is the kernel's > interface for delivering machine traps. Weren't signals designed to do the same thing at the beginning? (SIGHUP, SIGFPE, SIGSEGV, SIGILL all correspond to machine interrupts.) UNIX type signals are very few in number (only 32) and can only be sent to a process, which back in the old days was the basic unit of execution. Nowadays we have threads, and Mach's exceptions perform the same task as signals were intended to. But exceptions are handled on a per thread (or per taks) basis and allow a much wider range of messages by specifying exception type (including EXC_SOFTWARE for software generated exceptions), code and subcode. The pthreads library allows for per-thread signals with `pthread_kill()', so this can be handled in a uniform fashion. I'm still not on very strong footing here. But here's what I think is happening now when a process receives a signal is: ++ kill()RPC call | +---+ +---+ | proc1 | > --> | | handle signal | --> | proc2 | ++ | +---+ +---+ | ^ ++exception RPC | +-|-+ | kernel | > | | translate | ++ (from hardware) | | to signo | | +---+ This way there are two different ways that signals can arise, and they are treated differently until the very end. And this way the exception mechanism becomes unusable for anything other then sending signals. The scheme that I'm thinking of would look more like this: ++ exception_raise() | | proc1 | --+| +-+ yes ++ ++ || | corresponds | -> | handle | +--> | | to signal ? || signal | ++exception RPC || +-|---++-|--+ | kernel | --+|no | ++ v ++ (from hardware) | +---> | custom |+---+ | | handle | -> | proc2 | | +++---+ As you can see, both approaches result in one system call to convey the message to the target process. But in the second scheme unifies the two ways that signals can arise (as I think they should be) and also opens up the exception mechanism to the application, if UNIX type signals do not provide enough versatility. When I look through code, I not only want to know how it works, but also why it was designed a certain way. This is why these questions came up when I was reading the Hurd signal handling code. Has the second approach been considered during the initial design stage and simply thrown away for valid reasons, or has it just not come up? Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
More on oskit-mach and serial debugging
I've successfuly setup my second box with a serial line as a console and debugging line. I tried booting oskit-mach (from cvs) on it and it failed with a segfault in one of the oskit drivers. I discovered that when I tried to boot oskit-mach linked with oskit which were both compiled with debug symbols. The problem is the tulip driver, it's strange because it works when I boot linux with the same driver on the same box. I'll try to investigate and see where exactly the problem lies. But I'd like to know about the capabilities of serial debugging. For example I wasn't able to step through the code line by line or instruction by instruction. I always got the message "Skipping to the end of function , since it contains no line number information". This is strange because I did compile everything with -g. So is it possible to step through the code line by line? Also is it possible to examine the contents of local variables? Also, pardon my ignorance :-) but what's the command to log a GDB session to a file? Thanks. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit-mach
On Mon, Jul 09, 2001 at 10:10:42PM +0200, Jeroen Dekkers wrote: > I tried old version of both oskit-mach and oskit (Jeff suggested me that on > irc), oskit-mach works almost with version 2505 and with version 2901 > I get IRQ probing problems. Oskit-mach linked with oskit-2505 doesn't > understand root=hd0s11, if I try root=hda5 serverboots it says the following: > "Can't open server boot script /dev/hda11/boot/server.boot : Inappropriate > file type or format." I checked out oskit-mach from CVS and linked it with oskit-0.97.20010214 that I got from the debian archive. It boots and seems to work. It recoginses everything and even gets to starting up the system servers. However it panics somewhere inside the Linux tulip-driver. > I've got 2 bugfixes for oskit-mach too. The first doesn't set the flag > DC_NO_ONLCR for the console, because it only fucks up the console output. > There should be a carriage return when you have a newline. The second removes > a page fault error in oskit_linux_dev_init at address 0x104 (to get > information from the bios I guess). trunc_page(subcode) returns 0 when the > address is smaller than PAGE_MASK (0xfff) and generates a panic. I don't know > what the idea about that check is, but it works when I remove it. I've always supposed that Roland didn't include the DC_NO_ONLCR flag on purpose, if not I hope he accepts your patch. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
More on oskit-mach debugging
Hi, all.
After a bit more of oskit-mach debugging I've had some partial success.
My network card is now working with the OSKit driver. All I had to
do is change the [oskit]/linux/src/drivers/net/tulip.c file to a newer
version. Since I knew my card was working with linux-2.2.19, I just took
the driver from there.
Now if I was still linking with the version of oskit in the Hurd archives
all my problems would be solved and I would be able to boot properly.
However, I have compiled my own version of OSKit to get debigging
symbols. Now I get a SIGSEVG during initialization in the OSKit
function `oskit_linux_dev_init () at [oskit]/linux/dev/init.c:81',
on line:
129 x = *((unsigned *)(kaddr + 0x104));
Here `kaddr' has value 0x0 and the calculated address 0x104 is not
accessibl, hence the SIGSEGV. Lets see how `kaddr' gets its
value:
127 if (osenv_mem_map_phys(0, PAGE_SIZE, &kaddr, 0))
128 panic("%s:%d: unable to map phys memory", __FILE__, __LINE__);
Once all the functions are followed through and all macros expanded,
the result comes down to the following:
kaddr = phystokv(0) = 0 + phys_mem_va
And at the moment the value of phys_mem_va is also 0x0, hence `kaddr = 0x0'.
My question is, when during oskit-mach's initialization does the paging
turn on, and why isn't phys_mem_va set to the correct value?
Thanks.
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: More on oskit-mach debugging
Jeroen Dekkers wrote:
>
> On Fri, Jul 13, 2001 at 09:21:57AM -0400, Igor Khavkine wrote:
> > Now if I was still linking with the version of oskit in the Hurd archives
> > all my problems would be solved and I would be able to boot properly.
> > However, I have compiled my own version of OSKit to get debigging
> > symbols. Now I get a SIGSEVG during initialization in the OSKit
> > function `oskit_linux_dev_init () at [oskit]/linux/dev/init.c:81',
> > on line:
> >
> > 129 x = *((unsigned *)(kaddr + 0x104));
> >
> > Here `kaddr' has value 0x0 and the calculated address 0x104 is not
> > accessibl, hence the SIGSEGV. Lets see how `kaddr' gets its
> > value:
> >
> > 127 if (osenv_mem_map_phys(0, PAGE_SIZE, &kaddr, 0))
> > 128 panic("%s:%d: unable to map phys memory", __FILE__, __LINE__);
> >
> > Once all the functions are followed through and all macros expanded,
> > the result comes down to the following:
> >
> > kaddr = phystokv(0) = 0 + phys_mem_va
> >
> > And at the moment the value of phys_mem_va is also 0x0, hence `kaddr = 0x0'.
> >
> > My question is, when during oskit-mach's initialization does the paging
> > turn on, and why isn't phys_mem_va set to the correct value?
> >
>
> There was my previous trap.c patch about (see that mail for the patch). First
> I thought the same thing as you, but in gnumach and the example kernels
> phys_mem_va is also set to 0.
>
> When I looked further, I ended in the page fault handling code. If
> trunc_page(subcode) == 0, the kernel panics. After macro expansion that means
> if subcode (the value of the address) is smaller than the page size,
> trunc_page(subcode) is 0 and thus gives a panic.
I've found your mail and see that you've reported this already.
> Because 0x104 is smaller than PAGE_SIZE (0xfff iirc), the kernel page faults.
> I just removed the check and everythings works ok. Well, oskit-mach still
> doesn't work, but I get the same as with the debian packges. The fact that
> this problem only occurs when you built the oskit yourself is that with the
> debian package oskit_linux_dev_init is never called afaik, I don't know why.
I think the reason, for the check trunc_page(subcode) == 0 is to guard against
NULL pointer references. Usually in user processes the 0th page is protected
in such a way as to produce a SIGSEGV instead of letting the user overwrite
memory at that location. But inside the kernel, this might be a little trickier.
Myabe if the the kernel is mapped starting at the 1st page
(phys_mem_va = PAGE_SIZE) then it would work without your change.
I'd still like to know when/where exactly is the paging table and phys_mem_va
are set up in the code.
> I'm almost finished hacking remote debugging support with ethernet. If it
> works I will post it here, but it's only a dirty hack. Anyway you can also
> contact me on #hurd at openprojects, my nickname is F399.
As you might have guessed, my nick is \Igor\, see you there.
Igor
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Building OSKit-Mach (texinfo format) - dead link w/patch
On Tue, Oct 09, 2001 at 02:52:27PM -0400, Roland McGrath wrote: > I would recommend you use the hurd sourceforge project, store documents > there, and use that as a canonical web site to refer to. I suggest this > because it's something that volunteers can do without "official GNU" help. > I'm also happy to put things on the www.gnu.org site, but with sourceforge > the lot of you can just update it yourselves. Ok, I've moved the document to http://hurd.sf.net/docs/oskit-boot.txt. That's the only other publically accessible site I have access to. There's not link to it from the front page, I'm not sure how to make one unobtrusively. Maybe it'd be a better idea for one of the documentation sites to give it a home (hurddocs.sf.net maybe?). Sorry for any inconvenience. Igor ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
FROM MRS KATARINA IGOR
FROM MRS KATARINA IGOR EMAILS: [EMAIL PROTECTED] Dear RE: YOUR ASSISTANCE IS HIGHLY NEEDED I am very sure that this mail will bring lots of surprises and curiosity to you since there was no previous correspondence before now between us.I am the widow of one of the top rulers in Chechnya, My husband died along side with the Chenchan president who was killed in a bomb attack early this year in a parade ground. My husband told me before his death that he has a deposit of $28.8m which he deposited overseas and handed to me all the documents which my lawyer has confirmed with the bank. Right now I am looking for an Investor who will help me to invest the total sum in the west and after which I will relocate to your country.The security situation in Chechnya does not warrant me to do much from here; therefore I have designated my family lawyers who will co ordinate every aspect of the fund transfer and the investment with your assistance. I am ready to concede up to 25% of the funds to you as your share if you will help me to pull the funds and invest it in your country which has a stable economy. Upon receipt of your acceptance letter to my private mail box quoted above, I will introduce you to my family lawyer for details on how the transfer can be done in the shortest possible time. Awaiting your Urgent response via MY DIRECT EMAIL ADDRESS stated BELOW. [EMAIL PROTECTED] Regards MRS. KATARINA IGOR ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
