++?
Would people be opposed to a hack where optionally one could fence
off the jobs for C++ programs during buildworld? meaning maybe
set .NOTPARALLEL via some other option?
It's kind of insane how much memory the compiler uses these days.
Any other options?
--
- Alfred Perlstein
.- VMOA #51
Some suggestions here, jemalloc, kernel threads are good ones.
Another issue may just be some change for default thread stack size.
This would explain why the RESIDENT set is the same, but the VIRTUAL grew.
-Alfred
On 10/30/12 9:56 AM, Karl Pielorz wrote:
--On 30 October 2012 19:43 +0700
It seems like the new compiler likes to get up to ~200+MB resident when
building some basic things in our tree.
Unfortunately this causes smaller machines (VMs) to take days because of
swap thrashing.
Doesn't our make(1) have some stuff to mitigate this? I would expect it
to be a bit smarte
On 10/31/12 1:41 PM, Peter Jeremy wrote:
On 2012-Oct-31 12:58:18 -0700, Alfred Perlstein wrote:
It seems like the new compiler likes to get up to ~200+MB resident when
building some basic things in our tree.
The killer I found was the ctfmerge(1) on the kernel - which exceeds
~400MB on i386
On 10/31/12 3:14 PM, Peter Jeremy wrote:
On 2012-Oct-31 14:21:51 -0700, Alfred Perlstein wrote:
Ah, but make(1) can delay spawning any new processes when it knows its
children are paging.
That could work in some cases and may be worth implementing. Where it
won't work is when m
I've always wanted to be able to query the current dump device.
This patch lets me do this.
Poul-Henning, what do you think? Is there a nicer way? Perhaps a way
to include the "/dev/$device"
as the patch in its current form only stores "ada0p3". I think that is OK.
Provide a device name i
On 11/1/12 1:06 AM, Poul-Henning Kamp wrote:
In message <50921b44.20...@ixsystems.com>, Alfred Perlstein writes:
Poul-Henning, what do you think? Is there a nicer way? Perhaps a way
to include the "/dev/$device"
I think there are private implemenations where dump
I think very few of the m_nowaits actually need the reserve behavior. We should
probably switch away from it digging that deep by default and introduce a flag
and/or a per thread flag to set the behavior.
Sent from my iPhone
On Nov 11, 2012, at 4:32 PM, "Dieter BSD" wrote:
> Alan writes:
>>
On Nov 12, 2012, at 4:11 AM, Andre Oppermann wrote:
>
>
> I don't think many places depend on M_NOWAIT digging deep. I'm
> perfectly happy with having M_NOWAIT give up on first try. Only
> together with M_TRY_REALLY_HARD it would dig into reserves.
>
> PS: We have a really nasty namespace c
On 11/14/12 10:15 PM, Adrian Chadd wrote:
Hi all,
When debugging and writing wireless drivers/stack code, I like to
sprinkle lots of locking assertions everywhere. However, this does
cause things to panic quite often during active development.
This patch (against stable/9) makes the actual pani
On 11/15/12 12:51 PM, Andriy Gapon wrote:
on 15/11/2012 22:00 Adrian Chadd said the following:
But I think my change is invaluable for development, where you want to
improve and debug the locking and lock interactions of a subsystem.
My practical experience was that if you mess up one lock in o
On 11/15/12 11:22 PM, Andriy Gapon wrote:
on 16/11/2012 01:20 Alfred Perlstein said the following:
We need to enable developers to skip these areas and test their own code.
I wish that there was a magic knob to ignore build breakages, so that the
developers could test how their own code
On 11/16/12 10:18 AM, Adrian Chadd wrote:
On 16 November 2012 00:26, Alfred Perlstein wrote:
Adding another option to tag asserts so that it was sort of like:
KASSERT((cond, section, "string")); would be interesting, then you could
turn KASSERTS on based on "vfs" or p
On Nov 18, 2012, at 5:37 AM, Dimitry Andric wrote:
> On 2012-11-16 23:04, Navdeep Parhar wrote:
>> On 11/16/12 13:49, Roman Divacky wrote:
>>> Yes, it does that. iirc so that you can have things like
>>>
>>> void foo(int cond) {
>>> if (cond) {
>>> static int i = 7;
>>> } else {
>>>
On 12/8/12 5:05 PM, Richard Sharpe wrote:
On Sun, 2012-12-09 at 00:50 +0100, Andre Oppermann wrote:
Hi folks,
Our QA group (at xxx) using Samba and smbtorture has been seeing a
lot of cases where accept returns ECONNABORTED because the system load
is high and Samba has a large listen backlog.
Eitan was asking me to update the FAQ section 5.7:
*5.7.* Why do I get the error "kernel: proc: table is full"?
That error is no longer relevant, but I also seemed to find out
something else interesting..
Been grepping through the code, and it seems like the only side-effect
of maxproc chan
Hey guys.
So the other day in an effort to debug a memory leak I decided to take a
look at malloc+utrace(2) and decided to make a tool to debug where leaks
are coming from.
A few hours later I have:
1) a new version of utrace(2) (utrace2(2)) that uses structured data to
prevent overloading o
On 12/22/12 8:56 AM, Ed Maste wrote:
On 21 December 2012 22:37, Alfred Perlstein wrote:
Is it time to start installing with some form of debug symbols? This would
help us also with dtrace.
I just posted a patch to add a knob to build and install standalone
debug files. My intent is that we
On 12/22/12 8:46 AM, Ed Maste wrote:
When this knob is set standalone debug files for shared objects are
built and installed in /usr/lib/debug/.debug. GDB
searches this path for debug data.
The -g flag is automatically added to CFLAGS if debug files are enabled
(but the shared objects are still
On 12/22/12 6:14 PM, Jan Beich wrote:
Ed Maste writes:
When this knob is set standalone debug files for shared objects are
built and installed in /usr/lib/debug/.debug. GDB
searches this path for debug data.
[...]
What about ports? They are not allowed to install outside of PREFIX.
$ cd
On 12/22/12 8:13 PM, Alfred Perlstein wrote:
On 12/22/12 6:14 PM, Jan Beich wrote:
Ed Maste writes:
When this knob is set standalone debug files for shared objects are
built and installed in /usr/lib/debug/.debug. GDB
searches this path for debug data.
[...]
What about ports? They are not
On 12/23/12 9:28 AM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to take a look
at malloc+utrace(2) and decided to make a tool to debug where leaks are coming
from.
A few hours later I have:
1) a new
On 12/23/12 1:47 PM, Garrett Cooper wrote:
On Sun, Dec 23, 2012 at 8:26 AM, Ed Maste wrote:
On 22 December 2012 23:13, Alfred Perlstein wrote:
I have a patch for this. I am building world to see what happens, if you
want to try it, or comment on it, please let me know.
Changes are
On 12/23/12 7:20 PM, Garrett Cooper wrote:
On Sat, Dec 22, 2012 at 9:42 PM, Alfred Perlstein wrote:
...
lfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
invalid SHT_GROUP entry
/usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So: no
group info for section .text
On 12/23/12 8:36 PM, Mark Johnston wrote:
On Dec 23, 2012 10:55 PM, "Alfred Perlstein" <mailto:bri...@mu.org>> wrote:
>
> On 12/23/12 7:20 PM, Garrett Cooper wrote:
>>
>> On Sat, Dec 22, 2012 at 9:42 PM, Alfred Perlstein <mailto:bri...@mu.org>>
ILDIR=/root/Maildir
IRCNAME=Alfred Perlstein
CVSROOT=/home/ncvs
BLOCKSIZE=1K
OLDPWD=/usr/home/alfred/freebsd
PWD=/usr/home/alfred/freebsd
SHLVL=2
TERM=screen
SHELL=/usr/local/bin/zsh
MAIL=/var/mail/root
LOGNAME=root
USER=root
USERNAME=root
HOME=/root
SUDO_COMMAND=/usr/local/bin/zsh
SUDO_USER=a
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to take a look
at malloc+utrace(2) and decided to make a tool to debug where leaks are coming
from.
A few hours later I have:
1) a new
On 1/10/13 1:41 AM, Alfred Perlstein wrote:
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to
take a look at malloc+utrace(2) and decided to make a tool to debug
where leaks are
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
https://github.com/alfredperlstein/freebsd/compare
On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
On 1/15/13 10:18 AM, Wojciech Puchar wrote:
does anyone know a PXE image (just like /boot/pxeboot) that can be
placed on tftp server and the only thing it will do would be loading
first sector from first local disk at 0x07c00 and booting as with
normal hard drive.
what i need is to be able to
On 1/15/13 1:43 PM, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
Luckily it's for an open source project (Python), so recompilation
isn't a big deal. (I also check the intrinsic result versus the
syscall result during startup to verify
On 1/28/13 10:11 AM, Ian Lepore wrote:
I've got a question that isn't exactly freebsd-specific, but
implemenation-specific behavior may be involved.
I've got a server process that accepts connections from clients on a
PF_LOCAL stream socket. Multiple clients can be connected at once; a
list of
Does plip no longer work?
Sent from my iPhone
On Jan 30, 2013, at 4:39 PM, Eitan Adler wrote:
> There has been some discussion about removing plip support from GENERIC
> kernels.
> plip still appears in sys/conf/NOTES
>
> Does anyone object to the following?
>
> commit f4efd3cf43514bcb1378e2
On 3/1/13 5:50 AM, Andriy Gapon wrote:
I am trying to understand if it is possible to allow memory allocations
(M_NOWAIT,
of course) in a spinlock context.
I do not see any obvious architectural obstacles.
But the fact that all of the uma locks, system map lock, object locks, page
queue
locks a
On 3/5/13 8:03 AM, Dirk Engling wrote:
Dear fellow FreeBSD hackers,
while writing a daemon that uses a kqueue to keep track of forked
processes and pipes to userland client code etc, I noticed a lack of
features to implement a proper shutdown without holding data redundantly.
When my daemon
As far I can tell it's now April 2nd in all time zones.
Can we now end this thread?
thank you,
-Alfred
On 4/2/13 6:22 AM, Paul Schenkeveld wrote:
On Tue, Apr 02, 2013 at 10:22:20AM +, Ruben de Groot wrote:
On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed:
On Tue, Ap
On 4/8/13 4:10 PM, Adrian Chadd wrote:
Hi,
Your idea is interesting, but it doesn't fix the underlying problem -
there's just too much code. :(
If you were to API'ify some of the more basic things such as fget,
fdrop, filedesc stuff you could potentially swap out the systems for
simpler (albe
On 4/8/13 6:42 PM, Adrian Chadd wrote:
Well, it's relatively easy to experience what it's like.
No it's not. We all have jobs that demand different things from us.
Taking the time to guess at the problem, only to be told "you're doing
it wrong" by someone actually in the position to build t
On 4/9/13 10:36 AM, Wojciech Puchar wrote:
happy that FreeBSD is among the selected organization.
I am a third year student interested to work in the field of embedded
system. I applied last year and the title of my project was " Kernel
Size
why only in embedded system. smaller programs are al
On 4/10/13 11:42 AM, Benjamin Kaduk wrote:
On Wed, 10 Apr 2013, Wojciech Puchar wrote:
How do your tests work? Do you examine PTEs directly to check for
superpages
or are you relying on the vm.pmap.pde sysctls?
the later.
anyway - algorithm described on list - that heuristics detects
cons
du...@juniper.net
-Original Message-
From: owner-freebsd-hack...@freebsd.org
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Alfred Perlstein
Sent: Wednesday, April 10, 2013 4:00 PM
To: Benjamin Kaduk
Cc: Wojciech Puchar; Sebastian Feld; freebsd-hackers@freebsd.org
Subject: Re: Mul
On 4/30/13 8:57 PM, Lawrence Stewart wrote:
[reposting from freebsd-arch@ - was probably the wrong list]
Hi all,
I've had use for these a few times now when wanting to restart a loop at
a previously found element, and wonder if there are any thoughts about
sticking them (and equivalents for oth
Hey folks,
I took a shot at fixing this issue with building aicasm as part of
"buildkernel" of an older 9.0 src on a machine running HEAD.
aicasm.o: In function `__getCurrentRuneLocale': >
/usr/include/runetype.h:96: undefined reference to `_ThreadRuneLocale'
The issue seems to be two-fold:
1
On 5/1/13 9:57 AM, Steven Hartland wrote:
I don't believe aicasm is actually needed if you don't have a driver
which requires e.g. ahd or ahc. It would be good to get that fixed too.
True, but a challenge I don't currently have time for.
I'm about to kick-off a universe build with my changes i
Hey folks,
I took a shot at fixing this issue with building aicasm as part of
"buildkernel" of an older 9.0 src on a machine running HEAD.
aicasm.o: In function `__getCurrentRuneLocale': >
/usr/include/runetype.h:96: undefined reference to `_ThreadRuneLocale'
The issue seems to be two-fold:
On 5/1/13 2:38 PM, Brooks Davis wrote:
On Wed, May 01, 2013 at 09:44:54AM -0700, Alfred Perlstein wrote:
Hey folks,
I took a shot at fixing this issue with building aicasm as part of
"buildkernel" of an older 9.0 src on a machine running HEAD.
aicasm.o: In function `__getCurrent
On 5/10/13 12:31 PM, Karl Dreger wrote:
Hello,
I have been taking a look at a few syscalls in /usr/src/sys/kern/ and
always find that in their actuall c definition the function names are
preprended by a sys_. Take for example the fork system call which
is found in /usr/src/sys/kern/kern_fork.c
i
On 5/11/13 1:23 AM, Karl Dreger wrote:
I am feeling rather stupid at the moment, but I can't find the assembler
files that you are referring to. Do you mean that every syscall under
sys/kern/*.c has a corresponding .S file in src/lib/libc/?
Nope, the .S files are under the object directory:
On 5/26/13 10:03 AM, Dirk Engling wrote:
On 26.05.13 04:51, Super Bisquit wrote:
Please don't turn this into an architecture dependent mess. PCBSD is
i386 & AMD64 only.
Read my email thoroughly and notice that I never seriously considered
using pc-sysinstall after looking into it. Don't worry.
On 5/25/13 8:45 PM, Teske, Devin wrote:
On May 25, 2013, at 7:51 PM, Super Bisquit wrote:
Please don't turn this into an architecture dependent mess. PCBSD is i386 &
AMD64 only.
There's a GSoC project (of which I'm potential mentor) to fix that.
However, you are entirely right… we can't in a
On 5/27/13 9:56 AM, Bruce Cran wrote:
On 27/05/2013 16:48, Alfred Perlstein wrote:
Why can we not use in the interim use pc-sysinstall on the platforms
that it performs best on and use bsdinstall on the others?
Because pc-sysinstall doesn't have a UI - it's only a backend. If
On 5/27/13 11:40 AM, Bruce Cran wrote:
On 27/05/2013 19:03, Alfred Perlstein wrote:
Do we always have to seek the lowest common denominator for our user
experience?
Yes.
Is this a joke?
-Alfred
___
freebsd-hackers@freebsd.org mailing list
http
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think there should
be a single UI and scripting interface across all platforms. We should
try
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?
It probably /was/ too short a reply. Personally I think
On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran
[[ moved to hackers@ from private mail. ]]
On 5/28/13 1:13 PM, John Baldwin wrote:
On Tuesday, May 28, 2013 3:29:41 pm Alfred Perlstein wrote:
On 5/28/13 9:04 AM, John Baldwin wrote:
On Tuesday, May 28, 2013 2:13:32 am Alfred Perlstein wrote:
Hey folks,
I had a talk with Nathan Whitehorn
On 5/28/13 10:08 PM, Konstantin Belousov wrote:
On Tue, May 28, 2013 at 01:35:01PM -0700, Alfred Perlstein wrote:
[[ moved to hackers@ from private mail. ]]
On 5/28/13 1:13 PM, John Baldwin wrote:
On Tuesday, May 28, 2013 3:29:41 pm Alfred Perlstein wrote:
On 5/28/13 9:04 AM, John Baldwin
On 5/29/13 12:16 AM, Konstantin Belousov wrote:
On Tue, May 28, 2013 at 10:31:40PM -0700, Alfred Perlstein wrote:
On 5/28/13 10:08 PM, Konstantin Belousov wrote:
On Tue, May 28, 2013 at 01:35:01PM -0700, Alfred Perlstein wrote:
[[ moved to hackers@ from private mail. ]]
On 5/28/13 1:13 PM
are you actually adding to the ISO which FBSD-current can't do?
If it's not upstream already - will it be contributed upstream?
It seems pretty obvious to me that the contribution is that all this
stuff works out of the box. That is pretty nice.
x27;t there be some sort of DELAY in there?
My platform has an emulated serial device in hardware, so it
may be that the loop could run a LOT faster than transmit can
happen...
any ideas of what the DELAY should be?
--
- Alfred Perlstein
___
freebsd-hacke
H("kern.maxssiz", &maxssiz);
sgrowsiz = SGROWSIZ;
TUNABLE_ULONG_FETCH("kern.sgrowsiz", &sgrowsiz);
any objections?
I don't see any obvious way to get at these values on a running
system.
--
- Alfred Perlstein
___
f
* Paul Saab <[EMAIL PROTECTED]> [070712 11:14] wrote:
> Alfred Perlstein wrote:
> >I would like to export the various parameters from subr_param.c
> >into sysctl, these nodes would include the names from the following
> >tunables as well as others in these files.
> &g
ement limits to this so that a haywire application
is not able to be "critical" forever.
Any help would be appreciated.
--
- Alfred Perlstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
* Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote:
> On Tue, 2 Oct 2007, Alfred Perlstein wrote:
>
> >Hi guys, we need critical sections for userland here.
> >
> >This is basically to avoid a process being switched out while holding
> >a user level s
* Kip Macy <[EMAIL PROTECTED]> [071002 20:00] wrote:
> On 10/2/07, Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> > * Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote:
> > > On Tue, 2 Oct 2007, Alfred Perlstein wrote:
> > >
> > >
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote:
> On Tue, 2 Oct 2007, Alfred Perlstein wrote:
>
> >* Daniel Eischen <[EMAIL PROTECTED]> [071002 19:46] wrote:
> >>On Tue, 2 Oct 2007, Alfred Perlstein wrote:
> >>
> >>>Hi guys, we nee
* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:16] wrote:
> On Tue, 2 Oct 2007, Alfred Perlstein wrote:
>
> >* Daniel Eischen <[EMAIL PROTECTED]> [071002 20:02] wrote:
> >>On Tue, 2 Oct 2007, Alfred Perlstein wrote:
> >>
> >>>* Daniel Eisc
t scale well if they're descheduled from the cpu while holding a
> lock.
Yes, exactly the problem, it sucks when process A on CPU 1 runs out
of quantum while holding a lock that a runner on CPU 2 wants.
--
- Alfred Perlstein
___
freebsd-hacker
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 02:05] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Hi guys, we need critical sections for userland here.
> >
> > This is basically to avoid a process being switched out while holding
> > a use
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Do you have:
> >
> > a) Evidence or a paper to prove that this is a bad idea?
>
> I need evidence or a paper to prove that it is a bad idea to
* Wilko Bulte <[EMAIL PROTECTED]> [071004 04:15] wrote:
> Quoting Alfred Perlstein, who wrote on Thu, Oct 04, 2007 at 03:19:02AM -0700
> ..
> > * Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:01] wrote:
> > > Alfred Perlstein <[EMAIL PRO
uck on 6.x, how is threads on this platform?
Second off we are contending against other devices in the system
that do not run FreeBSD, How do we address that?
--
- Alfred Perlstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/m
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [071004 03:28] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > It's not worth my time to engage someone with your mind set, you
> > posses neither the technical nor interpersonal skill to be useful
> > to m
file > file.sysctl.out
sysctl_help_database_builder file.sysctl.out > file.sysctl.db
done
Then these would be copied into /boot or maybe some other place
as part of the install process.
Sysctl or some other util could then read these db files to give
help with sysctls.
Any ideas/pointers on how to do this linker m
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [080125 07:58] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Hey guys, something that I've always wanted to do was actually somehow
> > export those handy description strings from the kernel SYSCTL macros
&
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [080126 07:10] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> writes:
> >> [EMAIL PROTECTED] ~% sysctl -d dev.cpu.0.temperature
> >> dev.cpu.0.temperature: C
* Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> [080126 07:28] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Dag-Erling Sm??rgrav <[EMAIL PROTECTED]> writes:
> > > BTW, when are you going to join the 21st century and get a MUA that
> > > groks U
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
> Is there any (evidently non-portable) way of determining a function
> instance's return address? I have an idea or two that involves the
> return address and dladdr(). The code I currently use looks like this:
>
> int
> log_print(log_t *log, char *fmt,
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
> Alfred Perlstein writes:
> > This looks like what you are doing is trying to grab the data on the
> > stack before "log" which is the return address.
>
> Yes. It actually works :)
>
> >
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
> Alfred Perlstein writes:
> > On 18 Jul 1999, Dag-Erling Smorgrav wrote:
> > > Alfred Perlstein writes:
> > > > I doubt this is
> > > > at all portable and
On 19 Jul 1999, Dag-Erling Smorgrav wrote:
> Alfred Perlstein writes:
> > On 18 Jul 1999, Dag-Erling Smorgrav wrote:
> > > Hmm, I ended up using a global variable which I increment at the
> > > beginning of the signal handler, and decrement at the end.
> > As lon
it it is incorrect.
Increasing the size of the cvs repo is not a consideration when
worthwhile docs can be incorperated, especially when the person
who needs to maintain it requires changess for readability.
Is there a point to hindering the maintainer's ongoing work?
-Alfred Perlstein - [bri...
a follow the rules.
quit acting like and old fart that fears change. (*)
afaik, Brian is the mainter of ipfw, it should be noted so, so that
if his changes break something it comes down on his head. Trust
me to say something if that occurs.
I'm no big friend of Brian, however changes
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw
On Fri, 30 Jul 1999, Doug wrote:
> Spent quite a bit of time today playing around with the newly
> repaired readdirplus option for nfs clients in -current. My thanks to Matt
> Dillon and Bill Paul. For those that don't remember, I'm trying to use
> amd/nfs client stuff on some freebsd web se
n 3 charaters and there was a comment or two
sprinkled about.
the code is actually pretty nifty and makes sense, but you need
to stare at it for a few hours before you can make heads or
tails of anything. the fact that nested macros used modify
variables in the calling function is really, urm.
On Mon, 2 Aug 1999, Alfred Perlstein wrote:
> } \
> if (fhlen != 0) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
> if ((nfsd->
bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \
! } \
right before the while(0) instead of the else clause with the
full bzero.
i'd rather get rid of the extra copying going on and since
previously it was filled with garbage from the rest of the RPC
structure i
On Tue, 3 Aug 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> > On Mon, 2 Aug 1999, Matthew Dillon wrote:
> >
> > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> >
> > This is a patch that Peter Wemm proposed however he had this:
> >
&g
ve included the patch again for reference. (Note: I didn't write
> this patch, refer back to the thread for that info).
>
> -Matt
any percievable performance gain? I doubt it...
-Alfred Perlstein - [bri...@rush.net|bri...@wintelc
\
(*(MP)->mnt_op->vfs_fhtovp)(MP, FIDP, NAM, VPP, EXFLG, CRED)
btw, since this seems to work... is it ok to pass in a NULL
sockaddr *? (nam)
thanks for all the help,
-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net]
systems administrator and programmer
Wintelcom - htt
On 3 Aug 1999, Assar Westerlund wrote:
> Alfred Perlstein writes:
> >
> > * At this point, this should never happen
> > */
> > /* ARGSUSED */
> > static int
> > nfs_fhtovp(mp, fhp, nam, vpp, exflagsp, credanonp)
> > register struct mount
On Wed, 4 Aug 1999, Peter Jeremy wrote:
> Oscar Bonilla wrote:
> >If anyone has any comments, suggestions, etc. I would appreciate it.
>
> Overall, I like the idea of NSS. But, having worked on Solaris 2.x
> for some time, we need to avoid some of the blunders Sun made: The
> biggest problem wi
On Wed, 4 Aug 1999, Niall Smart wrote:
> Olivia Cheriton wrote:
> >
> > Niall,
> >
> > VMware will support FreeBSD as a guest operating system, but unfortunately
> > we currently do not have plans to support FreeBSD as a host operating
> > system. I have noted your request of FreeBSD host suppo
Why does open() at "sys/kern/vfs_syscalls.c" line 1023 call
vfs_object_create() when vnopen() ("sys/kern/vfs_vnops.c" line 174)
already does so?
vfs_object_create checks for this and doesn't leak, but it looks
funny to me.
-Alfred Perlstein - [bri...@rush.net|bri..
On 4 Aug 1999, Assar Westerlund wrote:
> Alfred Perlstein writes:
> > I heard they have released the source to the kernel modules needed
> > to run it.
> >
> > why not port them over? :)
>
> I started looking at the kernel modules and porting them, however, I
On Wed, 4 Aug 1999, Milan Kopacka wrote:
> On Wed, 4 Aug 1999, Alfred Perlstein wrote:
>
> > > I started looking at the kernel modules and porting them, however, I
> > > must confess that I don't fully understand exactly what the linux
> > > kernel module d
On Mon, 9 Aug 1999, Doug wrote:
> Matthew Dillon wrote:
> >
> > : So, the big question is whether there is anything we can tune to
> > speed up
> > :the writes. The freebsd machines are NFS clients to the sun servers doing
> > :most of the web processing. Overall performance on the reads s
...
so does the various states that vnodes are in when called from
vfs_syscalls, such as the lseek syscall.
it's slighly confusing, if the vnode is locked for "access" calls
why is it not locked for attribute calls?
-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org]
1 - 100 of 1003 matches
Mail list logo
