Re: licensing of intloop() in libddekit/interrupt.c

Hello Robert, Sure, I have no problem with the license. Best, Da On Sun, Nov 8, 2015 at 2:35 PM, Robert Millan wrote: > Hi! > > El 08/11/15 a les 20:12, Da Zheng ha escrit: >> Sorry for disappearing for years. > > Never mind, nice hearing from you :-) > >> Is t

Re: licensing of intloop() in libddekit/interrupt.c

Sorry for disappearing for years. Is there anything I can do for you? Best, Da On Sat, Nov 7, 2015 at 5:16 PM, Olaf Buddenhagen wrote: > Hi, > >> El 07/11/15 a les 12:11, Robert Millan ha escrit: > >> > Unfortunately I didn't get any reply from Zheng Da. Does someone >> > know if Zheng is using

Re: DDE - Commit fb489ff causes FTBFS

On 7/21/11 2:17 PM, Da Zheng wrote: > Hello, > > On 06/30/11 05:46, Samuel Thibault wrote: >>> I had been trying to build DDE packages for Arch Hurd for a while, and after >>> some discussion in #hurd, we found that in hurd/incubator.git, commit >>> fb48

Re: DDE - Commit fb489ff causes FTBFS

Hello, On 06/30/11 05:46, Samuel Thibault wrote: I had been trying to build DDE packages for Arch Hurd for a while, and after some discussion in #hurd, we found that in hurd/incubator.git, commit fb489ff7a7989b85ae4f3c1deaf5dbf816de6545 , "drop generated files", prevents building from source. I

Re: Would like to work on "Hurdish TCP/IP stack" gsoc project

Hi Sushil, I'm glad we can have more Hurd developers:) I think I can give some technical help, but I'm not sure what is the goal of the project. I forward your email to the mailing list, so we can talk together. Do you have anything in your mind? If I remember correctly, one goal of this project

Re: GNU Mach: disabling all network device drivers

Hello, It's strange. I thought the problem doesn't exist any more after I made some changes in the kernel. Are you using the latest gnumach in the master-user_level_drivers branch? Best, Zheng Da On 8/30/10 12:15 AM, Diego Nieto Cid wrote: > Hello, > > Short story: something is clearing kernel_

Re: [PATCH2/4] fully enable rpctrace to trace multitask programs.

Hi, No, I don't think so. I haven't touched this stuff for really long time. I probably don't have the time to do anything about it right now. Hopefully I can find time in the future. Sorry about that. Best, Zheng Da Sent from my iPhone On Aug 26, 2010, at 7:43 PM, Samuel Thibault wrote: >

Re: GSoC meetings

Sent from my iPhone On Aug 22, 2010, at 7:01 AM, Carl Fredrik Hammar wrote: > Hi, > > On Sun, Aug 22, 2010 at 11:18:41AM +0200, olafbuddenha...@gmx.net wrote: >> >> First of all, I'm not sure I will be able to make it to the meeting >> tomorrow. (Am at FrOSCon right now :-) ) But as usual, t

Re: sleep in microsecond or nanosecond

Hi, Should we still handle the special cases in mach_msg or in another system call? While sleeping in microseconds or nanoseconds, the kernel should do the loop on the behalf of the user process. Why do we still need a wakeup queue? Best, Zheng Da On 8/13/10 5:28 PM, Thomas Bushnell, BSG wrote:

sleep in microsecond or nanosecond

Hello, I need a program to sleep in several microseconds, but neither nanosleep() nor usleep() can work. They sleep at least 10ms. So it seems the only option is to use loop and Linux kernel does so as well for udelay() and ndelay(). Then I need high resolution timing. I think I can use TSC, but i

Re: preliminary patch for initrd support in Mach

On 10-6-14 下午3:00, olafbuddenha...@gmx.net wrote: >> or that modifying Mach for this purpose is misguided and should be >> avoided (for instance by embedding the initrd in a dedicated section >> of an elf module). > > Hm... I don't remember this variont actually being mentioned on IRC -- > but I t

Re: serious memory leak in hurd

On 10-6-13 下午6:28, Samuel Thibault wrote: > Da Zheng, le Sun 13 Jun 2010 11:54:10 +0800, a écrit : >>> It is. Are you perhaps using the old K16 qemu image? There is a bug >>> with it, you need to fix the image size >> >> No, I'm not using the qemu image. Hur

