On Sun, Aug 12, 2012 at 11:34 PM, Ingo Schwarze wrote:
> Hi Ted,
>
> Ted Unangst wrote on Tue, Jul 24, 2012 at 08:57:59PM -0400:
>
>> The vmwh package is very handy, but somewhat hard to discover.
>> Can we add a little hint to the man page for vmt?
>
> I know very little about VMWare, but from th
On Mon, Aug 13, 2012 at 03:02:22AM +0200, Alexander Hall wrote:
> On 08/06/12 22:56, Christiano F. Haesbaert wrote:
> >Please ignore the other thread, it takes ages for me to open my sent box
> >over gprs, so I'm opening a new one.
> >
> >
> >Index: fetch.c
> >==
I think I've hunt this down
http://tools.ietf.org/html/rfc3986#section-3.3
If you follow the BNF for path, you have.
path -> path->absolute -> segment-nz -> 1*pchar -> \
unreserved / pct-encoded / sub-delims / ':' / '@'.
So it seems "everything" is allowed on path, I'll fix the diff.
On Mon, Aug 13, 2012 at 4:24 PM, Stefan Fritsch wrote:
> - virtio: use lfence/sfence because __sync_synchronize() is broken
> on gcc < 4.4
please don't. use bus_space_barrier.
On Mon, Aug 13, 2012 at 09:07:52AM +0200, David Coppa wrote:
> On Sun, Aug 12, 2012 at 11:34 PM, Ingo Schwarze wrote:
> > Hi Ted,
> >
> > Ted Unangst wrote on Tue, Jul 24, 2012 at 08:57:59PM -0400:
> >
> >> The vmwh package is very handy, but somewhat hard to discover.
> >> Can we add a little hin
On Mon, Aug 13, 2012 at 4:24 PM, Stefan Fritsch wrote:
> Hi,
>
> here is the next iteration of my patch.
>
> Changes from V4 include:
>
> - virtio: support RING_EVENT_IDX
> - virtio: use lfence/sfence because __sync_synchronize() is broken
> on gcc < 4.4
> - net: rework memory ha
On 2012/08/13 10:51, Lawrence Teo wrote:
>
> OK for me as well; I prefer the version that spells out the port
> name as "sysutils/vmwh"
We direct users towards packages not ports.
On Mon, Aug 13, 2012 at 04:06:28PM +0100, Stuart Henderson wrote:
> On 2012/08/13 10:51, Lawrence Teo wrote:
> >
> > OK for me as well; I prefer the version that spells out the port
> > name as "sysutils/vmwh"
>
> We direct users towards packages not ports.
Good point.. thank you, I need to reme
On Monday 13 August 2012 17:07:41 you wrote:
> > * Note: the i386 does not currently require barriers, but we must
> > * provide the flags to MI code.
> >
> > This is not correct for virtio. We need a memory barrier.
>
> sure, copy it from amd64.
OK. A slight complication:
sfence/mfence/lfence
On Mon, Aug 13, 2012 at 5:30 PM, Stefan Fritsch wrote:
> On Monday 13 August 2012 17:07:41 you wrote:
>> > * Note: the i386 does not currently require barriers, but we must
>> > * provide the flags to MI code.
>> >
>> > This is not correct for virtio. We need a memory barrier.
>>
>> sure, copy i
On Mon, Aug 13, 2012 at 04:33:40PM +0200, Christiano F. Haesbaert wrote:
> I think I've hunt this down
>
> http://tools.ietf.org/html/rfc3986#section-3.3
>
> If you follow the BNF for path, you have.
>
> path -> path->absolute -> segment-nz -> 1*pchar -> \
> unreserved / pct-encoded / sub
On Mon, Aug 13, 2012 at 5:36 PM, Mike Belopuhov wrote:
> On Mon, Aug 13, 2012 at 5:30 PM, Stefan Fritsch
> wrote:
>> On Monday 13 August 2012 17:07:41 you wrote:
>>> > * Note: the i386 does not currently require barriers, but we must
>>> > * provide the flags to MI code.
>>> >
>>> > This is no
On Mon, Aug 13, 2012 at 5:41 PM, Mike Belopuhov wrote:
> On Mon, Aug 13, 2012 at 5:36 PM, Mike Belopuhov wrote:
>> On Mon, Aug 13, 2012 at 5:30 PM, Stefan Fritsch
>> wrote:
>>> On Monday 13 August 2012 17:07:41 you wrote:
> * Note: the i386 does not currently require barriers, but we must
Si no podes visualizar este mail, ingresa a:
http://news1.bonuscupon.com.ar/r.html?uid=1.2r.295h.1ab.u6nmp66iff
On 08/13/12 17:37, Christiano F. Haesbaert wrote:
On Mon, Aug 13, 2012 at 04:33:40PM +0200, Christiano F. Haesbaert wrote:
I think I've hunt this down
http://tools.ietf.org/html/rfc3986#section-3.3
If you follow the BNF for path, you have.
path -> path->absolute -> segment-nz -> 1*pchar -> \
Final version, better allocation arith.
ok ?
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.105
diff -d -u -p -r1.105 fetch.c
--- fetch.c 30 Apr 2012 13:41:26 - 1.105
+++ fetch.c 13
> From: Stefan Fritsch
> Date: Mon, 13 Aug 2012 16:24:15 +0200
>
> Hi,
>
> here is the next iteration of my patch.
>
> Changes from V4 include:
>
> - virtio: support RING_EVENT_IDX
> - virtio: use lfence/sfence because __sync_synchronize() is broken
> on gcc < 4.4
Broken how?
since I'm here already...
ok ?
Index: Makefile
===
RCS file: /cvs/src/usr.bin/ftp/Makefile,v
retrieving revision 1.25
diff -d -u -p -r1.25 Makefile
--- Makefile5 May 2009 19:35:30 - 1.25
+++ Makefile13 Aug 2012 15:
While I recognize there's some precedence in the tree for it already,
this seems ugly to me. Is there a reason different programs/libraries
need different diagnostic flags? Why doesn't this belong in
bsd.own.mk or mk.conf?
On Mon, Aug 13, 2012 at 12:34:37PM -0700, Matthew Dempsky wrote:
> While I recognize there's some precedence in the tree for it already,
> this seems ugly to me. Is there a reason different programs/libraries
> need different diagnostic flags? Why doesn't this belong in
> bsd.own.mk or mk.conf?
this makes mfi(4) print details about itself like mfii(4) does.
instead of:
instead of this:
mfi0 at pci10 dev 14 function 0 "Dell PERC 5" rev 0x00: apic 10 int 14,
0x1f031028
mfi0: logical drives 2, version 5.2.2-0072, 256MB RAM
scsibus0 at mfi0: 2 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3 0
The em(4) driver does not actually utilize the loop count
paramter for em_rxeof() so just remove it.
Index: if_em.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.264
diff -u -p -r1.264 if_em.c
--- if_em.c
22 matches
Mail list logo