Re: crypto(9) choose another driver if we cannot open a session on it

Le Wed, 10 Dec 2008 14:50:51 -0800, Sam Leffler a écrit : Hello, > > Which code exactly? Yes I'm curious :-) > > > > I'm thinking about how to remove the need for a device to support > > all the algorithms when we open a session. By using a fake "crypto > > virtual device" to open and dispatch c

Re: Strange "changed paths" in svn commits

On Fri, Dec 12, 2008 at 08:21:25AM -0800, Tim Kientzle wrote: > Rick C. Petty wrote: > >On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > > > >I suspect you've run into a well-known svn bug that affects "svn merge". I > >thought they had fixed it with subversion 1.5.4, but apparently

Re: preventing FIFO from EOF

BTW, buffer was written way back when memory was measured in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and its effectivness is questionable :-) My scenario: prog1 | prog2 where both are daemons. prog1 does all the work, and sends commands for prog2 to do when needed

Re: preventing FIFO from EOF

Christoph Mallon wrote: rihad schrieb: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need

Re: preventing FIFO from EOF

Christoph Mallon wrote: rihad schrieb: Something as simple as this: $ sh < /dev/null > /var/tmp/kick 2>/dev/null seems to block indefinitely, but exits as soon as I run $ buffer -i /var/tmp/foo (and buffer exits too) Strangely enough, something as stupid as this does the trick: sh < /dev/st

Re: preventing FIFO from EOF

Danny Braniss wrote: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one du

Re: preventing FIFO from EOF

Danny Braniss wrote: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one du

Re: preventing FIFO from EOF

> > BTW, buffer was written way back when memory was measured > > in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and > > its effectivness is questionable :-) > > > My scenario: > > prog1 | prog2 > > where both are daemons. prog1 does all the work, and sends commands for

Re: Strange "changed paths" in svn commits

Rick C. Petty wrote: On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: I suspect you've run into a well-known svn bug that affects "svn merge". I thought they had fixed it with subversion 1.5.4, but apparently it's still around. When doing a merge, it seems to randomly touch a bunch

Re: preventing FIFO from EOF

> Danny Braniss wrote: > >> $ mkfifo /var/tmp/foo > >> $ buffer -i /var/tmp/foo# misc/buffer > >> # in another console: > >> $ echo hi > /var/tmp/foo > >> > >> buffer prints hi and exits. I want it to keep reading and printing > >> indefinitely. > >> > >> Further experimentatio

Re: Strange "changed paths" in svn commits

On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote: > Hi, > > Is it how merging works or I'm missing something? I suspect you've run into a well-known svn bug that affects "svn merge". I thought they had fixed it with subversion 1.5.4, but apparently it's still around. When doing a mer

Re: NFS (& amd?) dysfunction descending a hierarchy

On Fri, Dec 12, 2008 at 03:41:29PM +0200, Kostik Belousov wrote: > ... > > * At 1229033597.287187 it issues an fstatfs() against FD 4; the > > unsuccessful return is at 1229033597.287195, claiming ENOENT. > > > > Say WHAT??!? > ... > > But is this error transient or permanent ? I.e., would rest

Re: preventing FIFO from EOF

rihad schrieb: $ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy w

Re: NFS (& amd?) dysfunction descending a hierarchy

On Thu, Dec 11, 2008 at 02:53:49PM -0800, David Wolfskill wrote: > On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote: > > ... > > > What concerns me is that even if the attempted unmount gets EBUSY, the > > > user-level process descending the directory hierarchy is getting ENOENT > >

Re: preventing FIFO from EOF

> $ mkfifo /var/tmp/foo > $ buffer -i /var/tmp/foo# misc/buffer > # in another console: > $ echo hi > /var/tmp/foo > > buffer prints hi and exits. I want it to keep reading and printing > indefinitely. > > Further experimentation revealed that I need two writers: one dummy >

preventing FIFO from EOF

$ mkfifo /var/tmp/foo $ buffer -i /var/tmp/foo# misc/buffer # in another console: $ echo hi > /var/tmp/foo buffer prints hi and exits. I want it to keep reading and printing indefinitely. Further experimentation revealed that I need two writers: one dummy writer that just

Strange "changed paths" in svn commits

Hi, Is it how merging works or I'm missing something? Why /stable/7/sys and /stable/7/sys/contrib/pf are in changed paths in commit r185814? Starting from 2008 Aug they appear in almost all commits to stable/7. # svn log -v svn://svn.freebsd.org/base/stable/7 -r185814 Changed paths: M /stab

Re: memtest86+ can not link: binutils issue?

on 31/10/2008 15:18 Andriy Gapon said the following: >>> ld --warn-constructors --warn-common -static -T memtest_shared.lds \ >>>-o memtest_shared head.o reloc.o main.o test.o init.o lib.o >>> patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o >>> random.o extra.o spd.