Re: serious memory leak in hurd

Hello, On 10-6-13 上午7:06, Samuel Thibault wrote: >>> Mmm, this could just be gnumach not writing back the cached data that >> Why does gnumach need to write back the data? > > Ah, sorry, you're reading the file not writing it. Anwyay, it's still > the same issue: gnumach doesn't dare dropping it.

Re: serious memory leak in hurd

On 10-6-12 下午7:58, Samuel Thibault wrote: > Hello, > > Da Zheng, le Sat 12 Jun 2010 19:46:49 +0800, a écrit : >> Here is what I did. I scp a big file from the Hurd (in the virtual machine) >> to >> the host OS. I check the memory statics with vmstat constantly. Afte

serious memory leak in hurd

Hello, I was debugging my DDE NIC driver, and found a serious memory leak. At first I thought it was caused by my modification in gnumach. Then I tried the gnumach from the debian repository and the original pfinet, and the same memory leak occurs. Here is what I did. I scp a big file from the Hu

Re: GNU Mach: disabling all network device drivers

On 10-6-9 下午2:24, Samuel Thibault wrote: > Zheng Da, le Wed 09 Jun 2010 01:22:48 -0400, a écrit : >> So which instruction triggers the trap? nop or movl? > > movl, but it's not its ofwn fault. > > My guess is that right after sti, an interrupt is triggered while nop is > being executed, gets hand

Re: state updates on porting of dde linux26

On 10-6-7 上午5:18, Thomas Schwinge wrote: > Hello! > > On Wed, May 12, 2010 at 05:37:45PM +0800, Da Zheng wrote: >> e100 doesn't work in qemu. Maybe I can find some hints by debugging it. > > I have a e100 card that needs a binary firmware blob loaded before it i

a minor bug in claim_irq

Hello, Here is a minor bug in claim_irq when ddekit_interrupt_attach fails. We should be set used_irqs properly in case ddekit_interrupt_attach fails. The fix is in the attachment. Best regards, Zheng Da diff --git a/libdde_linux26/lib/src/arch/l4/irq.c b/libdde_linux26/lib/src/arch/l4/irq.c inde

Re: state updates on porting of dde linux26

On 10-5-11 上午9:35, Da Zheng wrote: > Hello, > > I'm testing the porting of DDE Linux26 with different types of NIC drivers on > VMWare and qemu. I tested pcnet32, ne2k-pci, rtl8139, e1000. pcnet32 works in > both VMWare and qemu. Only qemu emulates ne2k-pci and rtl8139 c

Re: GNU Mach: disabling all network device drivers

On 10-5-19 下午10:42, Samuel Thibault wrote: > Zheng Da, le Thu 13 May 2010 08:59:59 -0400, a écrit : >> general protection trap. I tried several drivers and always got the >> same problem. >> The error can be seen at http://i.imagehost.org/0382/Screenshot.png. >> >> addr2line shows me 0x1076e6 is at

Re: GNU Mach: disabling all network device drivers

On 10-5-18 上午4:20, Thomas Schwinge wrote: > Hello! > > On Thu, May 13, 2010 at 08:59:59AM -0400, Zheng Da wrote: >> It is really weird. I built gnumach with --disable-device-drivers >> --enable-ide --enable-kdb. >> I boot hurd with the new kernel and run the user-level network drivers >> but got a

Re: GNU Mach: disabling all network device drivers

On 10-5-14 下午1:17, olafbuddenha...@gmx.net wrote: > Hi, > > On Thu, May 13, 2010 at 08:59:59AM -0400, Zheng Da wrote: > >> It is really weird. I built gnumach with --disable-device-drivers >> --enable-ide --enable-kdb. I boot hurd with the new kernel and run the >> user-level network drivers but

Re: GNU Mach: disabling all network device drivers

On 10-5-13 下午6:06, Samuel Thibault wrote: > Da Zheng, le Thu 13 May 2010 08:12:03 +0800, a écrit : >> qemu is extremely slow. the fewer files are compiled, the better it is >> for me. Thanks. > > I usually build in my Linux host actually. Right. I should also do that. Zheng Da

Re: GNU Mach: disabling all network device drivers

