"Steven Hartland" writes:
> Hi DES, unfortunately you need a quite bit more than this to work
> compatibly.
*chirp* *chirp* *chirp*
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.fre
This should eliminate the need for ivoras@'s gnop trick
when creating ZFS pools on Advanced Format drives.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
===
--- sys/cd
e your worldview on them. Maybe they know something you
haven't learned yet.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
Wojciech Puchar writes:
> Lev Serebryakov writes:
> > It is not exact so. Some Atoms on some motherboards with some
> > firmwares are 64-bit CPU.
> don't know of any now in shops that are not
http://soekris.com/products/net5501.html
http://soekris.com/products/net6501.h
verting such efforts to other
> man power or resources required areas.
You're assuming that maintaining i386 as a tier 1 platform really *does*
add significantly to our workload.
You should also check your calendar :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Dimitry Andric writes:
> Dag-Erling Smørgrav writes:
> > The following patches (for head and stable/9) automatically enables
> > CLANG_IS_CC if GCC is disabled but CLANG is not. Any objections?
> This looks fine to me. Otherwise, if ${CC} isn't set to clang,
>
le/9/share/mk/bsd.own.mk(revision 244989)
+++ stable/9/share/mk/bsd.own.mk(working copy)
@@ -581,6 +581,8 @@
.if ${MK_CLANG} == "no"
MK_CLANG_IS_CC:= no
+.elif ${MK_GCC} == "no"
+MK_CLANG_IS_CC:= yes
.endif
MK_LIBCPLUSPLUS?= no
DES
--
Dag
grarpamp writes:
> Any of hundreds of committer and admin accounts could be compromised
> with the attacker silently editing the repo.
FUD. Committer accounts don't have direct access to the repo.
DES
--
Dag-Erling Smørgrav - d...@des.no
Konstantin Belousov writes:
> "Dag-Erling Smørgrav" writes:
> > I assume you mean assignments, not calculations. I trust the compiler
> > to move them to where they are needed - a trivial optimization with SSA.
> It is a dereference before the assignment, so I perc
Konstantin Belousov writes:
> "Dag-Erling Smørgrav" writes:
> > + otable = fdp->fd_ofiles;
> > + ofileflags = fdp->fd_ofileflags;
> These two new calculations could be unused if the function return early.
I assume you mean assignments, not calculations. I
aside for that purpose.
(I assume that the old behavior was harmless, since it has persisted for
decades, but it was certainly confusing.)
The slightly repetitive nature of the new code is intentional.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/kern/kern_descrip.c
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
race is that its interactive mode is useful for playing text adventures
implemented with DNS TXT records :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
. If you know the people who run it, you might let them know
that it is inadvisable to process recursive queries from outside their
own network.
FWIW, the reply I got was not truncated. Perhaps there is a transparent
DNS proxy somewhere between you and 178.250.72.130 - quite common with
broadb
00
;; AUTHORITY SECTION:
des.no. 3600IN NS ns.des.no.
des.no. 3600IN NS ns.hyp.net.
;; ADDITIONAL SECTION:
ns.des.no. 3600IN A 194.63.250.121
;; Query time: 0 msec
;; SERVER: 194.63.250.121
;; WHEN: Mon Jul 9 23:22:23 2012
;; MSG SIZE rcvd: 128
DES
--
Dag-Erling Sm
works
with thousands of clients, but I doubt my boss is going to let me run
performance comparisons on the university's network)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
parate from the
authoritative nameserver (named). Yes, they are, but they have a *lot*
of code in common. In fact, *most* of the code in BIND is common code
shared between named, dig etc.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@
but dig(1) is
not nearly as widely used, and ldns's drill(1) supports the same
command-line syntax for the most common operations.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/ma
I'm willing to import and maintain unbound (BSD-licensed validating,
recursive, and caching DNS resolver) if you remove BIND.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
Robert Simmons writes:
> OpenSSH 6.0p1
No. It doesn't build cleanly on FreeBSD (I reported two issues during
the pre-release cycle, one was fixed but the other was not), and even if
it did, it's too big a change to push through on such short notice.
DES
--
Dag-Erling Smørgrav
Michael Bushkov writes:
> 2. Consequences of the aforementioned problem can probably be
> corrected by using _setsockopt(..., SO_NOSIGPIPE) in
> __open_cached_connection() in nscachedcli.c
That sounds like a workaround rather than a fix...
DES
--
Dag-Erling Smørgrav - d.
ly to Artem Belevich
earlier in this thread.
While we're at it, I'd be very grateful if someone could email me a
quick and dirty guide to setting up an LDAP server for testing. I have
too much on my plate right now to start reading documentation...
DES
t happens?
> I'd like to see it stay in base. Moving it (slowly) towards a point
> where we can turn it on by default would be cool.
Agreed, in principle.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing l
and even if it could, it would still
have to query the backend every time, so you might still get a longish
timeout for every lookup, depending on the type of backend and the
reason it failed.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@
To test, stop nscd, then run it from the command line like so:
$ su -
# cd /tmp
# ulimit -c 0
# /usr/sbin/nscd -nst
(do something in another terminal that causes it to crash)
# echo backtrace | gdb -batch -x /dev/stdin /usr/sbin/nscd nscd.core
and send me the output from both nscd and gdb once it cr
reproduce
the bug, but both users who reported problems used ldap, and I don't
have an LDAP server to test against, so I thought it might be specific
to LDAP.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.or
t to use it can" in one end to "finding someone willing
to clean it up and maintain it and enable it by default" in the other.
(no, I'm not volunteering to maintain it)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-ha
ring_ into the change-auth-token function
> pam_chauthtok(...), which always jumps in an interactive pw-changing
> loop.
There is no reliable way to do that. You don't even know that there is
such a thing as a password.
DES
--
Dag-Erling Smørgrav - d...@des.no
[redirected from -hackers to -security]
Jakub Lach writes:
> http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html
DES
--
Dag-Erling Smørgrav -
e intended to go hand in hand. I would have preferred that
contexts were actually tied to subtrees, but I had to play the ball I
was given.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/ma
necessarily equal to Y.
Since, as you point out, the coretemp device is a child of the
corresponding cpu device, there is no risk of orphaning the temperature
OID.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
ht
Bakul Shah writes:
> "Dag-Erling Smørgrav" writes:
> > You should replace the err() call with a warn() call instead of
> > removing it outright.
> That would print the err msg twice as opendir (or something) already
> seems to report the error. Try it!
Oh, OK.
(dp->d_name[1] != '\0' &&
You should replace the err() call with a warn() call instead of removing
it outright.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lis
ss!
> Nothing works.
Nothing that you've tried works because everything you tried was wrong.
You can't just make something up and expect it to work because you want
it to work. Read the documentation and use the proper tool for the
proper job.
DES
--
Dag-Erling Smørgrav - d...@des.no
efore you reboot - it used to be necessary, but ISTR someone hacked
around it to make it easier to run 32-bit chroots on amd64.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
Peter Jeremy writes:
> Dag-Erling Smørgrav wrote:
> > 9413 what? Puppies?
> Ooops, sorry - KB/sec as reported in the dump summary.
Thank you :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org maili
MaxMedian AvgStddev
> x 4 9413 9673 95689555.5 107.12143
> + 4 15359 15359 15359 15359 0
9413 what? Puppies?
DES
--
Dag-Erling Smørgrav - d...@des.no
feature is their dynamically adjusted rotational speed, which allows
them to conserve power without spinning all the way down.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
nical damage to
the arms.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
n", because you should
know better, and following your advice could damage people's hardware.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsub
after
three to six months. Remember, there was a huge flap a couple of years
when Ubuntu shipped with a default timeout of 90 seconds, which is more
than ten times more than what you suggest.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@free
Alexander Best writes:
> Dag-Erling Smørgrav writes:
> > No. Where did you get that idea? To repeat what I've said before -
> > several times - in this thread, a modern disk drive can handle hundreds
> > of thousands of controlled unloads but only a few hundred emerge
? To repeat what I've said before -
several times - in this thread, a modern disk drive can handle hundreds
of thousands of controlled unloads but only a few hundred emergency
unloads. Given the choice between "never spin down" and "always spin
down", the safe alternative
he new API if it is available and the old one if it isn't.
> Let's try with the patch attached...
Mailman strips binary attachments. The correct MIME type is
text/x-patch.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hacke
hat happens when the drive loses power while still
spinning).
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-
Alexander Best writes:
> Dag-Erling Smørgrav writes:
> > Alexander Best writes:
> > > so how about forgetting about expand_number() and simply
> > > introducing a maximum buffer size of 1 megabyte?
> > so how about just leaving the code alone? :)
> i thought
Alexander Best writes:
> so how about forgetting about expand_number() and simply introducing a
> maximum buffer size of 1 megabyte?
so how about just leaving the code alone? :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-h
byte why shouldn't they? it's their decision
> actually.
Good point... although if they set it too high, either malloc(3) will
fail - if they're lucky - or fetch(1) will crash when the system runs
out of physical RAM and swap, and they'll have to start ov
Alexander Best writes:
> so how about something like this? the fetch(1) manual would have to be changed
> a bit to state that if '-B val' > 1G it silently gets set to 1G.
1 GB is ridiculously large. 1 MB should be plenty.
DES
--
Dag-Erling Smø
Xin LI writes:
> Dag-Erling Smørgrav writes:
> > Xin LI writes:
> > > My 2 cents: I think we don't really need to care about the size
> > > for rescue binary after the splitfs VFS layer have been introduced
> > > to libstand? Build of release split M
#x27;m not sure, but i think fetch(1) is BSD specific so no POSIX regulations
> need
> to be taken into consideration. but you probably know more about this matter.
fetch(1) is 100% home-grown.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd
"Andresen, Jason R." writes:
> Dag-Erling Smørgrav writes:
> > I see no reason why sector size should be a selection criterium. Just
> > buy the disk that gives you the best performance and / or capacity for
> > your money. WD Green disks are cheap, but other ve
rescue has a full camcontrol.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
7;m not sure the difference is that big when it's crunched with the
rest of /stand.
textdata bss dec hex filename
268751 26464 54112 349327 5548f camcontrol-crunch
355122 27064 58904 441090 6bb02 camcontrol-full
DES
--
n) the argument to -S can not be
expressed in [kMGTEP]B.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke
ze should be a selection criterium. Just
buy the disk that gives you the best performance and / or capacity for
your money. WD Green disks are cheap, but other vendors offer models
with the same capacity and twice the speed for only 5% or 10% more.
DES
--
Dag-Erling Smørgrav
Ilya Bakulin writes:
> Dag-Erling Smørgrav writes:
> > Why did you shift the gnop? Did you short jumper 7-8?
> No, 7-8 remained as-is. ad7p1 was created using:
> #gpart add -t freebsd-ufs -s 10G -b 63 ad7
>
> So it begins at sector #63, but physical 4096-block begins a
, but you still have
to include the original license, disclaimer and copyright statement.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, se
Thiago Damas writes:
> "ATA 4K sector issues"
> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031154.html
Yes, we know. That's what this entire thread (and a zillion others
before it) is about.
DES
--
Dag-Erling S
l
> Notice, that for two subsequent phybs invocations there is big
> difference in timings for the same parameters.
Yes. WD Green disks suck.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freeb
fore I committed it, that table either did not exist or was empty.
That was three years ago, though, so my recollection is a bit fuzzy.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mail
jhell writes:
> On stable/8 this is needed to build. Seems the need for linking against
> libutil came in revision r211233.
Yes, I forgot to commit the Makefile. Thank you for reminding me.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
f
Garrett Cooper writes:
> Dag-Erling Smørgrav writes:
> > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE.
> I would actually argue against doing that because it would only create
> divergence between sysctl and tunable KPIs...
Not if we also introduce corres
try the disk reports to the BIOS.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
1 of Atapi-7
> volume 1 (google for ata-atapi-7.pdf).
Yes. We already support this. The problem is that WD's Advanced Format
disks (or at least some of them) lie.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.o
ARS disks are AF.
Also, it's not just the label - AF disks have AF-specific jumper
settings.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscri
;re interested.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 -
rt
hw.pci.host_mem_start
hw.physmemstart
The following are not addresses, but can be > 32 bits on 64-bit machines
and even on some 32-bit machines using PAE / PTE:
hw.physmem
vm.kmem_size
vm.kmem_size_max
vm.kmem_size_min
It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE.
DES
Ivan Voras writes:
> Dag-Erling Smørgrav writes:
> > Not sure what you mean. The original issue was that someone had used
> > TUNABLE_INT() for something that was actually a memory address. I
> > changed it to TUNABLE_ULONG(). Of course, if your tunable is a boolean
&
Garrett Cooper writes:
> Dag-Erling Smørgrav writes:
> > Perhaps. I don't remember all the details; I can't find a discussion in
> > the list archives (other than me announcing the change in response to a
> > bug report), but there must have been one, either on
han me announcing the change in response to a
bug report), but there must have been one, either on IRC or in Karlsruhe.
In any case, I never removed TUNABLE_INT(), so...
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailin
se it was signed.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
f with appropriate key entered
> to the port we will get non-0xff value.
Sounds gross, but if there's no other way, I guess it'll have to do. I
imagine you check the PCI id etc. first?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freeb
Not related to your problem, but related to $SUBJECT: make sure to use
-P in LFLAGS so your lex-generated symbols don't conflict
with those present in applications that use your library, or in other
libraries those applications may use.
DES
--
Dag-Erling Smørgrav - d...@d
Xin LI writes:
> "Dag-Erling Smørgrav" writes:
> > Perhaps the motherboard has additional watchdog hardware? If you
> > disable the watchdog in BIOS, does ichwd still work?
> If I kill -9 watchdogd the system do reset itself so I think ichwd(4)
> really works ev
dditional watchdog hardware? If you
disable the watchdog in BIOS, does ichwd still work?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send a
firmware to either catch it or pass it through.
Unfortunately, although it is possible for the ichwd driver to detect
programatically (by checking an MSR) if the watchdog timer is disabled
in hardware, it is not possible to determine whether it is disabled in
firmware.
DE
compound
> command.
This won't work, because tail won't start until the build is done. You
should just pass the file name as an argument to your script and handle
it there.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freeb
_amd64_kernel.log'. However, the top-level make file just
> continues on to the next label as if no error occurs.
Make looks at tee's exit status, not the script's.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebs
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...@
witch to .o on other platforms?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
make command line:
set -e
this will cause sh to terminate the script immediately with a
non-zero exit status if any command after the "set" line fails.
However, I don't see the point of using shell scripts in the first
place...
DES
--
Dag-Erling Smørgrav - d...@des.no
__
Bakul Shah writes:
> Except read doesn't do it quite right:
>
> $ ps | (read a; echo $a ; grep zsh)
> PID TT STAT TIME COMMAND
yeah, I forgot that it drops leading whitespace...
DES
--
Dag-Erling Smørgrav - d...@des.no
__
read line ; print $line ; done }
% jot 15 | (nhead 5 >/dev/null; nhead 3; echo hi; nhead 3)
6
7
8
hi
9
10
11
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
t will
not consume more input than necessary.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Dominic Fandrey writes:
> Dag-Erling Smørgrav writes:
> > Your .sig is strangely appropriate...
> Not my invention, this is a pretty common one, used by many people
> on the net. I actually have no idea where it comes from.
My point is that it is strangely appropriate to t
have ten (variable == variable)
comparisons and b) good compilers will warn about bare assignments used
as conditions.
The only practical effect of Yoda style is to make code harder to read.
Your .sig is strangely appropriate...
DES
--
Dag-Erling Smør
Sergey Babkin writes:
> I wonder if a version control system, like SVN, could be used to keep
> track of all the changes in /etc. (Or maybe it already is and I'm
> simply out of date).
arch is commonly used for things like this.
DES
--
Dag-Erling Smørgrav
?
I agree, please commit.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Julian Elischer writes:
> Who are you? and what have you done with DES?
I gave him a week off...
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> libraries are involved. However, it is possible to dynamically load
> modules using kldload. See the appropriate man page.
File is right. The kernel contains relocation entries so kernel modules
can be linked against it.
"monolithic" means something else entirely.
D
Tsuyoshi Ozawa writes:
> Julian Elischer writes:
> > Who are you? and what have you done with DES?
> Sorry [...]
Never mind, Julian was making a joke at my expense.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd
Dag-Erling Smørgrav writes:
> File is right. The kernel contains relocation entries so kernel modules
> can be linked against it.
"relocation entries" is possibly not the right term, someone with better
knowledge of ELF will have to correct me.
DES
--
Dag-Erling Smørgr
Mark nesterovych writes:
> Decided to write BSD licensed grep and provide it to FreeBSD project if
> success.
There is one already: textproc/bsdgrep.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing lis
e was actually a GSoC project last year, but nothing came
out of it. I really hope we can commit this soon!
BTW, at one point, in your blog, you write "periodic tick mode" instead
of "dynamic tick mode", which had me confused for a moment.
mutex then it sleeps until the next second
> boundary and tries again.
>
> The existing resettodr() would then turn into a wakeup(update_rtc).
Sounds good to me, but if only that thread has access to the RTC, why
bother with a mutex?
DES
--
Dag-Erling Smørgrav - d...@des.no
__
a to call resettodr()
any time the clock is stepped.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
1 - 100 of 726 matches
Mail list logo
