without ever actually submitting one single diff to us is not
a (re)commendable supplier.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
.
Is my assumption correct?
no.
Dump reads the raw device and finds everything by hand.
Restore (like tar!) just open/write/close/chown regular files.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
.
Submissions should contain a -current version or they are likely
to never make it into the tree...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
would
be if only we all listened more to you...
To tell the truth Terry, I think more work would get done here if
we didn't have to listen so much to five-star-arm-chair generals
like you.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
QUOTA control, but it had many useful side effects as well.
I can't seem to find it right now, but it is trivial to do: just
replace the sbrk(2) with mmap(). Only downside is the needed
filedescriptor which some shells don't like.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
for you. Find RFC27xx for more info
about PPS-API.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe
for when modifying sio.c?
It's in sio.c already.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send
.
--Bart
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
.
The HotWorks from www.vcc.com can do the same, a lot cheaper
and it has a FreeBSD driver: sys/pci/xrpu.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
their collector
(if I can get my hands on it) just to see what the error rate is...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
with
it's own stack.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
In message [EMAIL PROTECTED], Dmitry S. Rzhavin writes:
Hi!
Looks like jailed processes can't use udp or icmp, but can use tcp:
RTFM.
UDP works fine. ICMP and other raw socket magic doesn't.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
the VFS-cache very much in the first
place...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send
become much more
important.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL
|involuntary context switches
-+-+---
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
significant: one out of every five I/O have
:been saved.
Notice that both the user and system times increased..
Not significantly. As I already said: they are inside the standard
deviation and therefore concluding anything from them is bogus.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
.
What ratio of files are reused as a function of them
being open or not.
What ratio of files are being reused as a function of
the number of pages they have in-core.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
These guys have 2 SCSI analyzers at $200 each:
http://www.metricsales.com/bargains.asp
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
in the kernel where VT_* macros are
[ab]used - it is Linuxlator, attached please find patches to fix it - please
review.
Sounds like a plan, and a quick eyeball of the patch shows no trouble.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
may also want to look at the musycc and if_mn drivers which
support similar cards.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
to the Netgraph node. Perhaps this
is a better alternative. I would welcome any suggestions you might have for
handling this situation. Thanks again for your help...
Andy
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andy Schweig writes:
Hello,
Software Technologies Group (http
that, but rather a descriptive string, i.e.
No actually not, I want something short and predictable like
VT_CODA.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
In message [EMAIL PROTECTED], Terry Lambert writes:
Poul-Henning Kamp wrote:
Nate,
You're replying to Terry for christs sake! What did you expect if not
revisionist $anything ?
Which reminds me, Adrian still oves us his story about ref :-)
Poul, you're going off again, without regard
.
The v_tag has been abused a few places, easily recognizable by the fact
that the kernel should never inspect the value of v_tag.
These places should be easily changeable to use the new representation.
Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment.
--
Poul-Henning Kamp | UNIX
In message [EMAIL PROTECTED], Brent Verner writes:
On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
|
| Assignment:
|
| The v_tag element in struct vnode is a debugging aid, but unfortunately
| it is implemented in a way which means that adding a filesystem means
| modifying
;
}
bzero((caddr_t)ldep, sizeof *ldep);
+ nvp-v_flag |= VLOCKABLE;
lockinit(nvp-v_lock, PINOD, denode, 0, 0);
nvp-v_vnlock = nvp-v_lock;
nvp-v_data = ldep;
--%--multipart-mixed-boundary-1.97537.999617732--%--
--
Poul-Henning Kamp | UNIX since Zilog
In message [EMAIL PROTECTED], Maxim Sobolev writes:
In message [EMAIL PROTECTED], Brent Verner writes:
On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
|
| Assignment:
|
| The v_tag element in struct vnode is a debugging aid, but unfortunately
| it is implemented in a way
reminds me, Adrian still oves us his story about ref :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
.
v_tag is only a debugging aid and it should be replaced by a const char *
instead so that we don't need to modify sys/vnode.h just to add a filesystem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
the 14.318 MHz
xtal on the motherboard with a something more stable.
PC hardware really sucks for timing.
Tell me about it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
for SIGILL, SIGFPE */
but does that mean we must expose the entire contents of trap.h to
userland? The problem is T_ is very common in lex source.
We most certainly shouldn't. Everything but the needed bits should
be #ifdef KERNEL.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
In message [EMAIL PROTECTED], Daniel O'Connor writes:
On 10-Aug-2001 Poul-Henning Kamp wrote:
The new ghostscript 6.51 has integrated the HPIJS backends for HP printers.
HPIJS is written by HP and contains most of their weird colormunging
technologies.
I managed to compile a 6.51
/PCL/whatever backends
in ghostscript.
Highly recommended!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
in this area.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
do it by submitting
a followup with the text
This PR can be closed
on a line of its own.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send
.
Right, and what are you going to do about some random company
in Elbonia who labels and unapproved cd as Official ?
One should never makes rules one can't enforce...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
to get hold
of a media copy of FreeBSD, when absolutely nothing prevents
me or anybody else from rolling a net distribution ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
*Wollongong*cough*hack*wheeze* (THUD!)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
which contains an explanation and the
grep(1)'able line:
This PR can be closed
Remember: Each open PR is a pissed off contributor...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
is stop HIRING them. :)
You know, there is almost a fortune in that...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
as the hills, proving prior art
would probably be relatively straightforward.
Well, the application date is what counts, and that's mar1992, but I'm
pretty sure that Bill Jolitz had them beat to that date already...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
.
As I already said: a device with no other precense in /dev has only
quickdirty reasons for using DEVFS cloning.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
In message [EMAIL PROTECTED], Ruslan Ermilov writes:
On Tue, Jun 05, 2001 at 07:43:38PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David O'Brien writes:
On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote:
Others see it differently, it would seriously break
In message [EMAIL PROTECTED], Dima Dorfman write
s:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], David O'Brien writes:
On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote:
Is there any reason not to MFC the new md(4) functionality
Zero reason
applications.
If we have abandoned the no changes to API or ABI in -stable
paradigm, it would be a good idea, but it serious rains on that
rule...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
In message [EMAIL PROTECTED], David O'Brien writes:
On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote:
Others see it differently, it would seriously break a lot of
people who are using -stable in embedded applications.
Can you expand on this? I assume you know we
introduced the $1$ marker,
which allows the algorithm to be replaced in a backwards compatible
way (as already done by OpenBSD).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
and purposes is a separate protocol
(at least it has it's own namespace, that's close enough for me)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
track of cloned dev_t's so we can nuke them
at various strategic points, havn't gotten to that yet.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
vfs.devfs.topinode: 118
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
forwarded message -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog
will be the future of semiconductors.
Hitachi has a GaAs SPARC chip; it is used in Satellites.
The CRAY-3 was GaAs based, if I'm not mistaken.
And Convex made a GaAs based supercomputer, the 3800 I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
In message [EMAIL PROTECTED], Dennis writes:
At 01:06 AM 04/27/2001, Mark Sergeant wrote:
I guess you missed the POINT, [...]
And I have to hand that to you Dennis: when it comes to missing points
you are the master...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
demed nice proof of concept but not the right way ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe
resolution.
The pps driver implements the RFC2783 PPS-API for timestamping
external events.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
In message [EMAIL PROTECTED], Warner Losh writes:
In message 60546.987709317@critter Poul-Henning Kamp writes:
: Use the pps driver and you get microsecond jitter with nanosecond
: resolution.
While I usually see microsecond jitter, I have seen it as high as a
few milliseconds when the interrupt
In message [EMAIL PROTECTED], Kirk McKusick writes:
Every vnode in the system has an associated object.
No: device vnodes dont...
I think the correct solution to that is to move devices away from
vnodes and into the fdesc layer, just like fifo's and sockets.
--
Poul-Henning Kamp | UNIX
In message [EMAIL PROTECTED], Rober
t Watson writes:
On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Kirk McKusick writes:
Every vnode in the system has an associated object.
No: device vnodes dont...
I think the correct solution to that is to move devices
argument of them
all for doing this...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
In message [EMAIL PROTECTED], Julian Elischer writes:
If we merged vnodes and vm objects,
then if devices were not vnodes, how would you represent
a vm area that maps a device?
You would use a VM object of course, but it would be a special
kind of VM object, just like today...
--
Poul-Henning
ll devices are handled by a magic
filesystem (specfs) in the same "orphan" mode by all filesystems
which support devices is another good reason.
I think I'll kick back tonight and try to see what it actually
takes to do it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROT
*should* run
through the VM object first:
We guarantee that today my mapping the actual hardware and my having
all read/writes be synchronouse. I remember at least one other
UNIX which didn't make that guarantee.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
vnode * + v_id).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
"soft references" using "struct vnode * + v_id).
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
I don't think NFS relies on vnodes never being freed.
It does, in some case nfs stashes a vnode pointer and the v_id
value away, and some time later tries to use that pair t
: if (vpid == vp-v_id
:nfs_vnops.c:vpid = newvp-v_id;
:nfs_vnops.c:if (vpid == newvp-v_id) {
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
hahahahahahahaha.. Look at the code more closely. v_id is not
managed by NFS
way of dealing with
it for remote operations, but the trouble is that it prevents us from
ever lowering their number again.
If Matt can device a smart way to loose the soft reference in nfs,
vnodes can be a truly dynamic thing.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
worries in trying to change that.
The namecache can do without the use of soft references.
The only reason vnodes are stable storage any more is that NFS
uses soft references to vnodes.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
n it is OK
for you to commit it yourself.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
reference.
Well, if that's the case, yank all uses of v_id from the nfs code,
I'll do the namecache and vnodes can be deleted to the joy of our users...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
in the
cache_purgeleafdirs(), considering how often it is called,
Do you have measured the performance impact of this to be an
insignificant overhead ?
Once we have that figured out I will commit the patch for you...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
uot;vmstat -vm" ?
That is entirely different from the vfs-namecache, I think it is
a per process one-slot directory cache. I have never studied it's
performance, but I belive a good case was made for it in the 4.[34]
BSD books.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
er tonight.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL
) very expensive.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
The only thing that is truely expensive is having to physically
scan a large directory in order to instantiate a new namei
record. Everything else is inexpensive
ntries can be negative
entries. You can monitor the number of negative entries with the
sysctl
debug.numneg: 305
the value of "16" was rather arbitrarily chosen and better defaults
may exist.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP s
,
involving creation of vnode and very likely a vm object again.
We can safely say that you cannot profitably _increase_ the size of
the namecache, except for the negative entries where raw statistics
will have to be the judge of the profitability of the idea.
--
Poul-Henning Kamp | UNIX since
the underlying vnode.
Right, but doing so means that to refind that vnode from the name
is (comparatively) very expensive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
In message [EMAIL PROTECTED], Dennis writes:
It seems that only 256 bpf devices are supported. How painful would it be
to increase that number...I assume its an 8bit varable somewhere? Are there
other caveats?
It's pretty trivial. Send a patch when you are done.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Dennis writes:
At 01:32 PM 03/28/2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Dennis writes:
It seems that only 256 bpf devices are supported. How painful would it be
to increase that number...I assume its an 8bit varable somewhere
Are there anybody out there playing with LonWorks and FreeBSD ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
th sending a Fore and a efficient card
to our new maintainer if we get one...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
t resulted in. Sometimes ascii is the right API.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
In message [EMAIL PROTECTED], Robe
rt Watson writes:
On Sat, 24 Mar 2001, Kris Kennaway wrote:
On Sat, Mar 24, 2001 at 08:36:30AM +0100, Poul-Henning Kamp wrote:
Shouldn't the FreeBSD project issue a press release welcoming
Apple's MacOS X ?
Good idea, write one :-)
To be a really
agree. Chart me up in the "kernel architecture" category
and lets find somebody else do the PR writing...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malic
Shouldn't the FreeBSD project issue a press release welcoming
Apple's MacOS X ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
as closely as possible, including the fact that it may disappear
without notice or caution.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
, unlike normal diffs.
Unified diffs are generally smaller than "plain" context diffs, and
some people find them more readable and some don't.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
with added emphasis:
Unified diffs are *also* context diffs.
Context diffs are named such because they contain undisturbed context
around the changed lines, unlike *normal* diffs.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
that cyl 0-9 has
18 sectors while cyl10-81 has 21.
A small matter of hacking...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
people who can fix it, but they cannot do anything if you
refuse to supply all the precise details in an easy to access form.
If you are unwilling to do that, then stop bothering us!
Indeed, I think Dennis could solve two problems by just dropping
FreeBSD right away.
--
Poul-Henning Kamp
available? And (most important) one
which is supported by the necessary BSD drivers?
www.lanmedia.com, they have a T1/E1 card...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
to help.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequat
incorporate that in your patch ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAI
errors, nfs servers going away, forced
unmounts).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe:
In message [EMAIL PROTECTED], Peter Seebach writes
:
In message 9402.983047348@critter, Poul-Henning Kamp writes:
Well, no, but the sole available definition of "portable" says that it is
"portable" to assume that all the memory malloc can return is really
available.
No, thi
301 - 400 of 606 matches
Mail list logo
