Andrey Simonenko [EMAIL PROTECTED] wrote:
On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote:
Andrey Simonenko [EMAIL PROTECTED] wrote:
Is it enough to get exclusive lock on vnode, before changing
v_op pointer? Here is my code:
vn_lock(cvp-vp, LK_EXCLUSIVE
Jacques A. Vidrine [EMAIL PROTECTED] wrote:
BTW, a slightly more complete patch that has the diffs for
/usr/include/resolv.h and also should correctly close the sockets that each
thread opens for the resolver can be found here:
Alright, here we go! I simplified some things out a bit and used
pthread_once(3) to make things look a little cleaner. The RES_BOGUS flag
was unnecessary, and now single-threaded programs and the first thread of
multi-threaded programs do not incur the allocation of per-thread resolver
BTW, a slightly more complete patch that has the diffs for
/usr/include/resolv.h and also should correctly close the sockets that each
thread opens for the resolver can be found here:
http://green.homeunix.org/~green/mostly_reentrant_resolver.patch
--
Brian Fundakowski Feldman
Andy Hilker [EMAIL PROTECTED] wrote:
Hi,
do i need save-entropy cronjobs in a jail environment or is it useless?
I experience heavy load when save-entropy runs, because there are
many jails on the system.
So i wondered about if i need this only on base system...
Any ideas or hints, how
Sam Leffler [EMAIL PROTECTED] wrote:
On Friday 03 October 2003 10:38 pm, Brian Fundakowski Feldman wrote:
I keep getting these panics on my SMP box (no backtrace or DDB or crash
dump of course, because panic() == hang to FreeBSD these days):
panic: receive: m == 0 so-so_rcv.sb_cc == 52
Sean Hamilton [EMAIL PROTECTED] wrote:
Seems my toying with atacontrol caused a reproducable panic. I have a perl
script which causes the panic right away every time, I'll mail that to
anybody @freebsd.org that wants it. (Or is such paranoia unnecessary?)
I believe everything else needed is
For what it's worth; I'm also using a dual-Athlon that gets spontaneous
reboots once in a while and seems like it could possibly have to do with
ACPI activating while the system is trying to cool itself down. Do you have
any more hints here on where the problem may lie so I can attempt to
Takanori Watanabe [EMAIL PROTECTED] wrote:
Hi, I had trouble with unionfs when it calles getcwd(3) when
I mount some directory on the directry in same file system,like
mount -t union /usr/home/foo/bar /usr/src/sys/ .
I investigate the problem by inserting debug print in getcwd.c.
Then I
Matt Dillon [EMAIL PROTECTED] wrote:
:On 21-May-01 Brian F. Feldman wrote:
: There's a certain issue that when several processes sharing a vmspace are
: exiting at the same time, there is a race condition such that the shared
: memory is going to be lost because the check for vm-vm_refcnt
Matt Dillon [EMAIL PROTECTED] wrote:
This could explain a few bug reports I've had over the years in regards
to systems leaking swap space. Good find!
Hmmm. May I suggest an alternative?
* Keep the part that changes vm-vm_refcnt == 1 to
--vm-vm_refcnt == 0
There's a certain issue that when several processes sharing a vmspace are
exiting at the same time, there is a race condition such that the shared
memory is going to be lost because the check for vm-vm_refcnt being the
check for the last decrement happening before the last decrement is
In some way, using Linux LinuxThreads programs that use shared memory, I've
ended up with dozens of shared memory segments that reportedly still have 1
attachment (which I'm really darn certain is impossible since I've killed
_everything_ in sight). I think something must have happened that
Alfred Perlstein [EMAIL PROTECTED] wrote:
* Brian F. Feldman [EMAIL PROTECTED] [010424 05:07] wrote:
In some way, using Linux LinuxThreads programs that use shared memory, I've
ended up with dozens of shared memory segments that reportedly still have 1
attachment (which I'm really darn
"Jeremiah Gowdy" [EMAIL PROTECTED] wrote:
Uuuuh, I'm gonna have to agree with Murray that there is a complete
dearth of free software for Windows. Go search shareware.com, or
Tucows, or any of the other Windows-centric software sites, and just
TRY to find most of the same tools or
After just buying a device and attempting to use uhid for a while, I got a
nice little crash. I can't figure out what's going on, because the clist
queue seems to be corrupted. Is it valid for a clist to have a non-zero
c_cc and NULL c_cf? I wonder if this is just me, because it seems to
On Sep 28 Kris Kennaway wrote:
On Thu, 28 Sep 2000, Jim Mercer wrote:
the reason i ask, is that if people cvsup without seeing or noticing this,
they may not realize until too late that the new passwords are md5.
anyone using nis with non-freebsd systems might get really
On Fri, 29 Sep 2000, jack wrote:
On Sep 28 Kris Kennaway wrote:
On Thu, 28 Sep 2000, Jim Mercer wrote:
the reason i ask, is that if people cvsup without seeing or noticing this,
they may not realize until too late that the new passwords are md5.
anyone using nis
Today Brian F. Feldman wrote:
You had to install DES and _then_ add the + line. Now there's one
more step.
Exactly. Since at least 2.0.5 those needing DES passwords
installed DES, and later CRYPTO, and we had them. As you said,
`Now there's one more step.' The problem
On Thu, 28 Sep 2000, Jim Mercer wrote:
On Thu, Sep 28, 2000 at 06:14:07PM -0700, Kris Kennaway wrote:
Set the value of the passwd_format login capability to "des" in
/etc/login.conf.
Brian Feldman neglected to document or mention this in the release notes
at all, as far as I
On Tue, 12 Oct 1999, Daniel C. Sobral wrote:
"Brian F. Feldman" wrote:
I'd like everyone to note that for now, if you are providing user-access
to a 4.0 box (and you don't absolutely trust your users), you should be
using the RLIMIT_SBSIZE for limiting network memory
On Sun, 10 Oct 1999, Chris Costello wrote:
On Sun, Oct 10, 1999, Laurence Berland wrote:
I like the idea as an optional LINT parameter that is NOT in the generic
kernel. Might make some linux people feel comfortable with the switch,
or might prove useful under some odd circumstances, but
I'd like everyone to note that for now, if you are providing user-access
to a 4.0 box (and you don't absolutely trust your users), you should be
using the RLIMIT_SBSIZE for limiting network memory usage just as
you use other RLIMITs for memory limiting, etc.
--
Brian Fundakowski Feldman
On Sun, 10 Oct 1999, Leif Neland wrote:
I'd like to plot uptime and number of calls from ppp to mrtg.
Any 'easy' way to ask ppp for these values, getting the answer for number
of seconds online since last asked?
Store the time from the previous call after each call, as with a
On Sat, 9 Oct 1999, Jonathan M. Bresler wrote:
bill,
please send me one box. i can give them out at the Washington
Area FreeBSD User's Group...as well as to people at work. After a
year of quiet work a number of die hard Linux folks are coming around
to see the light. ;)
Could
What do you all think about
http://www.FreeBSD.org/~green/OpenBSD.libc_r.cancel.patch
? I isolated the set of commits that added cancelling to OpenBSD's
libc_r, and it seems (since they took it from us originally :) it
should be relatively simple to port :/
--
Brian Fundakowski Feldman
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general
On Mon, 13 Sep 1999, Matthew Dillon wrote:
The case that is causing the panics is with the non-interrupt mbuf
allocation mechanism. Specifically, the case where M_WAIT is used.
The second problem under discussion, which really ought to be separated
out from the mbuf panic
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general
On Mon, 13 Sep 1999, Matthew Dillon wrote:
The case that is causing the panics is with the non-interrupt mbuf
allocation mechanism. Specifically, the case where M_WAIT is used.
The second problem under discussion, which really ought to be separated
out from the mbuf panic
On Thu, 16 Sep 1999, Nick Hibma wrote:
How do I nuke vnodes? This is the NetBSD code that needs to be emulated:
/* locate the major number */
for (maj = 0; maj nchrdev; maj++)
if (cdevsw[maj].d_open == ulptopen)
break;
On Thu, 16 Sep 1999, Nick Hibma wrote:
How do I nuke vnodes? This is the NetBSD code that needs to be emulated:
/* locate the major number */
for (maj = 0; maj nchrdev; maj++)
if (cdevsw[maj].d_open == ulptopen)
break;
On Wed, 15 Sep 1999, Jordan K. Hubbard wrote:
It can go in after the freeze - it's a bit late to be asking now. :)
I was guessing as much :) I didn't specifically see anyone requesting
for these things in -STABLE, so I didn't really pay much attention to
merging these things. It makes me
On Wed, 15 Sep 1999, Dan Nelson wrote:
RCS file: /home/ncvs/src/bin/dd/dd.c,v
revision 1.17
date: 1999/06/19 19:49:32; author: green; state: Exp; lines: +25 -21
Miscellaneous dd(1) changes: mainly fixing variable types (size_t,
ssize_t, off_t,
On Wed, 15 Sep 1999, Jordan K. Hubbard wrote:
It can go in after the freeze - it's a bit late to be asking now. :)
I was guessing as much :) I didn't specifically see anyone requesting
for these things in -STABLE, so I didn't really pay much attention to
merging these things. It makes me
On Tue, 7 Sep 1999, Wilko Bulte wrote:
Wilko (confused...)
No, I already committed the change to comment it out in -STABLE. I will
investigate further, but I will definitely not have it in by -RELEASE time.
No problem has been noticed before because XFree86 has not supported MTRRs
until
On Tue, 7 Sep 1999, Wilko Bulte wrote:
Wilko (confused...)
No, I already committed the change to comment it out in -STABLE. I will
investigate further, but I will definitely not have it in by -RELEASE time.
No problem has been noticed before because XFree86 has not supported MTRRs
until
On Sat, 4 Sep 1999, Randall Hopper wrote:
Does FreeBSD support Write Combining on K6 processors?
Randall
Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0.
--
Brian Fundakowski Feldman / "Any sufficiently advanced bug is\
[EMAIL PROTECTED]
On Sun, 5 Sep 1999, Randall Hopper wrote:
Brian F. Feldman:
|Randall Hopper:
| Does FreeBSD support Write Combining on K6 processors?
|
|Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0.
Great! Thanks.
Do you know what the status is on the XFree86
On Sun, 5 Sep 1999, Randall Hopper wrote:
Mike Smith:
| Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE
|
|You could try to backport the two sets of commits I just made to the
|-stable branch, but you might be better off moving to -stable or to
|3.3-RELEASE.
On Sat, 4 Sep 1999, Randall Hopper wrote:
Does FreeBSD support Write Combining on K6 processors?
Randall
Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0.
--
Brian Fundakowski Feldman / Any sufficiently advanced bug is\
gr...@freebsd.org
On Sun, 5 Sep 1999, Randall Hopper wrote:
Brian F. Feldman:
|Randall Hopper:
| Does FreeBSD support Write Combining on K6 processors?
|
|Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0.
Great! Thanks.
Do you know what the status is on the XFree86
On Sun, 5 Sep 1999, Randall Hopper wrote:
Mike Smith:
| Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE
|
|You could try to backport the two sets of commits I just made to the
|-stable branch, but you might be better off moving to -stable or to
|3.3-RELEASE.
I do need help completeing this little project. Basically, the sockbuf
starvation problem can be solved by using administrative restrictions
on total sockbuf size. So far, I have things almost working. The only
problem is that on PF_LOCAL SOCK_STREAMS (or at least that's where it
shows up) there
It probably needs work still, and I'd really appreciate someone
helping finish it, but I have a solution.
http://www.FreeBSD.org/~green/sbsize.patch
--
Brian Fundakowski Feldman / Any sufficiently advanced bug is\
gr...@freebsd.org | indistinguishable from a
I do need help completeing this little project. Basically, the sockbuf
starvation problem can be solved by using administrative restrictions
on total sockbuf size. So far, I have things almost working. The only
problem is that on PF_LOCAL SOCK_STREAMS (or at least that's where it
shows up) there
It probably needs work still, and I'd really appreciate someone
helping finish it, but I have a solution.
http://www.FreeBSD.org/~green/sbsize.patch
--
Brian Fundakowski Feldman / "Any sufficiently advanced bug is\
[EMAIL PROTECTED] | indistinguishable from
On Mon, 23 Aug 1999, Sheldon Hearn wrote:
The OpenGroup Single UNIX Specification is quite clear on the following
issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g
for something we don't offer. Our -g is a backward compatibility option.
Yes, I agree that that's what
On Mon, 23 Aug 1999, Sheldon Hearn wrote:
The OpenGroup Single UNIX Specification is quite clear on the following
issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g
for something we don't offer. Our -g is a backward compatibility option.
Yes, I agree that that's what
On Sun, 22 Aug 1999, Nick Hibma wrote:
Unfortunately the kernel is compiled with -O which does not include
inlining (dunno about explicit inlining, but don't think so).
Nick
-O lets you do explicit inlining, and -O2 enables -finline-functions.
Anyway, I think the simple solution to the
On Sun, 22 Aug 1999, Bill Fumerola wrote:
On Sun, 22 Aug 1999, Zhihui Zhang wrote:
In file uipc_usrreq.c, there are many routines beginning with unp_. For
example, unp_connect(), unp_bind(), etc. What does unp stand for?
guess
W. Richard Stevens wrote a book Unix Network Programming
On Wed, 18 Aug 1999, Nik Clayton wrote:
On Tue, Aug 03, 1999 at 12:37:39AM -0700, Julian Elischer wrote:
Just fetched and compiled the festival package.
http://www.cstr.ed.ac.uk/projects/festival
Likewise, based on your comments.
Has anyone had any problems with the volume being far
On Sat, 14 Aug 1999, David Scheidt wrote:
On Sat, 14 Aug 1999, Brian F. Feldman wrote:
On Sat, 14 Aug 1999, James Howard wrote:
Would it be legal to strip the BSD license of say, inetd and put a GPL on
it? Many in the Linux community seem to think this is true but I thought
On Sat, 14 Aug 1999, Leif Neland wrote:
[Regarding GPL]
If a company sell or lease us a mailserver based on Linux, where we only
have smtp and pop3-access to, can we say "Hey, this is GPL'ed, give us the
source"?
Yes, you can do that; it's required for source to be "easily available"
in the
On Sat, 14 Aug 1999, James Howard wrote:
On Fri, 13 Aug 1999, Mike Smith wrote:
It doesn't work like that; once it's been distributed with Linux it's
no longer BSD-licensed, it's GPLed. They would still be unable to
recover post-viral changes and reuse them in their own XFS product.
On Sat, 14 Aug 1999, David Scheidt wrote:
On Sat, 14 Aug 1999, Brian F. Feldman wrote:
On Sat, 14 Aug 1999, James Howard wrote:
Would it be legal to strip the BSD license of say, inetd and put a GPL on
it? Many in the Linux community seem to think this is true but I thought
On Sat, 14 Aug 1999, Leif Neland wrote:
[Regarding GPL]
If a company sell or lease us a mailserver based on Linux, where we only
have smtp and pop3-access to, can we say Hey, this is GPL'ed, give us the
source?
Yes, you can do that; it's required for source to be easily available
in the GPL.
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote:
It would be nice, but there are portability issues.
Hi Peter,
I'm only replying to your mail because you're the last person to mention
portability as a case againsdt NetBSD's
On Fri, 13 Aug 1999, Jamie Howard wrote:
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
On Fri, 13 Aug 1999 12:50:54 -0400, "Brian F. Feldman" wrote:
I fully agree with this. If it can be cleanly added to the current test(1)
(which it can), we should have it, even if it were JUST for the sake of
portability.
A
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
On Fri, 13 Aug 1999 15:36:24 +1000, Peter Jeremy wrote:
It would be nice, but there are portability issues.
Hi Peter,
I'm only replying to your mail because you're the last person to mention
portability as a case againsdt NetBSD's test(1).
On Fri, 13 Aug 1999, Jamie Howard wrote:
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
On Fri, 13 Aug 1999 12:50:54 -0400, Brian F. Feldman wrote:
I fully agree with this. If it can be cleanly added to the current test(1)
(which it can), we should have it, even if it were JUST for the sake of
portability.
Ah, but I'm
On Wed, 11 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it
On Thu, 12 Aug 1999, Brian F. Feldman wrote:
On 12 Aug 1999, Dag-Erling Smorgrav wrote:
Graham Wheeler [EMAIL PROTECTED] writes:
I was writing a script yesterday, and I wanted to have a test to compare
the modification time of two files. test(1) doesn't have the ability to
do
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the current organization.
Choose:
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
I don't care if most of the
directories called "gnu" in the current tree contain GPLd code. How
I had to read your messa
On Wed, 11 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908112337400.81521-100...@janus.syracuse.net
Brian F. Feldman writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I
On 12 Aug 1999, Dag-Erling Smorgrav wrote:
Graham Wheeler g...@cequrux.com writes:
I was writing a script yesterday, and I wanted to have a test to compare
the modification time of two files. test(1) doesn't have the ability to
do this. In the end I worked around this by using make(1), but
On Thu, 12 Aug 1999, Brian F. Feldman wrote:
On 12 Aug 1999, Dag-Erling Smorgrav wrote:
Graham Wheeler g...@cequrux.com writes:
I was writing a script yesterday, and I wanted to have a test to compare
the modification time of two files. test(1) doesn't have the ability to
do
On Thu, 12 Aug 1999, Warner Losh wrote:
In message 199908121645.qaa13...@hermes.epita.fr free bsd writes:
: I would like to know, if there a way (a tools) to make a partition fat16.
fdisk to mark the partion as fat16, newfs_msdos to splat a file system
onto it.
Warner
This should
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the current organization.
Choose:
On Thu, 12 Aug 1999, Steve Kargl wrote:
That doesn't fit with the current organization.
Choose:
a. fsf
b. gnu
c. glibc
d. other
src/lib/libcompat/{fsf,gnu,glibc} connotes GPL code.
src/lib/libcompat/other allows SysV, Solaris, Linux, etc.
compatibility
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
I don't care if most of the
directories called gnu in the current tree contain GPLd code. How
I had to read your message about 4 or 5
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try to be more compatible with.
Brian
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try to be more compatible with.
Brian Fundakowski
On Mon, 9 Aug 1999, Tony Finch wrote:
"Brian F. Feldman" [EMAIL PROTECTED] wrote:
Is there anyone who is specifically checking for long long
C9X-compliancy in the source tree (mainly libc)?
I started reviewing libc for C9X features in general -- a fair amount
of work i
On Mon, 9 Aug 1999, Tony Finch wrote:
Brian F. Feldman gr...@freebsd.org wrote:
Is there anyone who is specifically checking for long long
C9X-compliancy in the source tree (mainly libc)?
I started reviewing libc for C9X features in general -- a fair amount
of work is required to update
On Sun, 8 Aug 1999, Osokin Sergey wrote:
Now in current i use following script (aka mixer.sh) for install sound
environment:
#!/bin/sh
mixer vol 36
mixer synth 36
mixer pcm 36
mixer line 36
mixer cd 68
Maybe add to rc.conf all features of mixer?
(aka vol, bass etc)
Yes, I've
I envision something like the following being available in /etc/rc,
since there are many people who set mixer default values at startup in
some random way. It would be nice to provide an easy way to do this.
I'd like to get a vote on whether this should be added or not.
I'd do something like the
On Sun, 8 Aug 1999, Osokin Sergey wrote:
Now in current i use following script (aka mixer.sh) for install sound
environment:
#!/bin/sh
mixer vol 36
mixer synth 36
mixer pcm 36
mixer line 36
mixer cd 68
Maybe add to rc.conf all features of mixer?
(aka vol, bass etc)
Yes, I've
On Sat, 7 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: Sorry, kinda used to quad rather than long long. I'm pretty sure ll
: isn't yet supported by the kernel printf functions...
You may be right about that.
The simple solution to this,
On Sat, 7 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908070138180.9444-100...@janus.syracuse.net
Brian F. Feldman writes:
: You can always use off_t with %qd, (int64_t)foo.
But that isn't portbale. %qd is a bsdism. %lld and %llu are the
latest C standards way to say
On Sat, 7 Aug 1999, Peter Wemm wrote:
Brian F. Feldman wrote:
On Fri, 6 Aug 1999, Don Lewis wrote:
On Aug 6, 3:29pm, Sheldon Hearn wrote:
} Subject: quad_t and portability
}
} Hi folks,
}
} I want to patch wc(1) so that it uses quad_t instead of u_long
On Sat, 7 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908070248001.11809-100...@janus.syracuse.net
Brian F. Feldman writes:
: Sorry, kinda used to quad rather than long long. I'm pretty sure ll
: isn't yet supported by the kernel printf functions...
You may be right about
On Sat, 7 Aug 1999, John Polstra wrote:
In article 19990807165202.a37...@cicely8.cicely.de,
Bernd Walter ti...@cicely.de wrote:
On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote:
But not on the Alpha... int64_t is a long there, and gcc complains unless
you use %ld.
Mmm
On Fri, 6 Aug 1999, Don Lewis wrote:
On Aug 6, 3:29pm, Sheldon Hearn wrote:
} Subject: quad_t and portability
}
} Hi folks,
}
} I want to patch wc(1) so that it uses quad_t instead of u_long. This is
} necessary if wc(1) is to produce sensible results for files containing
} more than
On Sat, 7 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: You can always use off_t with "%qd", (int64_t)foo.
But that isn't portbale. %qd is a bsdism. %lld and %llu are the
latest C standards way to say that.
Sorry, kinda used
On Fri, 6 Aug 1999, Daniel O'Connor wrote:
On 06-Aug-99 Wes Peters wrote:
Because it's wrong. If you don't believe me, buy a copy of the spec. Why
should we waste valuable developer time trying to support mis-configured
hardware?
Since when has PC hardware followed the specs?
On Fri, 6 Aug 1999, Don Lewis wrote:
On Aug 6, 3:29pm, Sheldon Hearn wrote:
} Subject: quad_t and portability
}
} Hi folks,
}
} I want to patch wc(1) so that it uses quad_t instead of u_long. This is
} necessary if wc(1) is to produce sensible results for files containing
} more than
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
--- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char
On Thu, 5 Aug 1999, John Polstra wrote:
In article [EMAIL PROTECTED],
Brian F. Feldman [EMAIL PROTECTED] wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld puts
On Thu, 5 Aug 1999, Arun Sharma wrote:
I wonder if so much assembly code is really necessary for FreeBSD. One
argument for minimal usage of assembly code is that it is easier to code
non trivial algorithms in C.
No, so much isn't really necessary.
One such example is the scheduler. Since
On Fri, 6 Aug 1999, Daniel O'Connor wrote:
On 06-Aug-99 Wes Peters wrote:
Because it's wrong. If you don't believe me, buy a copy of the spec. Why
should we waste valuable developer time trying to support mis-configured
hardware?
Since when has PC hardware followed the specs?
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
--- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char
On Thu, 5 Aug 1999, John Polstra wrote:
My position was (and still is) that for most purposes dynamic
linking is a definite advantage, but we should continue to permit
static linking for applications that want it (which Sun doesn't).
I generally agree, except I feel that when there are
On Thu, 5 Aug 1999, John Polstra wrote:
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without
1 - 100 of 278 matches
Mail list logo