Hello, On 10-5-13 上午12:26, Thomas Schwinge wrote: > Hello! > > Adding the possibility to programmatically disable all network device > drivers into GNU Mach's configure script is possible, but it'll take a > bunch of time if done properly, or I can do it in a very, very ugly way. > Instead, can't

Re: state updates on porting of dde linux26

On 10-5-11 下午2:18, Samuel Thibault wrote: > Da Zheng, le Tue 11 May 2010 09:35:34 +0800, a écrit : >> Only qemu emulates ne2k-pci and rtl8139 cards and both DDE drivers >> work well in qemu. >> >> The odd thing occurs to e1000. VMWare and qemu both emulate e1000. D

Re: irq handling in DDE Linux26

On 10-5-12 上午6:03, Samuel Thibault wrote: > Da Zheng, le Sat 08 May 2010 23:19:08 +0800, a écrit : >> A stupid question: when disable_irq_nosync is called, IRQ_DISABLED is set in >> the >> irq descriptor in the Linux kernel and the corresponding hardirq line should >&g

Re: state updates on porting of dde linux26

On 10-5-12 上午6:14, Samuel Thibault wrote: > Hello, > > I do not have the time to try it myself, just commenting: > > Da Zheng, le Tue 11 May 2010 09:35:34 +0800, a écrit : >> Linux drivers use jiffies to measure time. Unfortunately, Mach doesn't >> provide it

state updates on porting of dde linux26

Hello, I'm testing the porting of DDE Linux26 with different types of NIC drivers on VMWare and qemu. I tested pcnet32, ne2k-pci, rtl8139, e1000. pcnet32 works in both VMWare and qemu. Only qemu emulates ne2k-pci and rtl8139 cards and both DDE drivers work well in qemu. The odd thing occurs to e1

Re: irq handling in DDE Linux26

On 10-5-7 下午4:31, Samuel Thibault wrote: > Hello, > > Da Zheng, le Fri 07 May 2010 00:53:20 +0800, a écrit : >> In ne2k-pci, an example in DDE Linux26, when a packet is transmitted by the >> driver, disable_irq_nosync_lockdep_irqsave() is called to disable irq. Then >>

Re: irq handling in DDE Linux26

On 10-5-7 上午7:51, olafbuddenha...@gmx.net wrote: > Hi, > > On Fri, May 07, 2010 at 12:53:20AM +0800, Da Zheng wrote: > >> disable_irq_nosync_lockdep_irqsave is exactly the same as >> disable_irq_nosync when there isn't CONFIG_LOCKDEP. It seems to me >> tha

irq handling in DDE Linux26

Hello, In DDE Linux26, the interrupt is ignored when an interrupt line is disabled, i.e., the handle_irq field of ddekit_irq_ctrl is 0. In ne2k-pci, an example in DDE Linux26, when a packet is transmitted by the driver, disable_irq_nosync_lockdep_irqsave() is called to disable irq. Then it trigge

Re: driver problems of Hurd in qemu

On 10-5-4 下午5:36, Samuel Thibault wrote: > Da Zheng, le Tue 04 May 2010 17:28:42 +0800, a écrit : >> Are these known problems? I didn't find any discussion on this mailing list. >> Is >> there any easy fix? > > Could you try to comment the QEMU HARDDISK line in &g

driver problems of Hurd in qemu

Hello, I ran different versions of gnumach in different versions of qemu. I got the Hurd image for qemu from http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz. The gnumach in the original image runs well in qemu v0.9.1. I built the gnumach from the master branch of the git

Re: cache coherency in DMA and MMIO

