I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
to see what's required for IP-Filter (hoping for a clean interface)
and the response is "sigh". The old ipfw mechanism needs to be
abandoned, IMHO.
For those that aren't aware, pfil(9) in NetBSD used to provide two
lists
Hi ...
I want to read the status register of the lpt port in NIBBLE mode. I want to
do this wether there is a printer connected or not.
What would be the best way to accomplish this ??
Should I use the ppi0 device with the PPIGSTATUS ioctl call, because
if there is no printer connected I
I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
to see what's required for IP-Filter (hoping for a clean interface)
and the response is "sigh". The old ipfw mechanism needs to be
abandoned, IMHO.
can you comment a bit more ? I am a bit unclear on what
exactly is thay
In some mail from Luigi Rizzo, sie said:
I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6,
to see what's required for IP-Filter (hoping for a clean interface)
and the response is "sigh". The old ipfw mechanism needs to be
abandoned, IMHO.
can you comment a bit
The issue of one vs. multiple lists (per direction, interface,
protocol, you name it) has been discussed some time ago. For sure
multiple lists are a (minor, given that we can start the ipfw lists
with a few of "skipto") performance improvement over a single one,
at the possible price
In some mail from Luigi Rizzo, sie said:
The issue of one vs. multiple lists (per direction, interface,
protocol, you name it) has been discussed some time ago. For sure
multiple lists are a (minor, given that we can start the ipfw lists
with a few of "skipto") performance
Changing routing information is not a problem. For starters,
with inbound packets, there is none.
for outbound there is, and one of the biggest problems i had
with dummynet (as an example) was that some code passed
around route structures held in the stack, so you couldn't just keep
a
- Original Message -
From: "Wes Peters" [EMAIL PROTECTED]
To: "Jon Hamilton" [EMAIL PROTECTED]
Cc: "Lyndon Nerenberg" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, February 19, 2000 1:14 AM
Subject: Re: Crypto progress! (And a Bg TODO list)
And how exactly are they supposed
Thus spake Jason Allum ([EMAIL PROTECTED]):
It seems Jose Gabriel Marcelino wrote:
Well, rebuild the loader, that helped Bryan, apparently it has
nothing to do with the ata driver
i've had no troubles on my ata-based dell precision 410, running -current
(circa -11pm last night).
my bad!
those were meant for -current... sorry for the mis-post.
- jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Firstly, the cross-post to -hackers seems appropriate but
my apologies if it isn't.
I am now certain that there is a bug in ioctl() (at least for
setting the mixer).
This started out as an attempt to fix a bug in xmms, but making a
debug version of mixer(8) showed it to be affected the same
On Fri, 18 Feb 2000, Bruce Gingery wrote:
So I'll leave it up to you. There should be info at least in
a FAQ somewhere that indicates that bad RAM is not something
that can be ruled out until tested adequately, and perhaps a
checklist of symptoms that (virtually) ALWAYS
:Madhu Talluri's paper on page tables for 64 bit address spaces claims that
:having collision chains is expensive - for 8 bytes of mapping information,
:the pointer and tag storage overhead is 16 bytes.
:
:Though page table space is important, in the age of big memory computers,
:I think
:Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
:and it turns out that hash tables perform quite poorly. I'd suggest GPTs
:instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
:Both have the advantage of supporting multiple page sizes that
In some mail from Luigi Rizzo, sie said:
Changing routing information is not a problem. For starters,
with inbound packets, there is none.
for outbound there is, and one of the biggest problems i had
with dummynet (as an example) was that some code passed
around route structures held
:Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
:and it turns out that hash tables perform quite poorly. I'd suggest GPTs
:instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
:Both have the advantage of supporting multiple page sizes
Chuck Robey wrote:
On Fri, 18 Feb 2000, Bruce Gingery wrote:
So I'll leave it up to you. There should be info at least in
a FAQ somewhere that indicates that bad RAM is not something
that can be ruled out until tested adequately, and perhaps a
checklist of symptoms
On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote:
It looks like the hardware has to implement GPTs and know how to
walk them. How can FreeBSD use them without hardware support ?
No it doesn't. We've got software GPT implementations for both MIPS64 and
Alpha, and they're
On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote:
It looks like the hardware has to implement GPTs and know how to
walk them. How can FreeBSD use them without hardware support ?
No it doesn't. We've got software GPT implementations for both MIPS64 and
Alpha, and
:And don't forget that with VHPT you'll be getting nested TLB faults quite
:frequently in a sparsely-populated page table (think shared libraries).
:
:Efficiency-wise, Kevin has shown that you only need a fairly small VPHT, and
:it is global, so you ammortise the cost across all running tasks.
20 matches
Mail list logo
