On Thu, 17 Mar 2011, Jung-uk Kim wrote:
Both get_cyclecount(9) and cpu_ticks() do almost exactly the same
thing now assuming set_cputicker() is called with a correct function
before get_cyclecount() is used, which is true for x86, at least.
The only difference is get_cyclecount() may be inlined
On Fri, 18 Mar 2011, Kostik Belousov wrote:
On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote:
...
- set cputicker() has some design bugs. It assumes that the tick frequency
is the same across all CPUs, but the TSC is per-CPU. I have an old SMP
system with CPUs of different
On Sat, 19 Mar 2011, Bruce Evans wrote:
On Fri, 18 Mar 2011, Kostik Belousov wrote:
We definitely do not support configurations with different models of
CPUs in SMP, this is what Simmetric is about. Different as in frequency
or stepping.
...
Now there is even more asymmetry
in core
On Fri, 8 Apr 2011, Andriy Gapon wrote:
on 08/04/2011 03:00 Jeremy Chadwick said the following:
On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
As a generic question / observation, maybe we should just
implement 'errors=remount-ro' (or a reasonable facsimile) like Linux
has
On Tue, 31 May 2011 m...@freebsd.org wrote:
I am looking into potentially MFC'ing r212367 and related, that adds
drains to sbufs. The reason for MFC is that several pieces of new
code in CURRENT are using the drain functionality and it would make
MFCing those changes much easier.
The problem i
On Sat, 5 May 2012, Andriy Gapon wrote:
on 04/05/2012 18:25 John Baldwin said the following:
On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote:
on 03/05/2012 18:02 Andriy Gapon said the following:
Here's the latest version of the patches:
http://people.freebsd.org/~avg/zfsboot.patches
t hardware and
virtual clock oscillators that may be used to build timestamping and timer
functions (mostly the former).
I am not sure what sort of high resolution you are refering to but maybe
these will lead you in the right direction. Bruce Evans CCd - he may
have quite a bit that could be added
> On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote:
> > Hi.
> > I found some overhead code in /src/sys/net/if_ethersubr.c and
> > /src/sys/netgraph/ng_ether.c
> >
> > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
> > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN
luigi wrote:
> even more orthogonal:
>
> I found that copying 8n + (5, 6 or 7) bytes was much much slower than
> copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient,
> other cases are slow (turned into 2 or 3 different writes).
>
> The netmap code uses a pkt_copy routine that doe
jhb wrote:
> On Monday, August 20, 2012 10:46:12 am Mitya wrote:
> > ...
> > I propose this solution.
> >
> > In file /usr/src/include/net/ethernet.h add this lines:
> >
> > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) {
> > #if defined(__i386__) || defined(__amd64__)
> >
mitya wrote:
> 22.08.2012 05:07, Bruce Evans íàïèñàë:
> >> On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote:
> >>> Hi.
> >>> I found some overhead code in /src/sys/net/if_ethersubr.c and
> >>> /src/sys/netgraph/ng_ether.c
> >>>
&g
>From owner-freebsd-...@freebsd.org Thu Aug 23 10:58:03 2012
Delivered-To: freebsd-...@freebsd.org
Date: Wed, 22 Aug 2012 23:52:44 +0200
From: Luigi Rizzo
To: John Baldwin
References: <50324db4.6080...@cabletv.dp.ua>
<201208220802.14588@freebsd.org>
<201208221521.0695
luigi wrote:
> On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote:
> > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote:
> > > On 22 August 2012 05:02, John Baldwin wrote:
> > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote:
> > > >> Hi,
> > > >>
> > > >> What
On Fri, 1 Feb 2008, Alexander Motin wrote:
Robert Watson wrote:
It would be very helpful if you could try doing some analysis with hwpmc --
"high resolution profiling" is of increasingly limited utility with modern
You mean "of increasingly greater utility with modern CPUs". Low resolution
k
On Mon, 4 Feb 2008, Alexander Motin wrote:
Kris Kennaway wrote:
You can look at the raw output from pmcstat, which is a collection of
instruction pointers that you can feed to e.g. addr2line to find out
exactly where in those functions the events are occurring. This will often
help to track
On Tue, 12 Feb 2008, Andriy Gapon wrote:
on 12/02/2008 15:11 Bruce Evans said the following:
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
3.1. for a fresh buf getlbk would assign the following:
bsize = bo->bo_bsize;
offse
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
2.3. this code passes to bread blkno that is calculated as 4*sector,
where sector is a number of a physical 2048-byte sector. [**]
[**] - I think that this is a requirement of buffcache system, b
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
on 06/02/2008 18:29 Andriy Gapon said the following:
Small summary of the above long description.
For directory reading fs/udf performs bread() on a (underlying) device
vnode. It passes block num
>Can nohup really prevent processes from trapping SIGHUP? I thought it
>just set the SIGUP handler to discard and hoped for the best.
It's normally a bug to catch ignored signals. Daomons that reread config
files when they receive a signal may be counterexamples. OTOH, they
probably shouldn't be
>/*
> * XXX the data is 16-bit due to a historical botch, so we use
> * magic 16's instead of ICU_LEN and can't support 24 interrupts
> * under SMP.
> */
>intr = *(int16_t *)data;
>if (cmd != MEM_RETURNIRQ && (intr < 0 || intr >= 16))
>
>Once securelevel has been increased, no process can decrease it because
>kernel always refuse decreasing it. This is inconsistent with the
>manual page of init:
>
> The kernel runs with four different levels of security. Any super-user
> process can raise the security level, but only ini
>> There used to be security holes that allowed root to lower `securelevel'
>> using init. Rev.1.9 defends against any undiscovered holes.
>
>How about following change?
OK.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, 6 May 2010, Kostik Belousov wrote:
On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote:
...
Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired
both in kern_getrusage() and could be a problem in multithreaded process
with intensive performance acco
On Tue, 6 Jul 2010, Sean Bruno wrote:
On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote:
Found this lying around the Yahoo tree this week. Basically it allows
you to activate, reset and deactivate profiling with the '-f" flag.
I want something like this, but this implementation has too man
On Wed, 21 Jul 2010, Jaakko Heinonen wrote:
On 2010-07-20, Garrett Cooper wrote:
I ran into an issue last night where apparently several apps make
faulty assumptions w.r.t. whether or not access(2) returns functional
data when running as a superuser.
New implementations are discourag
On Tue, 20 Jul 2010, Garrett Cooper wrote:
Hi Hackers,
I ran into an issue last night where apparently several apps make
faulty assumptions w.r.t. whether or not access(2) returns functional
data when running as a superuser.
POSIX says:
In early proposals, some inadequacies in the access(
On Wed, 21 Jul 2010, Garrett Cooper wrote:
On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans wrote:
- See a recent PR about unifdefed CAPABILITIES code in vaccess(). ?(The
?comment says that the code is always ifdefed out, but it now always
?unifdefed in.) ? I don't quite understand this
On Fri, 24 Oct 2008, Thierry Herbelot wrote:
the [SUBJ] file contains the following extract (around line 705) :
* Default to PAGE_SIZE after much discussion.
* XXX: min(PAGE_SIZE, vp->v_bufobj.bo_bsize) may be more correct.
*/
sb->st_blksize = PAGE_SIZE;
which arrived around fo
>Am I understand this right: if I configure my PCI card to an
>exclusive interrupt, and then turn on CY_PCI_FASTINTR, I'll get
>rid of ``silo overflows'' on it.
Except in -current, where CY_PCI_FASTINTR is broken (it has no effect).
>Just out of curiosity.
>What is the ``interrupt latency in the
>I have multiprocessor machine:
>
>matherboard SOYO 5TX2/X5 with 2 intel 166 proceccors
>multiport card Cyclades Cyclom 8Yep
>
>Kernel config:
>
>options SMP # Symmetric MultiProcessor Kernel
>options APIC_IO # Symmetric (APIC) I/O
>options NCPU=2
>>There seems to be a problem with nested locks. What was the panic
>>message?
>
>I have the same problem with my Cyclom Ye cards (both the isa & pci
>variety)
>
>The kernel panics with:
>
>panic messages:
>---
>panic: rslock: cpu: 0, addr: 0xf026a15c, lock: 0x0001
>mp_lock = 0001; cpuid
>I commented out the SMP and FAST code, rebuilt the kernel from scratch and
>the panic still occurs. Is there other code that should be disabled? Is
>this fixed in 3.2? Why are there evil macro's in my computer? Why am I
>asking so many questions?
I committed a proper fix in /sys/i386/isa/cy.c
>dfr> If I understand this correctly, you are suggesting that we program timer0
>dfr> so that we only take interrupts when a finetimer is due to fire? If so,
>dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me
>dfr> uneasy, even though most would return without doing any
>this is problematic.
>
>you cannot add a new element before the pending firing because you can't
>tell how far into the present trigger you are.
This is not a problem for readable counters like the i8254. The problem
for the i8254 is that reading and writing it takes a long time (perhaps
5 usec
On Wed, 31 May 2006, Attilio Rao wrote:
2006/5/31, Suleiman Souhlal <[EMAIL PROTECTED]>:
Nice work. Any chance you could also port it to amd64? :-)
Not in the near future, I think. :P
It is not useful for amd64. An amd64 has enough instruction bandwidth
to saturate the L1 cache using 64-bi
On Sun, 15 Oct 2006, Cheng-Lung Sung wrote:
System: FreeBSD.csie.nctu.edu.tw 6.1-STABLE FreeBSD 6.1-STABLE #9: Thu May 11
14:31:45 CST 2006 [EMAIL PROTECTED]:/home/usr.obj/usr/src/sys/FREEBSD i386
Description:
- sys/sem.h has included sys/ipc.h, which includes sys/_types.h
but it (and
[This is still being sent to too many mailing lists since I don't know
which ones it should go to except gnats.]
On Mon, 16 Oct 2006, John Baldwin wrote:
Including sys/types.h would add lots of namespace pollution which
sys/ipc.h and sys/sem.h are trying hard to avoid. sem.h is trying too
ha
On Tue, 17 Oct 2006, Cheng-Lung Sung wrote:
On Mon, Oct 16, 2006 at 02:31:24PM -0400, John Baldwin wrote:
Is this better?
...
Thanks, I didn't go through the whole sem.h.
Also, it seems we should put these parts before 'sturct semid_ds'.
or say, after we include sys/ipc.h (which inclu
On Tue, 6 Feb 2001, Josef Karthauser wrote:
> I'm wondering what's changed recently to cause vmware2 running on
> the linuxemu to lose a lot of performance with disk I/O.
Use of cmpxchg and possibly other SMP pessimizations.
> A couple of weeks ago I could boot win2000 under vmware2 in a matter
On Wed, 7 Feb 2001, Josef Karthauser wrote:
> On Wed, Feb 07, 2001 at 08:56:14PM +, Josef Karthauser wrote:
> > On Wed, Feb 07, 2001 at 08:26:15PM +0100, Dag-Erling Smorgrav wrote:
> > > Brian Somers <[EMAIL PROTECTED]> writes:
> > > > Indeed. I've been doing a ``make build'' on an OpenBSD-c
On Sat, 24 Mar 2001, Dima Dorfman wrote:
> I tried to export this stuff in struct statfs, but ran into a problem:
> I'd need the complete definitions of _args in , but I
> can't include, e.g., because the latter includes the
> former ()!
mount.h used to know too much about all sorts of filesyst
On Sun, 25 Mar 2001, Peter Pentchev wrote:
> > Only mount_foofs can reasonably know about the options for foofs.
> > perhaps mount(8) could fork-exec mount_foofs(8) to print options for
> > foofs.
>
>
> Or could mount(8) invoke a couple of sysctl's to get a string representation
> of each mount
On Mon, 14 May 2001, Dima Dorfman wrote:
> Is there a reason the definitions of the MIN() and MAX() macros in
> sys/param.h are under an '#ifndef _KERNEL'? Quite a few files in the
It is to inhibit use of these macros. The {i,,l,lu,q}{max,min} inline
functions are supposed to be used instead.
On Wed, 30 Mar 2005, David Schultz wrote:
On Wed, Mar 30, 2005, Peter Jeremy wrote:
On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
Later in that thread they discuss skipping the restore state to make
things faster. The minimum buffer size they say this will be good for
is between 2-4k. D
On Thu, 31 Mar 2005, Peter Jeremy wrote:
On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote:
I still
think fully lazy switching (c2) is the best general method.
I think it depends on the FP workload. It's a definite win if there
is exactly one FP thread - in this case the FPU state
On Thu, 31 Mar 2005, Matthew Dillon wrote:
I didn't mean to get into the kernel's use of the FPU, but...
All I really did was implement a comment that DG had made many years
ago in the PCB structure about making the FPU save area a pointer rather
then hardwiring it into the PCB.
ISTR writi
On Fri, 1 Apr 2005, Matthew Dillon wrote:
:>The use of the XMM registers is a cpu optimization. Modern CPUs,
:>especially AMD Athlon and Opterons, are more efficient with 128 bit
:>moves then with 64 bit moves. I experimented with all sorts of
:>configurations, including the use
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote:
> I recently ran into revelant problem with /dev/stdout, while
> working on some software under linux that expected /dev/stdout as an
> argument instead of using stdout.
>
> Using the device file breaks, if the process is suid to a non
On Mon, 18 Sep 2000, Marc Tardif wrote:
> > 0cicuta/home/babolo(9)#dd of=/dev/wd0s2 if=/dev/zero bs=660b
> > 1cicuta/home/babolo(11)#od -b /dev/wd0s2
> [ snip ]
> > Why I use 2.2.7 for test?
> > Because of my lovely 4.1-STABLE is extremly unstable with content of
> > ad0s2 (wd0s2) above and silen
On Sun, 11 Apr 2004, Roman Kurakin wrote:
> I remind you that now I have two problems. First one that FreeBSD uses
> wrong assumption about which device should be CHS and which LBA:
>
> if (!ad_version(atadev->param->version_major) ||
> !(atadev->param->atavalid & ATA_FLAG_54_58) || !lbasize)
> at
On Thu, 17 Jun 2004, Cyrille Lefevre wrote:
> is there any reasons to hide timeradd() and co in
> from the kernel space (! _KERNEL) ?
Yes. This prevents them being used in the kernel. They are compatibility
cruft for NetBSD. In the kernel the corresponding interfaces are
spelled timevaladd(),
On Thu, 30 Aug 2001, Martin Blapp wrote:
> Searching the freebsd mailinglists I have seen that you also suffering
> under this problem on 4.X. STABLE:
I now remember your old mail about this. I (implicitly) suggested a fix,
but apparently no one tried it:
> On Thu, 21 Jun 2001, Martin Blapp wr
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> I wrote:
>
> > The problem here is that CPU#1 fails to hold clock_lock while setting
> > clkintr_pending, causing i8254_offset to be stepped twice, first due
> > to clkintr_pending, then due to i8254_lastcount being larger than count.
>
> With this p
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> > I see (amost).
> >
> > Please format the macro the same as the other macros in the file.
>
> Index: apic_vector.s
> ===
> RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
> retrie
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
> For RELENG_4, which uses Xintr0, this problem is reduced by adding the
> clkintr_pending variable (cf. revision 1.134 of clock.c and revision
> 1.38 of apic_vector.s)
>
> Looking more at the code, I now see that clkintr_pending is never set
> in -cur
On Tue, 4 Sep 2001, Maxim Sobolev wrote:
> > [neither Maxim Sobolev nor Brent Verner wrote]
> > In message <[EMAIL PROTECTED]>, Brent Verner writes:
> > >#include
> > >
> > >I've done a /cursory/ look over how this v_tag is used. I'm not sure
> > >this is a simple/clean as you propose, since th
On Sat, 8 Sep 2001, Chris Costello wrote:
> On Saturday, September 08, 2001, Poul-Henning Kamp wrote:
> > No actually not, I want something short and predictable like
> > "VT_CODA".
>
>How about my second suggestion: making v_tag point to
> mp->mnt_stat.f_fstypename, or a copy thereof?
Good,
On Sat, 15 Sep 2001, Matt Dillon wrote:
> I'm redirecting this to freebsd-hackers.
>
> Ok, I've comitted a new set of changes to libatm. Please check them out.
> When we get a format that enough people are happy with we can start
> converting the other libraries. I'm not particu
On Wed, 10 Sep 2003, Eno Thereska wrote:
> In FreeBSD 4.4, I am noticing a huge number of calls
> to ffs_fsync() (in /sys/ufs/ffs/ffs_vnops.c)
> when running a benchmark like Postmark.
>
> ffs_fsync() flushes all dirty buffers with an open file
> to disk. Normally this function would be called
> e
On Tue, 21 Oct 2003, Luigi Rizzo wrote:
> both -current and -stable have the following snippet of code in
> sys/dev/syscons/syscons.c:scclose():
>
> {
> ...
> int s;
>
> if (SC_VTY(dev) != SC_CONSOLECTL) {
> ...
> s = spltty();
>
On Mon, 4 Feb 2002, Michal Mertl wrote:
> Did you look at the patch by Bruce at
> http://groups.yahoo.com/group/freebsd-current/message/39605 ?
>
> Bruce, is it still fresh in your memory? Can you comment on the patch -
> can it be commited in some form?
I haven't done anything to clean up the p
On Mon, 4 Feb 2002, Mike Silbersack wrote:
> On Tue, 5 Feb 2002, Bruce Evans wrote:
> > I haven't done anything to clean up the patch. I hope the problem
> > will go away in future versions of gcc (align the stack at runtime in
> > the few routines that actually ne
On Tue, 5 Feb 2002, Nik Clayton wrote:
> On Tue, Feb 05, 2002 at 05:01:29PM +1100, Bruce Evans wrote:
> > My patch is not suitable for committing verbatim. It has 2 or 3 XXX's.
>
> Do you make these patches available anywhere, so that other people can
> look over them an
On Tue, 5 Feb 2002, Mike Silbersack wrote:
> On Tue, 5 Feb 2002, Bruce Evans wrote:
> > foo:
> > pushl %ebp
> > movl %esp,%ebp
> > subl $8,%esp# <- extra instruction for alignment (for foo)
> > addl $-12,%esp # <-
On Mon, 25 Feb 2002, David Malone wrote:
> I note that in the footnotes for getgrgid, in the section for "issue
> 6" of the standard:
>
> The requirement to include has been removed.
> Although was required for conforming
> implementations of previous POSIX specifications, it
On Thu, 14 Mar 2002, ozan s. yigit wrote:
> > Add the -ffloat-store flag to your compilation flags (or
> > add -msoft-float).
>
> that really means for this compiler on certain platforms, you
> can have slow and correct or fast and incorrect, but NOT fast
> and correct.
I think fast and correct
On Fri, 24 May 2002, Archie Cobbs wrote:
> I'm trying to debug a mbuf corruption bug in the kernel. I've added
> an mbuf sanity check routine which calls panic() if anything is amiss
> with the mbuf free list, etc. This function runs at splimp() and if/when
> it calls panic() the cpl is still at
On Thu, 15 Aug 2002, Maxim Sobolev wrote:
> When implementing ability to switch interface into promisc mode using
> ifconfig(8) I've stumbled into the problem with already exhausted
> space in the `short if_flags' field in the ifnet structure. I need to
> allocate one new flag, while we already h
On Sat, 17 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
> On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote:
> >> [skip]
> >>>
> >>> Fdisk should print these values, at least optionally, since they are needed
> >>> for debu
On Thu, 3 Oct 2002, Mark Santcroos wrote:
> I have an almost-ready patch that implements linux_read() syscall. This
> will check if we are reading from a raw disk and in that case it will
> enlarge the read() to the next sector boundary. I have it working in the
> kernel but I have problems retur
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Mark Santcroos writes:
> >On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote:
> >> Unbreaking block devices would be a better solution. Without buffering,
> >>...
> >
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bakul Shah writes:
> >How hard would it be to bring back block devices without GEOM?
>
> Not at all hard, pretty trivial in fact.
The easiest way is to restore the old code and use a minor number hack or
ioctl to enab
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
> Worst case you will have the option to use:
>
> options NOGEOM
> options vinum
A NOGEOM option would be as acceptable as a NOFFS option for turning off
forcing of the one true file system down everyone's throats.
Bruce
To Unsubscribe:
On Sat, 5 Oct 2002, Peter Wemm wrote:
> Bruce Evans wrote:
> > On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
> >
> > > Worst case you will have the option to use:
> > >
> > > options NOGEOM
> > > options vinum
> >
> > A NOGEOM
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
> On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote:
> > To be totally correct, you will need to:
> >
> > #ifdef _POSIX_REALTIME_SIGNALS
> > #if (_POSIX_REALTIME_SIGNALS != -1)
> >
> > ...
> >
> > #endif
> > #endif
> >
> >
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
> Earlier this year on the FreeBSD hackers mailing list:
>
>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers
>
> I was advised by Terry Lambert to use:
> #ifdef _POSIX_REALTIME_SI
On Thu, 10 Oct 2002, Terry Lambert wrote:
> Bruce Evans wrote:
> > In Standard C, this is equivalent to the non-verbose version:
> >
> > #if _POSIX_REALTIME_SIGNALS != -1
> > ...
> > #endif
> >
> > since if _POSIX_REALTIME_SI
On Thu, 10 Oct 2002, Terry Lambert wrote:
> Bruce Evans wrote:
> > _POSIX_REALTIME_SIGNALS is undefined:
> > Apparently the same as when it is defined to 0, except you cannot assume
> > that anything related to it works until you call sysconf(), so you must
> > n
On Thu, 10 Oct 2002, Craig Rodrigues wrote:
> On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote:
> > Perhaps because they wanted you to use sysconf() instead of these mistakes.
>
> Well in the case of ACE, it is a C++ library that is compiled on
> platforms which m
On Fri, 11 Oct 2002, Terry Lambert wrote:
> Bruce Evans wrote:
> > > I know it's not fashionable to write code that's portable to
> > > compilers other than GCC, but even if FreeBSD is going to ignore
> > > portability for it's own source code, it&#
On Tue, 12 Nov 2002, Tomas Pluskal wrote:
> I believe that everybody here knows about the "slow msdosfs" problem, that
> is AFAIK caused by implementation without clustering.
Which problem. msdosfs has a number of small problems. Mostly they don't
matter.
> For me this is very annoying, becaus
>Can nohup really prevent processes from trapping SIGHUP? I thought it
>just set the SIGUP handler to discard and hoped for the best.
It's normally a bug to catch ignored signals. Daomons that reread config
files when they receive a signal may be counterexamples. OTOH, they
probably shouldn't b
>/*
> * XXX the data is 16-bit due to a historical botch, so we use
> * magic 16's instead of ICU_LEN and can't support 24 interrupts
> * under SMP.
> */
>intr = *(int16_t *)data;
>if (cmd != MEM_RETURNIRQ && (intr < 0 || intr >= 16))
>
>> There used to be security holes that allowed root to lower `securelevel'
>> using init. Rev.1.9 defends against any undiscovered holes.
>
>How about following change?
OK.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>Once securelevel has been increased, no process can decrease it because
>kernel always refuse decreasing it. This is inconsistent with the
>manual page of init:
>
> The kernel runs with four different levels of security. Any super-user
> process can raise the security level, but only in
> > In file included from
> > /usr/src/sys/boot/i386/libi386/../../../sys/signal.h:236,
> > from
> > /usr/src/sys/boot/i386/libi386/../../../sys/param.h:90,
> > from
> > /usr/src/sys/boot/i386/libi386/aout_freebsd.c:29:
> > /usr/src/sys/boot/i386/libi386/../../../
> In unistd.h we have definitions for getopt, optarg, optind, opterr, and
> optopt.
These are the standard POSIX (.2?) declarations.
> The things I propose to add to unistd.h are the following:
> struct option
> {
> char*name;
> int has_arg;
> int *flag;
> in
On Sun, 23 Jan 2000, Warner Losh wrote:
> : This is what I asked for, when I asked for "other specification". Could
> : you provide the chapter/verse number of where POSIX spec contradicts the
> : man pages? It will help me make my case on the TCL forum, since the TCL
> : developers remain un
On Wed, 26 Jan 2000, Yevmenkin, Maksim N, CSCIO wrote:
> > > I've just found that read from /dev/bpfX never return
> > EAGAIN/EWOULDBLOCK.
> > > It means that when you do a non blocking read and there is
> > no data you will
> > > always get 0.
> [ untested fix removed :) ]
>
> Yes, it works.
On Tue, 30 May 2000, Garrett Wollman wrote:
> <<[EMAIL PROTECTED]> said:
>
> > i know that :) i guess my questions were
> > 1) why the same piece of code duplicated in all ``mount_xxx'' utilities?
>
> Because the original loadable module system held strongly to the
> religion that the kernel sh
On Wed, 31 May 2000, Joy Ganguly wrote:
> what is the significance of QUEUE_VMIO buffer (struct buf) queue ?? as
> far as i could see they are not used at allbut maybe i am wrong.
It signifies bitrot. Its use was removed more than 5 years ago in
rev.1.35 of sys/kern/vfs_bio.c, but its defi
On Thu, 1 Jun 2000, G.B.Naidu wrote:
> I am having problems with DDB while setting breakpoints in the kernel. I
> entered the DDB by giving kernel -d at boot prompt. After that I tried to
> set break point at ip_output() by giving "b ip_output". But it complains
> saying that "sumbol not found".
92 matches
Mail list logo