On 10-4-23 下午7:37, Samuel Thibault wrote: > Depends on how you use the mem device. It it ends up using pmap_enter() > to actually fill the page table, it will notice whether your physical > addresses are within RAM or above, see the code there. I think I find the code to do that. if (ma

Re: cache coherency in DMA and MMIO

On 10-4-24 下午6:37, Samuel Thibault wrote: >>> It does (or should do): such pointers have the __io qualifier. >> I checked the code of e1000 again. The data for MMIO is qualified by __iomem, > > Right, I hadn't checked the precise name :) > >> but the data in the transmission or receiving queues (

Re: cache coherency in DMA and MMIO

On 10-4-23 下午7:37, Samuel Thibault wrote: > Da Zheng, le Fri 23 Apr 2010 14:51:22 +0800, a écrit : >> They are not just one or two variables. They are an array of structure >> variables. Should I define all fields of the structure with volatile >> qualifier? > >

Re: cache coherency in DMA and MMIO

On 10-4-22 下午11:01, Samuel Thibault wrote: > Samuel Thibault, le Thu 22 Apr 2010 16:51:38 +0200, a écrit : >> Da Zheng, le Thu 22 Apr 2010 22:37:51 +0800, a écrit : >>> So does the driver need to consider about cache coherency problems on PC >>> when >>>

cache coherency in DMA and MMIO

Hello, I try to make e1000 work with my porting of DDE Linux26. After I tested the code, it seems the variables in the transmission queue, which are access by the device with DMA, are not changed by the device after a packet is transmitted. antrik suggested that it might be related to cache cohere

Re: too many warning messages from gnumach

Hi, On 10-3-22 上午1:09, Samuel Thibault wrote: >> I'm still not sure. The number of pageouts isn't 0 but vmstat doesn't give me >> anything about swap area. vmstat --swap-active shows me nothing. >> Is swap disabled? > > I'd tend to think so. What is pageouts? Is it not the number of pages that ar

Re: too many warning messages from gnumach

On 10-3-22 上午12:32, Samuel Thibault wrote: > Da Zheng, le Sun 21 Mar 2010 18:55:48 +0800, a écrit : >> Do I disable swap in the right way? > > You can ask vmstat whether it's really disabled. If it is, there is > probably a bug in Mach in finding argv[0]. I'm s

Re: too many warning messages from gnumach

Hi, On 10-3-17 下午8:39, Samuel Thibault wrote: > > Mmm, the command column is normally only empty if the page got swapped > out. If you disable the swap completely, there shouldn't be a problem. How do I disable swap? I thought if I don't run mach-defpager and swapon, swap is disabled. I comment t

Re: too many warning messages from gnumach

On 10-3-17 下午8:39, Samuel Thibault wrote: > Da Zheng, le Wed 17 Mar 2010 20:00:11 +0800, a écrit : >> On 10-3-17 下午6:31, Samuel Thibault wrote: >>>> After I get pid from ps, how do I map it to task ID in kdb? >>> >>> You can't, only the proc server kn

Re: too many warning messages from gnumach

On 10-3-17 下午6:31, Samuel Thibault wrote: >> After I get pid from ps, how do I map it to task ID in kdb? > > You can't, only the proc server knows that. But for the initial tasks, > you know in which order they get started, and thus their task number. so in many cases (the warning is triggered by

Re: too many warning messages from gnumach

Hi, On 10-3-17 下午5:48, Samuel Thibault wrote: >>> For the record, here are the initial tasks and their pid: >>> >>> task 0 pid 2: gnumach >>> task 1 pid 3: ext2fs >>> task 2 pid 4: exec >>> task 3 pid 1: init >>> task 4 pid 0: proc >>> task 5 pid 5: auth >>> task 6 pid 6: /bin/bash >> OK, so the t

Re: too many warning messages from gnumach

On 10-3-17 下午5:20, Samuel Thibault wrote: > Da Zheng, le Wed 17 Mar 2010 10:25:13 +0800, a écrit : >> 0: 1fef52341fef32948 0 12 >> gnumach >> 0:(...)1:(...) ... >> 1: 1fef6b241fef6b

Re: too many warning messages from gnumach

Hi, On 10-3-17 上午10:25, Da Zheng wrote: > OK, now I can invoke kdb and set the variable. After the Hurd triggers the > warning, I get to kdb and invoke 'show all thread/u", but I don't know how to > find the task that trigger the warning. There are so many tasks and thre

Re: too many warning messages from gnumach

Hi, On 10-3-16 下午8:59, Samuel Thibault wrote: > > Get the address of the mach_port_deallocate_debug variable, set it to 1 > by entering kdb and use > > w theaddress 1 > > then trigger the warning, you'll now get kdb invoked from the context. > Then you can use trace to get the backtrace, and "s

Re: too many warning messages from gnumach

Hi, On 10-3-16 下午8:59, Samuel Thibault wrote: >>> Are you using the latest libc from debian-ports? (2.10.2-6+hurd.1) >>> One important fixes got in it, and should get rid of that warning flood. >> You are right. After I upgraded libc, no warning flood any more when I use >> vim. >> I don't know i

Re: too many warning messages from gnumach

Hi, On 10-3-16 下午5:21, Samuel Thibault wrote: > Da Zheng, le Tue 16 Mar 2010 12:48:15 +0800, a écrit : >> I now use the gnumach from the master branch in the git repository for >> development. After I built and reboot my machine, I saw a few warning >> messages >>

too many warning messages from gnumach

Hello, I now use the gnumach from the master branch in the git repository for development. After I built and reboot my machine, I saw a few warning messages printed on the screen: task deallocating an invalid port xx, most probably a bug. What's worse, when I ran vim, there are too many such

Re: Cannot build gnumach

On 10-3-15 下午10:04, Thomas Schwinge wrote: > Hello! > > On Mon, Mar 15, 2010 at 09:44:39PM +0800, Da Zheng wrote: >> ../gnumach/configure --enable-kdb >> But I got an error shown in the image >> http://d.imagehost.org/view/0774/Picture_1 >> I wonder

Cannot build gnumach

Hello, I tried to build gnumach get from the git repository git://git.sv.gnu.org/hurd/gnumach.git. Then I do the following: cd gnumach autoreconf --install mkdir ../gnumach-build cd ../gnumach-build ../gnumach/configure --enable-kdb But I got an error shown in the image http://d.imagehost.org/view

Re: Late news

On 10-3-3 下午5:30, Samuel Thibault wrote: > Da Zheng, le Wed 03 Mar 2010 09:48:13 +0800, a écrit : >>> - libpciaccess backend merged upstream >> Is the bug in libpciaccess fixed? I heard X cannot work with libpciaccess or >> something like that. > > That's wha

Re: Late news

On 10-3-4 下午1:55, Arne Babenhauserheide wrote: > > Do you mean this one for DDE? > - http://lists.gnu.org/archive/html/bug-hurd/2010-02/msg00017.html For DDE, you can see a brief introduction here: http://www.bddebian.com:/~hurd-web/user/zhengda/ Zheng Da

Re: Late news

On 10-3-3 上午4:16, olafbuddenha...@gmx.net wrote: > Hi, > > On Mon, Mar 01, 2010 at 09:00:01PM +0100, Arne Babenhauserheide wrote: > >> I somehow fumbled with the date (thoght we'd have a 29th and 30th???), and >> today >> I'm to groggy to write the news, so they'll be a bit late this month. >

Re: memory leak in DMA buffers allocation?

Hi, On 10-2-13 上午3:29, olafbuddenha...@gmx.net wrote: > >> antrik said this implementation isn't consistent with Mach's memory >> management and I should make it work like device_map, so there will be >> a pager in the kernel. I basically agree with that. What should the >> interface be? any sugg

memory leak in DMA buffers allocation?

Hi, I wrote a RPC in GNUMach to allocate contiguous physical memory for DMA buffers. The code is shown as below. I have been using this function for quite a long time, but it seems it can cause some kind of memory leak. If I run the pcnet32 driver, which uses this function to allocate DMA buffers,

Re: Generalizing mobility for the Hurd

Hi, On 10-1-29 下午9:53, Carl Fredrik Hammar wrote: > Hi, > > I'm happy to announce that I have completed my thesis and presented it > at a seminar. It was even passed with distinction which is the highest > possible grade (the other two grades being passed and failed). congratulations again;-) >

Re: DDE Linux26 in the Hurd

On 10-1-29 上午12:05, Björn Döbel wrote: I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch? >>> It is DDE-based. Not very hard, you can extract libATA code from Linux >>> and need to add a few fu

Re: DDE Linux26 in the Hurd

Hi, On 10-1-28 下午10:29, Björn Döbel wrote: >> I'm sorry to ask again about the status of DDE Linux26 again. The hard disk >> driver for TUDOS is based on DDE Linux26 or you wrote it from scratch? > > It is DDE-based. Not very hard, you can extract libATA code from Linux > and need to add a few fu

Re: DDE Linux26 in the Hurd

Hi, On 10-1-28 下午9:39, Björn Döbel wrote: >> You missed my point. I understand that each driver runs in a separate >> program. >> The problem is that a device has to find the bus where it is located. In the >> current implementation, a driver can only scan 32 devices. If we have 33 >> devices >>

Re: Fwd: The status of dde linux26 in Hurd

Hi, On 10-1-28 上午12:24, Samuel Thibault wrote: > Da Zheng, le Wed 27 Jan 2010 19:17:57 +0800, a écrit : >> Next step is to develop Mach device interface on the top of dde linux26. It >> shouldn't be difficult for the network device as I have done that before. I >> should

Re: DDE Linux26 in the Hurd

Hi, On 10-1-27 下午9:54, Björn Döbel wrote: >>> The L4IO server scans all PCI devices at startup. DDE applications use >>> l4io_pci_find_device() to iterate over all the devices and assign them a >>> local/logical PCI ID. So, yes, for a DDE application it always looks >>> like there is only one PCI

Fwd: The status of dde linux26 in Hurd

sorry, send it to a wrong mailing list. Original Message Subject: The status of dde linux26 in Hurd Date: Wed, 27 Jan 2010 18:59:36 +0800 From: Da Zheng To: help-h...@gnu.org Hi, Porting dde linux26 to the Hurd works smoothly. Currently pcnet32 driver can work in it. I

Re: crosshurd

On 10-1-3 下午4:24, olafbuddenha...@gmx.net wrote: > Hi, > > On Sat, Jan 02, 2010 at 10:46:20PM +0800, Da Zheng wrote: > >> I tried crosshurd. It doesn't work. > > That's not a useful problem report... I used crosshurd again. It's working now. Strange. but very cool:) Zheng Da

Re: cannot boot subhurd

Hi, On 10-1-3 下午11:48, Thomas Schwinge wrote: > Yes: > > Of course, this problem will go away / shift from the kernel into > user-space processes as soon as we have disk I/O completely handled in > user space. > > Which, by the

Re: cannot boot subhurd

Hi, On 10-1-3 下午9:00, Samuel Thibault wrote: >> No, I didn't. The new partition isn't in the disk where Hurd runs. Do I still >> need to restart the kernel? > > Yes, fdisk says so: “WARNING: Re-reading the partition table failed > with error 1073741902: Function not implemented. The kernel still

Re: cannot boot subhurd

On 10-1-3 上午3:40, Samuel Thibault wrote: > Da Zheng, le Sat 02 Jan 2010 22:46:20 +0800, a écrit : >> Yes, I did "mke2fs /dev/hd1". After partitioning, I tried to create hd1s1 >> device >> file with MAKEDEV, but got the error "Unknown code P 6 while trying

Re: cannot boot subhurd

Hi, On 10-1-2 下午3:06, olafbuddenha...@gmx.net wrote: > But then you still have a boot sector and probably a few empty sectors > before the start of the actual partition -- I don't see how ext2fs could > ever have mounted this... > > Unless you actually did "mke2fs /dev/hd1" after partitioning --

Re: cannot boot subhurd

Hi, On 09-12-31 上午11:04, olafbuddenha...@gmx.net wrote: >> But it always worked before. I can also mount /dev/hd1 to my file >> system. 'settrans -a subhurd /hurd/ext2fs /dev/hd1' works on my >> system. > > Have you put a filesystem on /dev/hd1 without partitioning it? That's > certainly unusual.

Re: SMP, barriers, etc.

On 09-12-28 下午8:32, Samuel Thibault wrote: >> So when a write memory barrier instruction is executed, the processor >> has to remember the order of writes, so the read memory barrier >> instruction executed on another processor can somehow get the >> information? > > In principle, yes. The actual

Re: cannot boot subhurd

On 09-12-29 下午5:42, olafbuddenha...@gmx.net wrote: > Hi, > > On Mon, Dec 28, 2009 at 11:45:50PM +0800, Da Zheng wrote: > >> I tried to boot subhurd but no matter how I try it, it just fails to >> boot. > >> #boot servers.boot /dev/hd1 > > Err... /dev/

cannot boot subhurd

Hi, I tried to boot subhurd but no matter how I try it, it just fails to boot. My servers.boot is /hurd/ext2fs.static --bootflags=${boot-args} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -Tdevice ${root-device} $(task-create) $(task-resume) /li

Re: SMP, barriers, etc.

Hi, On 09-12-28 下午7:28, Samuel Thibault wrote: >>> It's not more expensive than usual operations: it already has to do it >>> to process cache line invalidations for everything that is in the cache. >> I don't understand. Do you mean processing cache line invalidation in local >> cache? > > Yes:

Re: Reauthentication implementation flaw due to EINTR

On 09-12-28 下午7:21, Samuel Thibault wrote: > Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit : >> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate) >> is to be canceled? > > No, here the auth_user_authenticate() RPC is over (else the initiator >

Re: SMP, barriers, etc.

On 09-12-28 上午11:00, Samuel Thibault wrote: > Da Zheng, le Mon 28 Dec 2009 10:31:26 +0800, a écrit : >> On 09-12-27 下午6:38, Samuel Thibault wrote: >>> Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : >>>> Is the process above correct? >>> &

Re: Reauthentication implementation flaw due to EINTR

On 09-12-28 下午6:14, Samuel Thibault wrote: > Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit : >> On 09-12-28 上午3:56, Carl Fredrik Hammar wrote: >>> >>> OK, I think I have a vague picture of what is going on: >>> ports_interrupt_self_on_port_death >

Re: Reauthentication implementation flaw due to EINTR

Hi, On 09-12-28 上午3:56, Carl Fredrik Hammar wrote: > > OK, I think I have a vague picture of what is going on: > ports_interrupt_self_on_port_death > ports_interrupt_self_on_notification > ports_interrupt_rpc_on_notification, > which requests notification (to the same port as > auth_server_authen

Re: Reauthentication implementation flaw due to EINTR

On 09-12-27 上午1:47, Carl Fredrik Hammar wrote: > > Is it the code below from S_auth_server_authenticate the problem? > > /* Store the new port and wait for the user RPC to wake us up. */ > s.passthrough = newport; > condition_init (&s.wakeup); > ports_interrupt_self_on_port_death (server

Re: Reauthentication implementation flaw due to EINTR

Hi, On 09-12-22 上午3:43, Samuel Thibault wrote: > Hello, > > I had been noticing odd issues with sudo when it calls setresuid & > such, it took me some time to understand that there was a flaw in the > reauthentication implementation: > > sudo calls setresuid(), which calls setauth(), which (for

Re: SMP, barriers, etc.

On 09-12-27 下午6:38, Samuel Thibault wrote: > Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit : >> Is the process above correct? > > I have never actually programmed the architectures where things work > like this (powerpc & such), but that's what I have und

Re: SMP, barriers, etc.

Hi, Samuel Thibault wrote: >> After I read this introduction, I checked some atomic operations >> implementation such as atomic_add_return in Linux for Aphla processors. >> Before and after these operations change the variable, they put memory >> barriers. So it's something like this: >> smp_mb

Re: review of modifications of eth-multiplexer

Hi, olafbuddenha...@gmx.net wrote: > Hi, > > On Wed, Dec 23, 2009 at 06:32:41PM +0200, Sergiu Ivanov wrote: >> On Wed, Dec 23, 2009 at 03:51:16PM +0100, olafbuddenha...@gmx.net >> wrote: > >>> These are probably all related. It's all part of the network >>> virtualization project. >> I see. The

Re: SMP, barriers, etc.

Hi, Samuel Thibault wrote: > (I've cleaned To: and subject a bit :) > > Da Zheng, le Wed 23 Dec 2009 21:23:23 +0800, a écrit : >> Samuel Thibault wrote: >>>> Is there anything else we should worry about? >>> Ordering. See /usr/src/linux/Documentatio

Re: [PATCH] Devnode: Fix the pseudo-master device port opening flags.

Hi, Sergiu Ivanov wrote: >> Maybe devnode can detect the access right of .MASTER first before it >> calls file_name_lookup(). So if the user doesn't have write access >> to .MASTER, it just makes its own node read-only. If the user want >> to change the access right of the devnode node and want to

Re: [PATCH] Devnode: Fix the pseudo-master device port opening flags.

Sergiu Ivanov wrote: > Hello, > > On Fri, Dec 25, 2009 at 05:09:40PM +0800, Da Zheng wrote: >> Sergiu Ivanov wrote: >>> - master_device = file_name_lookup (arg, 0, 0); >>> + master_device = file_name_lookup (arg, O_READ | O_WRITE, 0); >> Wh

Re: [PATCH] Devnode: Fix the pseudo-master device port opening flags.

Sergiu Ivanov wrote: > * devnode/devnode.c (parse_opt): Open the pseudo-master > devide port with O_READ | O_WRITE flags to allow subsequent > device creation. > --- > > Hello, > > Originally, devnode would open the pseudo-master device port with 0 > flags. These flags are stored by eth-multiple

Re: review of modifications of eth-multiplexer

Sergiu Ivanov wrote: > Hello, > > On Wed, Dec 23, 2009 at 03:51:16PM +0100, olafbuddenha...@gmx.net wrote: >> On Tue, Dec 22, 2009 at 11:25:51PM +0200, Sergiu Ivanov wrote: >> >>> but looking at the commit history in your hurd.git repository, I can >>> see that there are commits concerning the mul

Re: [PATCH] Add the .MASTER node to the eth-multiplexer.

Sergiu Ivanov wrote: > Hello, > > On Wed, Dec 23, 2009 at 08:52:33AM +0800, Da Zheng wrote: >> netfs_attempt_lookup locks this node and the node is unlocked by >> libnetfs, right? I forget a lot:-) So why can the second lookup not >> wait until the first one finishes

Re: What would it take....

Samuel Thibault wrote: > Good morning :) Good afternoon:-) > > Da Zheng, le Thu 24 Dec 2009 08:50:14 +0800, a écrit : >> So has network-transparent IPC been removed from microkernel or not? > > See DEVELOPMENT: > > Support for NORMA was removed on 2006-03-20. >

Re: What would it take....

olafbuddenha...@gmx.net wrote: > Hi, > > On Tue, Dec 22, 2009 at 02:31:46PM +0100, Tim Kack wrote: > >> 3. What would it take to enable SMP and/or NORMA-RPC? > > I think we actually nuked NORMA support from GNU Mach... Or at least we > discussed that. > > Doing network-transparent IPC at the mi

Re: What would it take....

Samuel Thibault wrote: >> Is there anything else we should worry about? > > Ordering. See /usr/src/linux/Documentation/memory-barriers.txt It's a long file. There are a lot to study:) > >> Then the use of volatile is very limited and the only case I can think of is >> something like signal handl

Re: What would it take....

Samuel Thibault wrote: > Samuel Thibault, le Wed 23 Dec 2009 10:26:09 +0100, a écrit : >> Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : >>>> If you use volatile, the compiler won't >>>> optimise instructions so it would "work" too ; note

Re: What would it take....

Hi, Samuel Thibault wrote: > Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : >>> If you use volatile, the compiler won't >>> optimise instructions so it would "work" too ; note however that it's >>> not SMP safe (it may even not be prem

Re: What would it take....

Hi, Samuel Thibault wrote: >> (or volatile variable + memory barrier) > > You do not need both. If you use a memory barrier, you don't need to > tell the compiler "volatile", since the memory barrier already tells it > that things may have changed. If you use volatile, the compiler won't > optimi

Re: What would it take....

Samuel Thibault wrote: > Da Zheng, le Wed 23 Dec 2009 10:21:50 +0800, a écrit : >>> Anyway, deciding between shared memory or pure IPC is not really an >>> issue. I believe the more difficult part is how to make process >>> actually perform IPCs securely. It can p

Re: What would it take....

Hi, Samuel Thibault wrote: >> Then must process-shared semaphores and mutexes be implemented in >> shared memory? or it's completely through IPCs? > > Note that posix mutexes are always shared between processus through > shared memory anyway (the application is responsible for sharing the > memor

Re: What would it take....

Hi, Samuel Thibault wrote: >> When process-shared semaphores and mutexes themselves are in the shared >> memory, can we not use the similar implementation as the ones in the same >> process? > > The implementation uses Mach messages, so it's basically the same thing. > With different tasks, you

Re: What would it take....

Samuel Thibault wrote: > Da Zheng, le Tue 22 Dec 2009 23:04:55 +0800, a écrit : >> I think we need to use process-shared mutexes, > > Or better, process-shared condition variables. I'm not talking about sleep/wakeup signaling:-) why do we need to condition variables to prot

Re: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.

Sergiu Ivanov wrote: > Hello, > > On Tue, Dec 22, 2009 at 07:40:12PM +0800, Da Zheng wrote: >> Could you tell me why initializing node status here is perferred? > > The multiplexer creates nodes on any demand, whether the client > intends to further use the node to crea

  1   2   >