scripting language, not a general-purpose one.
BTW, most of the Perl scripts we had were rewritten in C, not sed / awk.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
Nathan Whitehorn writes:
> Dag-Erling Smørgrav writes:
> > I'm not sure I understand what you mean (or rather, how it would
> > help the tinderbox). What *would* help would be an easy way to
> > determine, *before* trying to build it, whether a specific kernel
>
urrent bottleneck in BSD grep is the memchr() that looks for
'\n' in the input buffer.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsu
orrect line is "device md", but mdconfig(8) will automatically load
the module, so you don't need it.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
t an absolute. I think what we are doing
> isn't a problem for 99.999% of use cases.
On the rare occasions where I use sysinstall, I usually find that prompt
annoying... but I almost broke a CD drive once by ejecting the tray
with the enclosure's dust cover half clo
Gabor PALI writes:
> Dag-Erling Smørgrav writes:
> > Gabor PALI writes:
> > > Sorry for chiming in, just a quick idea. If you find the "get a
> > > high-level language that compiled to C" idea good,
> > I don't think it's a good idea
>
erbox). What *would* help would be an easy way to determine,
*before* trying to build it, whether a specific kernel config is
appropriate for a specific target. Can you think of an easier way to do
this than to scan the config for the "machine&q
"b. f." writes:
> At r211506, 'grep -wq' does not seem to work properly (in the very
> least, it is not the same as with GNU grep),
"Does not seem to work properly" is not a very useful statement. The
least you could do is provide an example.
DES
-
Gabor PALI writes:
> Sorry for chiming in, just a quick idea. If you find the "get a
> high-level language that compiled to C" idea good,
I don't think it's a good idea, and I don't understand why this thread
seems stuck in that rut.
DES
--
Da
bles other languages they already know, than Lisp, which doesn't.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mai
ught
> the system time for gnugrep and bsdgrep would be almost the same.
Two reasons:
1) BSD grep does tons of unnecessary memory-to-memory copy operations in
grep_fgetln().
2) GNU grep has its own highly optimized regex code.
DES
--
Dag-Erling Sm
is no way to fix this with the current tinderbox code.
MHO is that the entire powerpc64 thing is very poorly thought out.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
rr.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Adrian Chadd writes:
> I've just looked at grep_fgetln(). Surely memchr() isn't required there.
Of course it is, how else are you going to locate the '\n'? OTOH, I'm
not sure grep_fgetln() is needed at all.
DES
--
Dag-E
x27;%x' expects type 'unsigned
int', but argument 4 has type 'vm_offset_t'
/src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned
int', but argument 3 has type 'register_t'
*** Error code 1
Stop in /obj/powerpc.powerpc64/src/
his is not about "what we expect people to do" but about "what I expect
*you*, an experienced FreeBSD committer, to do" :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/
and moreover FreeBSD HPC,
Not "FreeBSD clusters", but "*the* FreeBSD cluster", i.e. the .f.o
machines hosted by Y!.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailma
0.000 100.00% regexec [38]
The culprit seems to be the first memchr() in grep_fgetln(). For some
reason, even with -O2, it is not inlined:
% echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin
/usr/obj/usr/src/usr.bin/grep/grep | grep memchr
0x0000000000402
"V. T. Mueller, Continum" writes:
> Dag-Erling Smørgrav writes:
> > Based on my 12 years of experience in this project, you are very,
> > very wrong.
> An 'argumentation' like the above is simply a killer phrase that ends
> every discussion.
An 'ar
grep - expecting correctness and speed.
Based on my 12 years of experience in this project, you are very, very
wrong.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
this particular case I think
> it's pretty obvious that I'm either alone, or in a very non-vocal
> group; so c'est la vie.
"This is madness!"
"Madness? This... is... CURRENT!"
DES
--
Dag-Erling Smørgrav - d...@des.no
__
ult in people actually running the
> profiling tools which pointed to the buffering as the number one thing
> to fix.
There is a lesson here: people who are unsatisfied with the performance
of ${TOOL} should profile it before they start a flamefest on -current.
DES
--
Dag-E
cense for us.
Does that really matter? We're not going to start building releases
with icc, are we?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
by the user (the "TiVo clause"), although the bits that
are most commonly used in embedded devices (Linux itself and busybox)
are still under GPLv2.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://
defined as uint64_t on sparc64 and sun4v,
and in sys/boot as unsigned long int, which is the correct size on both
32-bit and 64-bit machines (assuming I32LP64).
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Dimitry Andric writes:
> Dag-Erling Smørgrav writes:
> > No, what is used is a variant of method 1 *on top of* method 2 for a
> > very specific case. You need "a special version of clang" (method 2)
> > anyway to support cross-building.
> Eventually, clang s
ng using for the build32 stage on
> amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
> appended.
No, what is used is a variant of method 1 *on top of* method 2 for a
very specific case. You need "a special version of clang" (method 2)
an
"Sean C. Farley" writes:
> Dag-Erling Smørgrav writes:
> > Did you actually test your patch? It makes absolutely no measurable
> > difference.
> Yes, I saw a reduction,
I didn't...
DES
--
Dag-Erling Smørgrav - d...@des.no
__
lone
language, but as an embeddable scripting engine. We could easily create
our own scripting language based on lua with FreeBSD-specific functions,
and there would be no fear of interfering with third-party software,
because it wouldn't be called lua.
DES
--
Dag-Erl
e, try to mmap(2) it first, and if
that fails, fall back to the plain buffered read(2) method.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
"Sean C. Farley" writes:
> This should trim some time off BSD grep.
Did you actually test your patch? It makes absolutely no measurable
difference.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mail
Ivan Voras writes:
> Dag-Erling Smørgrav writes:
> > Marius Nünnerich writes:
> > > I did not think of a new GEOM class that looks like glabel but one
> > > that has no metadata stored on disk . It is then activated and
> > > controlled by loader.co
es).
As you would know if you had followed the discussion about WD EARS
disks, gnop does what you want and is currently the recommended
solution.
I am looking into a permanent solution and would appreciate if people
held off on this for a couple of weeks.
DES
--
Dag-Erling Smørgrav -
egacy/usr/lib -o strfile strfile.o -legacy
> Syntax error: end of file unexpected (expecting ")")
> *** Error code 2
>
> Stop in /src/games/fortune/strfile.
Does anyone have any idea what caused this? The exact same error
occurred on all platf
ed into CAM.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
in gnu grep.
> Ok, thanks, then I'll just document it.
Uh, no. GNU grep's behavior is consistent with just about everything
else that has --include / --exclude options, e.g. tar and rsync. Please
change BSD grep's behavior to match GNU
Dag-Erling Smørgrav writes:
> Andriy Gapon writes:
> > Michael Butler writes:
> > > I have a custom kernel for my laptop which uses ATA_CAM rather than
> > > the now aging ATA driver ..
> > You do realize that ATA_CAM just (well, mostly) introduces a wrapper
>
ly for legacy drives, but since Micahel's panic message contains
"current process = 12 (irq15: ata1)", his BIOS is probably in legacy
mode.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.f
e bug would affect fetching from servers requiring
> authentication, so I've made the same fix there as well.
OK, I'll trust your analysis and commit this do head, then ask portmgr
to do an exp run with the patch.
DES
--
Dag-Erling Smørgrav - d...@des.no
YAMAMOTO Shigeru writes:
> 'advertise' is added at r209607 and r209609.
>
> please chone one of them.
I don't know what "chone" means.
The tinderbox uses cvsup and is therefore at the mercy of the whims and
idiosyncracies of the cvs exporter.
DES
--
y nasty part of it :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
"M. Warner Losh" writes:
> I went ahead and used pidfile_close in this context because that's
> what's recommended in the man page. I know it is likely redundant,
> but I thought better safe than sorry...
agreed...
DES
--
Dag-
Anton Shterenlikht writes:
> However, I've got this set on 3 ia64 boxes.
> On two of them I don't have this lzma problem.
Because they either don't have liblzma installed from ports, or they
have a different version that works.
DES
--
Dag-Erling S
Anton Shterenlikht writes:
> # make buildenv
> Entering world for ia64:ia64
> # env
> LIBRARY_PATH=/usr/local/lib
where does this come from? Your .bashrc or something?
% make buildenv
% unset LIBRARY_PATH
then run the cc command again.
DES
--
Dag-Erling Smørgrav -
Dag-Erling Smørgrav writes:
> This confirms my suspicion that ld is picking up the wrong liblzma:
> > attempt to open /usr/local/lib/liblzma.a succeeded
> but I still can't figure out why.
Uh, I must be blind. It uses /usr/local/lib/liblzma.a because
-L/usr/local/lib was
% env
and also show us your make.conf and src.conf?
Do you have any gcc ports installed?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
efrom() is sufficient, since the only resource held by the
pidfile that would persist across execve() is the file descriptor (and
hence the lock).
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.
Garrett Cooper writes:
> It leaves stray unused lockfiles in the directory:
That's normal and harmless.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-cu
it again with -Wl,--verbose in addition to -v? Like
this: cc -static -v -Wl,--verbose -o rescue ...
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscri
"M. Warner Losh" writes:
> Dag-Erling Smørgrav writes:
> > "M. Warner Losh" writes:
> > > Maybe the real problem is that devd locks the file, then dies. The
> > > file remains locked, so the flopen is failing with EWOULDBLOCK.
> > The lock
pto -lm
Look again, your command line is mangled. For instance, the "r" in
"realpath.lo" is missing and the "l" in "fsck_ffs.lo" has been replaced
with a space.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
f
eck the ownership of that file? Did you run
buildworld as root and buildenv as a regular user?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
Dag-Erling Smørgrav writes:
> - Under flock semantics (flock(2) locks), the lock is released when
>*all* file descriptors the process holds for that file is closed.
are, even, and sorry for the horrid quoting.
DES
--
Dag-Erling Smørgrav - d...@
Dag-Erling Smørgrav writes:
> "M. Warner Losh" writes:
>> Maybe the real problem is that devd locks the file, then dies. The
>> file remains locked, so the flopen is failing with EWOULDBLOCK.
>
> The lock is released when the process that holds it terminates.
&
cit assumption that
> flock will release the lock when a process terminates... That isn't
> the case in BSD
Yes it is.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailm
"M. Warner Losh" writes:
> Why not fix pidfile_open to not return a file handle when the PID
> doesn't match?
It doesn't. If it can't lock the file, or if fstat(2) fails after it
has locked the file, it returns NULL.
DES
--
Da
you got was completely unrelated, and that patch does
*nothing* that will help Anton. Your problem seems to be that ar(1)
somehow got built before libarchive, while Anton's problem is that gcc
is picking up the wrong version of liblzma.
DES
--
Dag-Erling Smørg
ake the cc comand line that failed and run it again with
the -v option and show us the output.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
wered my questions.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Anton Shterenlikht writes:
> Dag-Erling Smørgrav writes:
> > I expect this to produce the same error as before; if not, there is
> > something seriously wrong.
> the error is different...
>
> echo fsck_ffs: /usr/lib/libc.a /usr/lib/libufs.a >> .depend
> cc -O1
Ed Schouten writes:
> In my opinion, we should just rename mailwrapper to whateverwrapper
> and list the lpr programs in there as well.
Take a look at /etc/alternatives in any Debian-based Linux distro...
DES
--
Dag-Erling Smørgrav - d...@
un (cc -static ...), add -v
before -static (cc -v -static ...) and run it.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &q
Anton Shterenlikht writes:
> Dag-Erling Smørgrav writes:
> > Anton Shterenlikht writes:
> > > Did you mean /usr/local/lib/liblzma.a ?
> > No, I meant /usr/lib/liblzma.a.
> This file doesn't exist on either of my other two ia64 boxes, where
> this problem is n
Dag-Erling Smørgrav writes:
> On a machine where make buildworld failed, do
>
> % cd /usr/src
> % make buildenv
> % echo $PATH
> % which cc
> % cc --version
> % strings $(which cc) | grep -w tmp
instead of that last line:
% cc -dumpspecs
(still in buildenv)
DES
--
such file
> #
>
> Did you mean /usr/local/lib/liblzma.a ?
No, I meant /usr/lib/liblzma.a.
Do you have any other compilers installed?
On a machine where make buildworld failed, do
% cd /usr/src
% make buildenv
% echo $PATH
% which cc
% cc --version
% strings $(wh
witch to .o on other platforms?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Next, do
% nm /usr/obj/usr/src/lib/liblzma/liblzma.a | grep physmem
and show us the result. While you're at it, do this as well:
% nm /usr/lib/liblzma.a | grep physmem
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mai
hey will not solve his problem. All they
will do is muddle the tracks and reduce our chances of ever finding out
what the problem really is.
> Praying for you,
I'd rather you didn't.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-cu
correct revision numbers? Have you tried checking out a clean copy
of r209203 and building + installing that before trying to build r209240
again?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.free
hell.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rs are in /usr/src/include.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
process after applying patches which you know affect some
headers.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make buildincludes
% make installincludes
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
which builds both libedit and sh) before I
posted it.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebs
uld go into src.conf(5)?
I'll leave that to someone who knows why it doesn't work :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, s
can't, say, read data from a file into a buffer and then
pass that buffer to iconv, because the buffer is not const (otherwise
you couldn't have read data into it). That seems like a pretty
fundamental flaw.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
Alexander Best writes:
> Dag-Erling Smørgrav writes:
> > The problem is that "/usr/src/" is not a prefix of "/usr/src".
> ah i see. would something like
>
> empty(.CURDIR:M/usr/src*) instead of empty(.aCURDIR:M/usr/src/*) work?
I think so. My hypothesis is
x of "/usr/src".
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Garrett Cooper writes:
> 1. Script doesn't check to see whether or not it has write access (and
> doesn't catch some errors):
IMHO, any shell script which is intended to be used more than twice
should start with "set -e".
DES
--
Dag-Erl
Alexander Best writes:
> Dag-Erling Smørgrav writes:
> > Alexander Best writes:
> > > .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) &&
> > > exists(/usr/local/bin/gcc44)
> > > CC = gcc44
> > > CXX = g++44
> >
Alexander Best writes:
> .if empty(.CURDIR:M/usr/src/*) && empty(.CURDIR:M/usr/obj/*) &&
> exists(/usr/local/bin/gcc44)
> CC = gcc44
> CXX = g++44
> CPP = cpp44
> .endif
What happens when .CURDIR = /usr/src?
DES
--
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Those are freestanding environments, where printf() and puts() don't
> > exist as far as the C standard is concerned.
> Most controller environments have some kind of libc.
They are still freestanding environment
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > The only way you can tell that gcc did it is if you break the rules,
> > such as by defining your own version of printf() or puts().
> Our loader stages do this for good reasons. And in microcontroller
> programming (
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > Amazing - this is one of the things which can get nasty if you try
> > > some kind of microtuning.
> > Only if you break the rules. Bad code is always bad, even if it
> > s
Bernd Walter writes:
> Amazing - this is one of the things which can get nasty if you try some
> kind of microtuning.
Only if you break the rules. Bad code is always bad, even if it
sometimes works by accident.
DES
--
Dag-Erling Smørgrav - d...@
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > I'm not sure when removing a memset is allowed.
> > Always, if the compiler can determine that the data will not be used
> > later.
> I'm at least sure that the compiler
You can't pass a volatile pointer to memset.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
o the right thing anymore.
In that case, we can simply cd /usr/src/usr.bin/clang/tblgen && make &&
make install.
> Do we really want to install an application like tblgen?
Yes.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-c
Tijl Coosemans writes:
> Dag-Erling Smørgrav writes:
> > #define FORCE_ASSIGN(type, var, value) \
> > *(volatile type *)&(var) = (value)
> memset can be optimised away as well. The only way is to declare those
> variables volatile.
Assigning through
ng/Makefile (revision 209062)
+++ usr.bin/clang/Makefile (working copy)
@@ -1,5 +1,5 @@
# $FreeBSD$
-SUBDIR=clang
+SUBDIR=clang tblgen
.include
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@fre
RCE_ASSIGN(type, var, value) \
*(volatile type *)&(var) = (value)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
Roman Divacky writes:
> I would like to propose to integrate clang/LLVM into FreeBSD HEAD
> in the near future (days, not weeks).
+1
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
g at the bug is
> immense. When you do know that the issue can be in the compiler, and
> not the OS, why looking ?
...so is this.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailma
Brooks Davis writes:
> http://wiki.freebsd.org/201005ToolchainSummitSummary
"No new functionality that requires clang/llvm."
How about "No new functionality with non-trivial incompatibilities with
clang/llvm"?
DES
--
Dag-Erling
Kostik Belousov writes:
> Dag-Erling Smørgrav writes:
> > It adds quite a bit of code to pretty much every UFS VOP.
> No, it does not. Essentially, it adds one or two function calls per
> vop that allocate or deallocate blocks or inodes, and the function
> bodies verify two
much it affects
performance, but I suspect it's noticeable for disk-intensive workloads
such as busy databases.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
Lev Serebryakov writes:
> "Dag-Erling Smørgrav" writes:
> > Most pseudo-raid kit has nifty features like checksum offloading,
> > composite writes etc.
> Why are they called ``PSEUDO-raids'' then?
Several reasons - they don't present the array to t
ug which sos@ worked around in the driver, I forget which)
> Any URLs?
Google "Promise FastTrak SATA RAID"
I have two or three of those, including one with on-board SDRAM (but no
battery backup)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
Alexander Motin writes:
> Dag-Erling Smørgrav writes:
> > Most pseudo-raid kit has nifty features like checksum offloading,
> > composite writes etc. which can improve performance considerably. You
> > can't access those from GEOM.
> Have you ever seen them document
201 - 300 of 430 matches
Mail list logo
