Re: glabel force sectorsize patch
On Sun, Aug 8, 2010 at 14:02, Ivan Voras ivo...@freebsd.org wrote: On 8.8.2010 12:30, Pawel Jakub Dawidek wrote: On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote: Hi, In order to help users having 4k sector drives which the system recognizes as 512 byte sector drives, I'm proposing a patch to glabel which enables it to use a forced sector size for its native-labeled providers. It is naturally only usable with glabel-native labels (those created by glabel label) and not partition and file system labels because we cannot add arbitrary new fields to metadata of those types. The patch is here: http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch [...] This mechanism is a band-aid until there's a better way of dealing with 4k drives. So why do you want to obfuscate glabel with it? For people to start depend on it? Once we start supporting 4kB sectors what do we do with such a change? Remove it and decrease version number? What people will do with providers already labeled this way? If its temporary, just allow to list providers you want to increase sector size in /boot/loader.conf. Once we start supporting it properly people might simply remove it from loader.conf and it should just work. Glabel is not for that and I don't agree for such obfuscation. Of course, there are good and bad sides to it. My take on it is that the only bad side is that it really isn't glabel's primary function to (optionally) fixup geometry, while the good sides are: * glabel is in GENERIC and judging by the mailing lists' traffic it is one of the better used parts of the system so people are familiar with it. It is also already used as a perfectly valid fixup for device renaming, making both UFS and ZFS more stable for usage. * You can't really make people depend on glabel both because it is in GENERIC and because of it storing metadata in the last sector, making the rest of the drive completely usable without it in the event native 4k sector support is grown. I'd like to hear comments from the wider audience. In respect with your comment, I will compromise: as 4k sector drives have become available over the counter more than 6 months ago and so far I think this is the first effort to give some support for them, I will commit this patch before 9.0 code freeze only if no other support gets developed. I do not like this at all. Even if it's just for the KISS and POLA principles. A geom should do one thing and do it right imo. Why not write a new geom class that does what you want? ___ 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
Re: glabel force sectorsize patch
On Sun, Aug 8, 2010 at 21:08, Ivan Voras ivo...@freebsd.org wrote: On 8.8.2010 14:57, Marius Nünnerich wrote: On Sun, Aug 8, 2010 at 14:02, Ivan Voras ivo...@freebsd.org wrote: This mechanism is a band-aid until there's a better way of dealing with 4k drives. I do not like this at all. Even if it's just for the KISS and POLA principles. A geom should do one thing and do it right imo. As the addition will not modify general behaviour of glabel but add a new feature (which is actually clean and trivial to implement) invisible to most of the users, I don't think either KISS nor POLA are in any danger here. Adding a new feature maps directly to KISS, especially if the feature is in the wrong module. POLA: I wouldn't guess that a blocksize resizing is hidden in a _part_ of glabel. I am not using the native glabel part at all, just the named GPT partitions as most of the users seem to prefer nower days (and I guess will get even more traction after Dan's blog post). I do agree that it shouldn't be glabel's job to do this but also am *very* strongly against shipping 9.0 without any support for 4k drives, and the way I've chosen is the lesser of two evils. I am against workarounds for stupid hardware vendors most of the time. Especially if it's just a minority, they break pola intentionally and is fixed easily without this kludge. Afaik if you align your Partitions to higher values (I use 1MB for example) ufs is not having any performance issues (I have not benchmarked this myself). Code and patches by others are of course welcome. I'm hoping this discussion will trigger someone with experience in the lower levels of kernel to go and finally add the drive info parsing so it gets solved the right way :) Why not write a new geom class that does what you want? I'm not against this approach also. Technically, if we go this way, the new GEOM class will be almost a line-for-line copy-paste of glabel with this single metadata field added, so I'd rather fold it into glabel. 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.conf variables. (Maybe like gnop? If I remember correctly, I did not take a look at that class for ages). This way you would get: - Your feature - no KISS violation, that class should be really simple - no POLA violation, feature is in a class with a discriptive name, glabel is left alone - no metadata store problem (is it in the last 512 or 4K bytes?) - No problem with future compatibilty, a user would have to active the class and it's configuration by hand, no magic here Marius ___ 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
Re: How to troubleshoot why VirtualBox kernel module freezes the system?
On Wed, Apr 28, 2010 at 22:18, Yuri y...@rawbw.com wrote: VirtualBox kernel module (port emulators/virtualbox-ose-kmod) began to cause system freezes from some kernel change around the end of January. Once the system freezes it has to be rebooted. Soundcard, if it was playing something, begins to cycle some very short piece. Nothing is logged into /var/log/messages. Is there any way to troubleshoot this, like enabling some kernel configuation options? What is normally done in such case? Should I run system under kernel debugger? But would it detect something if it's not a SEGV but the freeze? It freezes for me too after a short while when I use the nvidia blob (8.0-RELEASE/amd64). Does your machine have firewire and do you have a second machine with firewire? I heard that it should be possible to read the ram contents of a frozen machine over firewire. I only have one firewire machine so I can't test. ___ 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
Re: ctfconvert dependency...
On Thu, Mar 11, 2010 at 10:26, Shrikanth Kamath shrikant...@gmail.com wrote: Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My understanding here is ctfconvert needs to build the ctfdata for the kernel image and the kernel loadable modules. If we were to DTrace 'DTrace' then we need the ctfdata for the files under cddl/ and sys/cddl, is that correct? ctf information is needed for everything we want to dtrace. We even need it for tracing userland stuff but that doesn't work right now for other reasons. ___ 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
Re: ctfconvert dependency...
2010/3/11 C. Bergström cbergst...@pathscale.com:
Marius Nünnerich wrote:
2010/3/11 C. Bergström cbergst...@pathscale.com:
Shrikanth Kamath wrote:
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target
suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes bsd.lib.mk in it's Makefile, so will the
above
not try to
run 'ctfconvert' on libctf itself?
I'm going to make some assumptions and go out on a limb here..
The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg
repo)
When OpenSolaris is built they convert stab debugging information over
to
CTF (compressed text format?). This is done so that they can have
debugging
information, but without the overhead of stab (or dwarf2). I don't know
how
much of the original onnv-gate Makefiles came over from OpenSolaris, but
assuming the FBSD kernel doesn't need/use CTF format this dependency can
and
probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
Hopefully this is useful information and I'm not too wrong or someone
will
correct me
The CTF information is needed by DTrace.
My guess is that it will run ctfconvert on itself so it should be
there from a prior install or it is part of some early toolchain
stuff.
CTF is needed by DTrace where? The build may depend on it, but this is
probably for legacy reasons only. DTrace in opensolaris isn't dependent on
it to function correctly. Replace the $(CTFCONVERT) and a few other
utilities with /bin/true and the build will succeed. (I can only speak
first hand from OSUNIX/OpenSolaris though and not FBSD..)
The build will succeed but dtracing something with the FBT provider won't.
___
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
Re: ctfconvert dependency...
2010/3/11 C. Bergström cbergst...@pathscale.com:
Shrikanth Kamath wrote:
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes bsd.lib.mk in it's Makefile, so will the
above
not try to
run 'ctfconvert' on libctf itself?
I'm going to make some assumptions and go out on a limb here..
The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg repo)
When OpenSolaris is built they convert stab debugging information over to
CTF (compressed text format?). This is done so that they can have debugging
information, but without the overhead of stab (or dwarf2). I don't know how
much of the original onnv-gate Makefiles came over from OpenSolaris, but
assuming the FBSD kernel doesn't need/use CTF format this dependency can and
probably should go away. (Only (k)mdb supports CTF that I'm aware of?)
Hopefully this is useful information and I'm not too wrong or someone will
correct me
The CTF information is needed by DTrace.
My guess is that it will run ctfconvert on itself so it should be
there from a prior install or it is part of some early toolchain
stuff.
___
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
Re: sx locks and memory barriers
On Tue, Sep 29, 2009 at 21:15, Attilio Rao atti...@freebsd.org wrote: 2009/9/29 John Baldwin j...@freebsd.org: On Tuesday 29 September 2009 11:39:37 am Attilio Rao wrote: 2009/9/25 Fabio Checconi fa...@freebsd.org: Hi all, looking at sys/sx.h I have some troubles understanding this comment: * A note about memory barriers. Exclusive locks need to use the same * memory barriers as mutexes: _acq when acquiring an exclusive lock * and _rel when releasing an exclusive lock. On the other side, * shared lock needs to use an _acq barrier when acquiring the lock * but, since they don't update any locked data, no memory barrier is * needed when releasing a shared lock. In particular, I'm not understanding what prevents the following sequence from happening: CPU A CPU B sx_slock(data-lock); sx_sunlock(data-lock); /* reordered after the unlock by the cpu */ if (data-buffer) sx_xlock(data-lock); free(data-buffer); data-buffer = NULL; sx_xunlock(data-lock); a = *data-buffer; IOW, even if readers do not modify the data protected by the lock, without a release barrier a memory access may leak past the unlock (as the cpu won't notice any dependency between the unlock and the fetch, feeling free to reorder them), thus potentially racing with an exclusive writer accessing the data. On architectures where atomic ops serialize memory accesses this would never happen, otherwise the sequence above seems possible; am I missing something? I think your concerns are right, possibly we need this patch: http://www.freebsd.org/~attilio/sxrw_unlockb.diff Actually, since you are only worried about reads, I think this should be an acq barrier rather than a rel. In some cases acq is cheaper, so we should prefer the cheapest barrier that provides what we need. You would still need to keep some language about the memory barriers since using acq for shared unlocking is different from exclusive unlocking. Actually, I don't think that an acq barrier ensures enough protection against the reordering of 'earlier' operation thus not fixing the architecture ordering problem reported by Fabio. Also, I don't think we just have to care about reads (or I don't understand what you mean here). However, I'm not even sure that we have faster read barriers than the write one. As long as it should be true in theory I don't think that's what happen in practice. The memory clobber is quite heavyweight. It actually forces gcc to forget any cached memory items in registers and reload everything again. What I really want is just a barrier to tell GCC to not reorder things. If I read a value in the program before acquiring a lock it is in theory fine to keep that cached across the barrier. However, there isn't a way to do this sort of thing with GCC currently. Yes, that's the only tool we have right now with GCC. I will try to look for another way, but it sounds difficult to discover. Even if we would have a mechanism to tell GCC to not reorder the instructions the CPU itself would still be free to reorder if there are no barriers. Or am I missing something? ___ 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
Re: How best to debug locking/scheduler problems
On Mon, Jun 15, 2009 at 23:53, Mel Flynnmel.flynn+fbsd.hack...@mailing.thruhere.net wrote: Hi, I'm trying to get to the bottom of a bug with getpeername() and certain kde4 applications which is probably as low-level as the libthr and the scheduler. From browsing various related files in sys/kern it seems KTR is a good bet to get the information needed, yet it isn't really well supported in userland. For one, I've got no clue other then logging console output(?) how to retrieve the lock info or filter it in userland from reading ktr(9) and alq(9). Gdb is useless as the process doesn't give the information gdb wants and gdb just hangs in wait. ktrace also does not provide anything as there are no more syscalls being made, so I'll have to get to the bottom of this by tracing and filtering. Short description of the problem: a process never gets out of mi_switch and remains locked even init tries to shut it down. [snip] Hi Mel, my idea would be to try DTrace for this. Hopefully the following link will help you: http://wiki.freebsd.org/DTrace There are more links at the bottom. I added DTrace probes to geom a while ago and it's really easy. Feel free to ask for more help. Kind regards Marius ___ 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
Re: Clang: now available from a SVN server near you!
Thanks to the team for this! On Thu, Jun 4, 2009 at 11:38, Ed Schouten e...@80386.nl wrote: Good news everyone! As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch into SVN. Tuesday I finally had some time to do it, so here's the result: http://svn.freebsd.org/viewvc/base/projects/clangbsd/ You can now build your very own version of FreeBSD with Clang installed as /usr/bin/cc as follows: - Check out the clangbsd branch from our SVN repository: svn co svn://svn.freebsd.org/base/projects/clangbsd If one has a (recent) head checkout one can also use the faster and lighter svn switch svn://svn.freebsd.org/base/projects/clangbsd in the head working directory (less traffic for the server too). ___ 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
Re: Memory leak on thread removal
On Sat, May 16, 2009 at 19:05, Mikolaj Golub to.my.troc...@gmail.com wrote:
On Fri, 15 May 2009 13:48:51 +0200 Marius Nünnerich wrote:
MN On Tue, May 12, 2009 at 08:27, Mikolaj Golub to.my.troc...@gmail.com
wrote:
Hi,
The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386,
amd64):
#include omp.h
#include unistd.h
int n = 4, m = 2;
int main () {
for (;;) {
int i;
//sleep(2);
#pragma omp parallel for num_threads(m)
for(i = 0; i 1; i++) {}
//sleep(2);
#pragma omp parallel for num_threads(n)
for(i = 0; i 1; i++) {}
}
return 0;
}
During the run the program's virtual memory usage constantly grows. The
growth
is observed only when n != m. When running the program with uncommented
sleep() and observing the number of threads with 'top -H' I see in turn 2
or 4
threads. So it looks like memory leak when thread is removed. Should I
fill
PR?
It looks like I have found the leak. The problem is in libgomp/team.c.
gomp_thread_start() does sem_init() but sem_destroy() is never called. This
patch solves the problem for me:
--- contrib/gcclibs/libgomp/team.c.orig 2009-05-16 17:32:57.0 +0300
+++ contrib/gcclibs/libgomp/team.c 2009-05-16 19:16:37.0 +0300
@@ -164,9 +164,12 @@ new_team (unsigned nthreads, struct gomp
static void
free_team (struct gomp_team *team)
{
+ int i;
free (team-work_shares);
gomp_mutex_destroy (team-work_share_lock);
gomp_barrier_destroy (team-barrier);
+ for(i = 1; i team-nthreads; i++)
+ gomp_sem_destroy (team-ordered_release[i]);
gomp_sem_destroy (team-master_release);
free (team);
}
I am going to fill PR to gcc mainstream, but should I also register this in
FreeBSD bugtrack as gcc is part of the base?
BTW, the problem is not observed under Linux. I have not looked in Linux code
but it looks like sem_init() implementation for Linux does not do memory
allocation. The memory for the test program below grows under FreeBSD and does
not under Linux.
#include semaphore.h
int
main(int argc, char *argv[]) {
sem_t sem;
for(;;) { sem_init(sem, 0, 0);}
return 0;
}
Wow! Thanks for tracking this down. I think you can file both PR's so
that FreeBSD can include your patch before it comes in via upstream.
MN I can confirm this. I briefly looked through the libgomp code but
MN didn't see the leak. Anybody knows good tools how to investigate this?
http://freshmeat.net/projects/lmdbg
This is a small memory leak debugger. It does not provide all functionality
you can find in more sophisticated tools but is lightweight, portable and
simple in use. It was very useful when I traced this bug.
Thanks, I'll take a look at it.
___
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
Re: Memory leak on thread removal
On Tue, May 12, 2009 at 08:27, Mikolaj Golub to.my.troc...@gmail.com wrote:
Hi,
The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386, amd64):
#include omp.h
#include unistd.h
int n = 4, m = 2;
int main () {
for (;;) {
int i;
//sleep(2);
#pragma omp parallel for num_threads(m)
for(i = 0; i 1; i++) {}
//sleep(2);
#pragma omp parallel for num_threads(n)
for(i = 0; i 1; i++) {}
}
return 0;
}
During the run the program's virtual memory usage constantly grows. The growth
is observed only when n != m. When running the program with uncommented
sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
threads. So it looks like memory leak when thread is removed. Should I fill
PR?
I can confirm this. I briefly looked through the libgomp code but
didn't see the leak. Anybody knows good tools how to investigate this?
___
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
Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation
On Tue, Apr 28, 2009 at 22:19, Julian Bangert julid...@online.de wrote: Hello, I am currently trying to work a bit on the remaining missing feature that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. For now, I am trying to extend the current system call and implementation to add cache control ( the type of memory caching used) . This feature inherently is very architecture specific- but it can lead to enormous performance improvements for memmapped devices ( useful for drivers, etc). I would do this at the user site by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to the various caching options ( like Uncacheable,Write Combining, etc... ) with the same numbers as the PAT_* macros from i386/include/specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is assigned the meaning feature not used, use default cache control. For each cache behaviour there would of course also be a macro expanding to the rigth combination of these flags for enhanced useability. Hmm, I don't like that. What about using something like PAT_WC directly for the userland? Afaik a userland app that uses stuff like this is md anyway. The mmap system call would, if any of these flags are set, decode them and get a corresponding PAT_* value, perform the mapping and then call into the pmap module to modify the cache attributes for every page. My first question is if there is a more elegant way of solving that - the 3 flags would be architecture specific ( they could be used for other things on other architectures though if need be ) and I do not know the policy on architecture specific syscall flags, therefore I appreciate any input. The second question goes to all those great VM/pmap gurus out there: As far as I understand, at the moment the pmap_change_attr can only cange the cache flags for kernel pages. Is there a particular reason why this function might not be adapted/extended to userspace mappings? If not, I would either add a new function to iterate over all pages and set cache flags for a particular region or add a new member (possibly just add the 3 flags again ? ) to the md part of vm_page_t. Or one could just keep track and return errors as soon as someone tries to map a memory region ( cache-customized mapping is usually done to device memory ) already mapped with different cache behaviour. Do you know how other OS handle this stuff? Maybe there is some inspiration there for a clean interface. I'm not sure if I remember correctly but there is something in my mind that we must take care that no virtual pages have different PAT settings for the same physical page. Maybe I read something like this in the AMD's documentation of PAT. Sorry I don't remember exactly but perhaps someone else can explain it better. ___ 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
Re: Debugging init process.
On Wed, Mar 11, 2009 at 08:51, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, I need to debug init process. I am not able to attach init to gdb and it throws As others mentioned, this is explicitly disabled. You could re-enable it by hacking the kernel, but it could cause other unexpected problems. Alternatively, there's always printf debugging. What is wrong with init, that you need to debug it? It's a fairly simple program that's been around for a long time and should be pretty stable. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). DTrace is not available for userland processes yet. ___ 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
Re: Why safe using msleep with timeout=0 but not tsleep?
On Mon, Dec 8, 2008 at 9:17 PM, John Baldwin [EMAIL PROTECTED] wrote:
On Sunday 07 December 2008 02:00:30 pm Marius Nünnerich wrote:
See subject.
Interesting commit:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=77059
Lost wakeups. If you have code like so that doesn't use any locks:
int flag;
void
foo(void)
{
flag = 1;
wakeup(flag);
}
void
bar(void)
{
if (flag == 0)
tsleep(foo, ..., 0);
}
Then one CPU may run the 'foo' routine to completion after another CPU has
seen 'flag == 0' but before it has put the thread to sleep in tsleep(). Even
on UP systems with preemption you can still get this race if you get
preempted by an interrupt (which runs foo()) in between the 'flag == 0' test
and calling tsleep(). Using an interlock avoid this:
struct mtx lock;
int flag;
void
foo(void)
{
mtx_lock(lock);
flag = 1;
mtx_unlock(lock);
wakeup(flag);
}
void
bar(void)
{
mtx_lock(lock);
if (flag == 0)
mtx_sleep(foo, lock, ..., 0);
mtx_unlock(lock);
}
In this case 'lock' closes the SMP/preemption races.
--
John Baldwin
Thank you for the explanation, John!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Why safe using msleep with timeout=0 but not tsleep?
See subject. Interesting commit: http://svn.freebsd.org/viewvc/base?view=revisionrevision=77059 - Marius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel documentation and specification
On Thu, 24 Mar 2005 13:17:56 +0200 Giorgos Keramidas [EMAIL PROTECTED] wrote: The book is absolutely fabulous! Watch out for the details though and keep in mind that you many find it nice to have a FreeBSD source tree nearby, just for the fun of browsing the source itself too while you read. Is there much difference to The Design and Implementation of the 4.4BSD Operating System? I have already read that, and don't know if the new book is just the same with a few parts updated? cheers Marius pgpCU0pnKoUfU.pgp Description: PGP signature
