Re: Proposal for alleviating disk read / write time
On Wed, 18 Jul 2007, Ivan Voras wrote: Garrett Cooper wrote: Clarifications and comments are more than welcome. I really appreciate it. Hmm, your requirements look more and more like a... database? :) [whistling away...] I know. The only catch is that the last time I brought up databases it turned into a big discussion, where I got the following (paraphrased) opinions: 1. MySQL rules -- BDB sucks! 2. It'll be a cold day in %$#@ before SQL is included in the base system -- even SQL-Lite. 3. BDB isn't non-atomic and not stable. Unless something more constructive is going to be discussed, I'm not going to pursue that semi-bikeshed topic again. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal for alleviating disk read / write time
On Wed, 18 Jul 2007 [EMAIL PROTECTED] wrote: On Wed, 18 Jul 2007, Ivan Voras wrote: Garrett Cooper wrote: Clarifications and comments are more than welcome. I really appreciate it. Hmm, your requirements look more and more like a... database? :) [whistling away...] I know. The only catch is that the last time I brought up databases it turned into a big discussion, where I got the following (paraphrased) opinions: 1. MySQL rules -- BDB sucks! 2. It'll be a cold day in %$#@ before SQL is included in the base system -- even SQL-Lite. 3. BDB isn't non-atomic and not stable. Unless something more constructive is going to be discussed, I'm not going to pursue that semi-bikeshed topic again. -Garrett The other problem is that using a database technology in place of flat text files will force less intelligent tools without access to lower level DB manipulation APIs (portmaster for instance) to depend on other apps to do the data store translation legwork for them. But maybe that isn't a bad idea? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large amounts of memory access operations cause panic under CURRENT (was Large gap between fwrite and write, and fread and read)
On Tue, 17 Jul 2007, Milos Vyletel wrote: Go figure it'd cause panics for other people. I wasn't using zfs at all but it panicked anyhow once (my amd64 VM only, not my i386 test server, surprisingly). I wish I'd gotten the panic but I walked away to get a glass of water, and there wasn't a core dump because the VM shut down completely instead of restarting. Heh. My virtual machine died around 90k on the first trial though. I'll be sure to reduce the amount and see what happens, and I'll put nanosleeps or usleeps between the read and write ops to see if that alleviates the race condition seen, but I'll keep the problem code around for reference later in case I've stimulated some sort of weird bug in FreeBSD, or otherwise. Both my VM and test server run almost no programs though other than samba and rsync, so you'll probably see the panic faster / more frequently than I will if you run a lot more programs resident in memory. Just curious, what scheduler are you using on CURRENT, what processor do you have, and what are your memory specs? Thanks, -Garrett Hi Garrett, this is just my desktop where is running only Xorg, fluxbox, few aterms and firefox. But i can get the panic on console too, shortly after booting. I'm using SCHED_ULE. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20f32 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x3LAHF,CMP Cores per package: 2 usable memory = 3211718656 (3062 MB) avail memory = 3105570816 (2961 MB) For the record, it crashes few times before it hit 100k iterations, before i put debug printf in your code and increase MAX_ITERATIONS to 1m. And as far as I can tell, I had pretty much the same results as you've measured. mv Sorry for the noise, forgot to CC current@ This seems to be resolved with the latest CURRENT sources and ULE patches. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large gap between fwrite and write, and fread and read
On Tue, 17 Jul 2007, Heiko Wundram (Beenic) wrote:
On Monday 16 July 2007 14:06:57 Garrett Cooper wrote:
I ran some tests and I noticed a large difference in the cumulative
sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold
differences on a real machine).
This difference is at least partially explained when looking
at /usr/include/stdio.h, which defines the FILE structure: read/write on a
file descriptor is (pretty much) a direct syscall with operating system
specific semantics on a wide range of behavior, such as buffering, flushing
and seeking in read/write-opened files, whereas fread/fwrite on FILE*'s is
an abstraction of file access for which the stdio-API defines semantics,
such as buffering, the time flushing takes place and seeking in
read/write-opened files, across different flavors of POSIX-compatible libc's
equally.
As the stdio-interface is a wrapper (with indirect calls calling the syscall
read at some point in time, see the FILE-structure definition), you'll have
to expect a difference in runtime, too.
(You mixed up f{read,write}(3) and {read,write}(2), just as a sidenote, which
is also indicative of the difference: man3 is indicative of a libc
implementation, whereas man2 generally contains syscall documentation)
--
Heiko Wundram
Yeah, that's what I meant. I was rather tired when I made that post at
5:30 this morning. Heh.
Thank you for the additional info though. That was brief, but
comprehensive :).
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding slowdowns in pkg_install
On Fri, 6 Jul 2007, Michel Talon wrote: Tim Kientzle said: One approach I prototyped sometime back was to use libarchive in pkg_add as follows: * Open the archive * Read +CONTENTS directly into memory (it's guaranteed to always be first in the archive) I can only concur with that. In my program http://www.lpthe.jussieu.fr/~talon/check_pkg.py i discovered that memory mapping +CONTENTS and then working in memory before rewriting it was around 5 times faster than reading line by line and parsing each line. See function fix_pkg_database(). By the way i am writing a new +CONTENTS fileand then renaming it, which avoids leaving a mess if something goes astray like portupgrade does. -- Michel TALON Ok, excellent I'll try that then. I'll work on an improved parser this weekend and probably will have more conclusive results for next week, but for the immediate point in time I'll post results on how slow / fast the critical sections were once I return home and post process my data again for averages and standard deviations. I'll use this as my basis for further conclusions this summer. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help / advices with freebsd + asrock 4coredual-vsta (VT8237A)
On Tue, 19 Jun 2007, didier derny wrote: On 19 juin 07, at 15:33, Soeren Straarup wrote: On Mon, Jun 18, 2007 at 01:14:54PM +0200, didier derny wrote: I recently bought an asrock 4coredual-vsta mother board when I tried to install freebsd I saw with horror that freebsd6,2-stable and freebsd7.0-current where coughing when they tried to access the IDE or SATA hard disks /cdrom. it just get stuck after having accessed the hard disk or cdrom A great help would to have an output of 'boot -v' also known as a verbose boot. snip I there any hope to see FreeBSD working on this mother board ? is there anything I can do to help to solve the problem ? do I have to change my mother board for something else ? I choosed this one simply because it had a pci express AND an AGP slot in that case to you have any advice for the video board if I want to buy somethething working with X11 ? thanks for your help -- [EMAIL PROTECTED] org /Soeren That's a problem with the CF reader. Is your CF reader compatible with the driver available in the kernel, and did you build in USB CF support to the kernel statically? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making sense of ktrace(1) output
On Mon, 18 Jun 2007, Roman Divacky wrote: Unfortunately I have to profile all of the source up the tree to create profiled symbols, and I'm running into some issues profiling liblegacy. Does anyone have any hints for getting around that, or just profiling all of the relevant libs? I think you can build fbsd with profiling of all libraries (in base) and run it like that... Hmm.. I think I'll actually try the -static gcc flag and see where it gets me. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making sense of ktrace(1) output
On Tue, 19 Jun 2007, Peter Jeremy wrote: On 2007-Jun-18 15:37:11 +0200, Roman Divacky [EMAIL PROTECTED] wrote: well.. instead of using ktrace I'd suggest building profiled pkg_add and see that way where the time is spent. ktrace is great if you dont have the source code... but you do :) If you decide to go this route, you might like to apply http://www.freebsd.org/cgi/query-pr.cgi?pr=99800 By default gmon.out is overwritten by each process so you will only get the output from the last process of a given name. My patch optionally saves the profiling output each process in a separate file. gprof(1) can already accumulate the output from multiple files so this patch gives you the ability to profile multiple executions of a single executable. You will still need to glue together the profiling results from each executable. -- Peter Jeremy Yeah, I noticed that. Thanks for the heads up on the PR :). Why not create a flag though instead of check to see if an environment variables been set? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: AMD deciding _now_ what to do about Linux
On Fri, 15 Jun 2007, Ali Mashtizadeh wrote: Hi, Sun's pushing ATI/AMD to provide good drivers for Solaris, so it means they will have to work on the portability issue of their drivers. It is probably the best time to influence AMD's decision since they are going to do what Sun tells them. Nvidia has an easier time porting their drivers since the core of the driver is the same across all platforms AFAIK. Hopefully, they will realize the best stratedgy is to open source their drivers, which there has been some hints about it recently. -- Ali Mashtizadeh علی مشتی زاده On 6/15/07, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Fri, Jun 15, 2007 at 02:03:39PM -0400, Ali Mashtizadeh wrote: Hey everyone, This email went out on Xorg I thought it might be useful for all of us stuck with ATI cards. We should all show our interest in AMD helping out the BSD community as well! Just like Nvidia has been doing! Linux strategy -- gotta love the use of the word strategy, like they're playing chess or Risk or Daisenryaku. Yes, because supporting an operating system involves strategy. Not to sound rude, but I wouldn't hold your breath over the statement. Yes, *absolutely* mail them and show support for the BSDs, and tell them you'll be happy to beta test whatever they put out (as long as they have a good feedback method for reporting those bugs; not some defunct HTML form web page that sends submissions to /dev/null). I believe AMD/ATI cares about providing a good driver base (for Linux and probably the BSDs), but no matter how many customers mail them, the reality of the situation is a disappointing one: managers and executives of sorts are who have say over all of this, who decide all of this, and who ultimately make the statements on all of this. As a Texan co-worker of mine says, too many chiefs, not enough indians. nVidia has the same problem, for what it's worth. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | 1. This shouldn't have been sent to the hackers@ list, because it's more of a discussion than a technical topic. 2. Please top post. Disregarding those 2 comments, I have a few thoughts: 1. It doesn't matter which company you deal with, ATI/AMD, Intel, nVidia -- all are large corporations and swaying the interest of the execs and legal depts to release corporate secrets and technologies is a big deal because it's their competitive edges in the marketplace. 2. Intel did opensourced their graphics drivers, and of course there's been a great deal of followup discussion about nVidia and ATI doing the same thing, but like Jeremy said I have little faith in the companies opensourcing their drivers for at least 1-2 years because their secrets are their livelihood and they don't want competitors having access to them. 3. The ATI Linux drivers quite frankly suck right now. They're currently at the stage that nVidia was 3-4 years ago with Linux (working, but not on all distros, quite a few hacks in place), and I wasn't impressed in the least by them (hence I dumped my ATI card and purchased an nVidia one). 4. Sun is a lot different than Linux or FreeBSD. Sun is a software/hardware vendor with plenty of financial collateral behind them, so their getting support faster than FreeBSD is more likely, as long as the devs are there to support Solaris. 5. I did email ATI about support and apparently I sent my message to the wrong section (I should have requested a driver enhancement, not filed bug -- I hate some online forms and their lack of clarity). But since I purchased my nVidia card after the fact I never followed up on the reply I got from ATI. I highly doubt your message gets shuffled away into nowhere; it would create a bad corporate image to ignore current/potential customers ;). Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reason for doing malloc / bzero over calloc (performance)?
On Thu, 14 Jun 2007, Ivan Voras wrote: [EMAIL PROTECTED] wrote: Hmmm... I wonder what the Mach kernel in OSX does to allocate memory then. I'll have to take a look at OpenDarwin's source sometime and see what it does. Following the link chain from the benchmark link posted in this thread I've come to the information that it's similar to -CURRENT: small allocations are carved from the local pool, big ones from prezeroed pages (from kernel). Do you know if that's with malloc or calloc? What portion of the source demonstrates this? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reason for doing malloc / bzero over calloc (performance)?
On Thu, 14 Jun 2007, Matthew Dillon wrote: I'm going to throw a wrench in the works, because it all gets turned around the moment you find yourself in a SMP environment where several threads are running on different cpus at the same time, using the same shared VM space. The moment you have a situation like that where you are futzing with the page tables, i.e. using mmap() for demand-zero and munmap() to free, the operation becomes extremely expensive verses anything else because any update to the page table (specifically any removal of page table entries from the page table) requires a SMP synchronization to occur between all the cpu's actively sharing that VM space, and that's on top of the overhead of taking the page fault(s). This is true of any memory mapping the kernel has to do in kernel virtual memory (must be synchronized with ALL cpus) and any mapping the kernel does on behalf of userland for user memory (must be synchronized with any cpu's actively using that VM space, i.e. threaded user programs). The synchronization is required to properly invalidate stale mappings on other cpus and it must be done synchronously due to bugs in Intel/AMD related to changing page table entries on one cpu when instructions are executing using that memory on another cpu. There is no way to avoid it without tripping up on the Intel/AMD hardware bugs. From this point of view it is much, much better to bzero() memory that is already mapped then it is to map/unmap new memory. I recently audited DragonFly and found an insane number of IPIs flying about due to PAGE_SIZE'd kernel mallocs using the VM trick via kernel_map kmem_alloc(). They all went away when I made the kernel malloc use the slab cache for allocations up to and including PAGE_SIZE*2 bytes. Fun, eh? -Matt Matthew Dillon [EMAIL PROTECTED] I have no intention of using malloc/calloc with free, and then repeating the same procedure. It's better just to use the memory allocated, if possible, size permitting this. I wasn't thinking that closely though (ISA/hardware config versus OS implementation), but I had my suspicions since the AMD64 architecture is very different from the PowerPC architecture, in terms of word size, sychronization schemes, instruction count, etc. Interesting insight though. Thanks :). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: On Wed, Jun 13, 2007 at 08:26:38AM -0700, Garrett Cooper wrote: Sorry -- actually I meant that (along similar lines), there was a program with the following lines: vsystem(/bin/chmod +x %s, filename); and I replaced it with: chmod(filename, (mode_t) ( S_IXUSR | S_IXGRP | S_IXOTH )); You supposedly mean stat + chmod here, right? Trivial errors like this are easy to make. Yes . Good catch, thanks :). Next step, eliminating the linked list structure in favor or red-black trees, maybe. Due to the way pkg_install works, this most likely is just adding complexity for no gain, it might actually slow it down. Hmmm... the only thing is that it does the linked list traversal a number of times per dependency. I'll take a look in gdb at the size of each dependency and then confer with Kirill (my mentor) about that a bit more. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: On Wed, Jun 13, 2007 at 11:15:52AM -0500, Rick C. Petty wrote: Another improvement made by using stat(2)/chmod(2) over chmod(1) using system(3) variants is the protection against malicious filenames. The original code should have used fork/execv instead anyway. To be precise, this case should use open/fstat/fchmod to avoid another bunch of race conditions. Joerg Should I briefly lock (flock) the file when running open/fstat/fchmod then to avoid issues? This may become a problem as pkg_*/make becomes more parallelized (another student's goals for his SoC project). Needless to say, pkg_* is by no means threadsafe in its current form though. It uses some global vars that are currently not mutex locked, and this type of file access is another issue (I wonder if spinlocking or sleeping waiting for flock to finish would be better in this case). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reason for doing malloc / bzero over calloc (performance)?
On Wed, 13 Jun 2007, Ed Schouten wrote:
* Garrett Cooper [EMAIL PROTECTED] wrote:
Garrett Cooper wrote:
Title says it all -- is there a particular reason why malloc/bzero
should be used instead of calloc?
-Garrett
As someone just brought to my attention, I should do some Googling.
Initial results brought up this:
http://boredzo.org/blog/archives/2006-11-26/calloc-vs-malloc.
To be more precise; I took a look at the source code of calloc on my
FreeBSD 6 box:
| void *
| calloc(num, size)
| size_t num;
| size_t size;
| {
| void *p;
|
| if (size != 0 SIZE_T_MAX / size num) {
| errno = ENOMEM;
| return (NULL);
| }
|
| size *= num;
| if ( (p = malloc(size)) )
| bzero(p, size);
| return(p);
| }
This means that the results on that website would be quite different
than the the ones that the FreeBSD 6 malloc/calloc should give. There is
even a difference between calloc'ing 10 block of 10 MB and 1 block of
100 MB, which shouldn't make a difference here. calloc doesn't have any
performance-advantage here, because it just calls malloc/bzero.
When looking at FreeBSD -CURRENT's calloc (won't paste it; too long), it
just does a arena_malloc/memset (which is malloc/bzero) for small
allocations but a huge_malloc for big allocations (say, multiple pages
big). The latter one already returns pages that are zero'd by the
kernel, so I suspect the calloc performance for big allocations on
-CURRENT is a lot better than on FreeBSD 6. As with FreeBSD 6, it
wouldn't matter if you calloc 10 pieces of 10 MB or one piece of 100 MB.
Yours,
--
Ed Schouten [EMAIL PROTECTED]
WWW: http://g-rave.nl/
Hmmm... I wonder what the Mach kernel in OSX does to allocate memory then. I'll
have to take a look at OpenDarwin's source sometime and see what it does.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, Rick C. Petty wrote: On Wed, Jun 13, 2007 at 10:23:36AM -0700, [EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007, Joerg Sonnenberger wrote: Should I briefly lock (flock) the file when running open/fstat/fchmod then to avoid issues? This may become a problem as pkg_*/make becomes more parallelized (another student's goals for his SoC project). I wouldn't bother. What issue are you trying to avoid? If one process is trying to chmod +x and another is trying to do a chmod -x, it shouldn't matter if you lock between the fstat/fchmod-- someone is going to win anyway. This operation is not something that needs to be thread-safe. Needless to say, pkg_* is by no means threadsafe in its current form though. It uses some global vars that are currently not mutex locked, and this type of file access is another issue (I wonder if spinlocking or sleeping waiting for flock to finish would be better in this case). Does pkg_* use multiple threads? I was under the impression each pkg tool used a single thread (i.e. no threads) to do its operations and that they wait for system(2)-type calls as needed. Maybe I'm not clear by what you mean when you say global vars. Well, I mean that as it currently stands there are several variables used globally for setting attributes per package (I'm not at my machine right now so I can't look them up until ~6pm PST). Now another question is whether the pkg_* tools can handle multiple processes managing the ports at the same time. For the mostpart, this is true. Without looking at the code, I would expect that the only contentions would be when trying to update the +REQUIRED_BY files. Everything else should be just fine; you're not supposed to be installing the same port multiple times at the exact same time, but maybe a lock could be held on the package directory (i.e. /var/db/pkg/$PKG_NAME). Again, I don't believe this is strictly necessary. Currently, no, and this is a condition that's contingent for a fellow SoC'er's project. The mentor said that all that *should* occur is there should be an flock, but that was it. So instead of making more work for him and since I am modifying pkg_* already, I thought it would be best to just make my modifications to simplify his end (he still has a ways to go on the dependency tracking I think). It goes a bit deeper than the +REQUIRED_BY files, in particular with the +CONTENTS, etc files as the pkg_* tools are enumerating the packages currently on the system, their dependencies, owning files, etc. Perhaps a global .lock file of some kind in the package directories would be the way to go though. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, Tim Kientzle wrote: Next step, eliminating the linked list structure in favor or red-black trees, maybe. Due to the way pkg_install works, this most likely is just adding complexity for no gain, it might actually slow it down. Hmmm... the only thing is that it does the linked list traversal a number of times per dependency. I'll take a look in gdb at the size of each dependency and then confer with Kirill (my mentor) about that a bit more. If you tend to look for the same few items over and over, just move items to the front of the list as soon as you find them. Alternatively, if you know you won't look for this item ever again, move it to the end of the list or remove it from the list entirely. Simple tricks like this can greatly speed things up with almost no effort. Better yet, do easy things like this first; if they help, then look at more complex approaches. As Joerg said, though, you're not likely to gain much from this. pkg_install is almost entirely disk bound. I spent a lot of time recently in libarchive/bsdtar optimizing the disk handling; I can share lots of ideas for improving performance of disk-bound operations like this. Tim Kientzle Thank you Tim. I'll definitely keep that in mind :). -Garrett PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking into the other package utilities closely in the next couple weeks, evaluating what approaches I should take in solving some bottlenecks with installing packages and ports. My goals are up on http://wiki.freebsd.org/GarrettCooper, and will be modified soon. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
On Wed, 13 Jun 2007, Stephen Montgomery-Smith wrote: On Wed, 13 Jun 2007, [EMAIL PROTECTED] wrote: PS I'm looking at pkg_install and pkg_version mostly, but I'll be looking into the other package utilities closely in the next couple weeks, evaluating what approaches I should take in solving some bottlenecks with installing packages and ports. My goals are up on http://wiki.freebsd.org/GarrettCooper, and will be modified soon. Since you are interested in speeding up the pkg_* stuff, I thought I would bring these to your attention (speed ups to the pkg_create and port registration processes, not quite what you are doing, but related). http://www.freebsd.org/cgi/query-pr.cgi?pr=112765 http://www.freebsd.org/cgi/query-pr.cgi?pr=112630 Let me also wish you good luck in your speed improvements. I was rather encouraged by these two, but all my future searches proved somewhat negative. In particular I looked rather hard at trying to speed up make (required for pkg_version when it calls make -V PKGNAME multiple times). I can tell you that in that instance, replacing linear lists by berkeley DB made no difference at all - it was very disappointing. In short, you really want to do a lot of profiling and see where the speed bottlenecks really are before writing lots of code. Stephen Stephen, I have no control over the Makefile revisions, but I'll talk with Kirill about the pkg_* integration / testing, and be sure to note you on the change if it is integrated. I'll take your comments into consideration though :). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panicking in 6.2 and 7-CURRENT -- interrupt issues
On Tue, 29 May 2007 [EMAIL PROTECTED] wrote: Hello, I'm trying to install 7-CURRENT on my desktop, locally instead of on a virtual machine, and I'm running into an issue where the kernel almost always panics on boot with my motherboard (ASUS P5N-SLI E), due to some sort of interrupt assignment / probing issues. Observations: 1. 7-CURRENT (built) never properly detects the interrupts on the system. 2. 7-CURRENT (May ISO snapshot) doesn't properly detect my USB keyboard, but boots and runs sysinstall. 3. 6.2 RELEASE panics if I don't boot FreeBSD up into safe mode, due to an issue with the ohci driver (I think the error message had something to deal with device adding / enumeration and not being able to find a memory / interrupt address). First off, if I could get some of the command line arguments to pass to the kernel to emulate safe-mode, that would be much appreciated. Second off, if anybody has any ideas on how to debug this issue, I'll go off and try to determine what the cause is. If it's anything like it was before (clean out /usr/obj, rebuild), I'll be ok. Otherwise, I'll have to purchase more parts and build another dedicated FreeBSD system :(.. Thanks, -Garrett Sorry for cross-posting so much, but this information is relevant to all of the mailing lists included. Ok I solved my problem, to a certain extent. Basically the ASUS P5N-E SLI motherboard (nVidia chipset) isn't bootable with FreeBSD 6.2 RELEASE without going into SAFE MODE (panics after ohci_add_done looking for a non-existent memory address, if the USB controller is enabled in the BIOS with Legacy Mode, i.e. USB Keyboard compatible), and isn't compatible with FreeBSD 7 at all (kernel can't map IRQs properly on up-to-date CURRENT and panics in kernel mode during boot). Strangely enough the 7-CURRENT snapshot ISOs work, but then again it doesn't setup the OHCI and USB keyboard stuff properly, and I can't get any sort of input from my keyboard, obviously. The ASUS P5B-DLX motherboard (Intel chipset) is compatible with FreeBSD 6.2 and 7 though, without any hacks. Maybe someone should update some documentation on the release notes page for supported hardware? Thanks, -Garrett PS Please CC me in any communication as I'm not subscribed to doc@, stable@, or [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panicking in 6.2 and 7-CURRENT -- interrupt issues
Hello, I'm trying to install 7-CURRENT on my desktop, locally instead of on a virtual machine, and I'm running into an issue where the kernel almost always panics on boot with my motherboard (ASUS P5N-SLI E), due to some sort of interrupt assignment / probing issues. Observations: 1. 7-CURRENT (built) never properly detects the interrupts on the system. 2. 7-CURRENT (May ISO snapshot) doesn't properly detect my USB keyboard, but boots and runs sysinstall. 3. 6.2 RELEASE panics if I don't boot FreeBSD up into safe mode, due to an issue with the ohci driver (I think the error message had something to deal with device adding / enumeration and not being able to find a memory / interrupt address). First off, if I could get some of the command line arguments to pass to the kernel to emulate safe-mode, that would be much appreciated. Second off, if anybody has any ideas on how to debug this issue, I'll go off and try to determine what the cause is. If it's anything like it was before (clean out /usr/obj, rebuild), I'll be ok. Otherwise, I'll have to purchase more parts and build another dedicated FreeBSD system :(.. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
On Wed, 16 May 2007, Rick C. Petty wrote: On Tue, May 15, 2007 at 01:08:03AM -0700, Garrett Cooper wrote: Sorry for all you Java lovers out there.. it's just that from where I'm at I don't see anyone using it in the workplace (Intel). We're all using C/C++/Perl, with occasional spots of Ruby/Python. We use Java almost exclusively (Oracle), although scattered bits of Python and occasional C/C++ thru JNI. Not to start a flame war, but I much prefer Java and I know a lot of other corporations are using it as well (just do a search for software engineer on any job site, and count the Java hits vs. C++). Also, Java outperforms Python/Ruby/Perl on all string manipulations from our extensive tests. However, my group likes the philosophies behind Ruby and likes the rapid development of Python when we need a scripting language. Use the Right Tool for the problem; just because you like using a hammer doesn't mean all screwdrivers are stupid. -- Rick C. Petty Ok, fair enough. But there's a lot of overhead involved with Java with their completely OOP view on programming. Also, although I know that many database solutions companies (in particular Oracle and IBM), do like Java, it's not used in many other regions of the market from what I've seen (Apple, Intel, M$, many other companies that have openings in my school's resume databases). Most want C++, C#, and VB.NET (ew)... and maybe Javascript with AJAX support. Also, since I deleted the original message by accident, I wanted to note that I found a BDB dump feature in MySQL's source, so I'm going to try and adapt that to my SoC project just for research purposes to dump out the table fields and see how Ruby messes with the data. -Garrett PS If you hated BDB and loved SQL, please note that some SQL engines use BDB for a database backend instead of MyISAM, INNODB, etc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
On Wed, 16 May 2007, Rick C. Petty wrote: On Wed, May 16, 2007 at 01:41:27PM -0700, [EMAIL PROTECTED] wrote: Ok, fair enough. But there's a lot of overhead involved with Java with their completely OOP view on programming. Agreed. Also, although I know that many database solutions companies (in particular Oracle and IBM), do like Java, it's not used in many other regions of the market from what I've seen (Apple, Intel, M$, many other companies that have openings in my school's resume databases). Most want C++, C#, and VB.NET (ew)... and maybe Javascript with AJAX support. From what I've seen, after filtering out VB and C#, the next top is Java. I completely agree with you about ew.. not a big fan of C-flat or VB. =) PS If you hated BDB and loved SQL, please note that some SQL engines use BDB for a database backend instead of MyISAM, INNODB, etc. I was aware that MySQL has a lot of backends, but most hosting sites that give you mysql don't give you backend options-- it's MyISAM or die. :-/ Anyway, good luck with the BDB. Have you thought about looking at dbopen(3) or dbm(3)? I'm sure you'll get more FreeBSD supporters if you use something already shipping with the stock system. -- Rick C. Petty It (BDB 1.8.5) is already in the system under: /usr/src/lib/libc/db :) hash(3) and btree(3) have more details in manpage format. I'm just using parts of the MySQL server for research purposes. Thankfully the BDB dump code can be separated from the rest of the code and built modularly =). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On Tue, 15 May 2007, Tom Evans wrote: On Tue, 2007-05-15 at 11:23 -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Dag-Erling Smørgrav [EMAIL PROTECTED] typed: Peter Jeremy [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. It would, if it were true. It isn't. Except it is. apt-get --build source package_name That doesn't update from sources, that just builds a package. You're still stuck updating from packages. Further, like the rpm command, this doesn't deal with dependencies, other than to complain if they aren't met. This means that using it to deal with sources is about as pleasant as using rpm to install binary packages. Further, there doesn't appear to be anything like make.conf to make it easy to tailor the build process to meet the users requirements. mike Of course Gentoo does do this [updating from source], being as it is a rip-off of freebsd ports. I haven't used it since the (fairly) early days when portage was written as a series of bash scripts. I'm fairly sure they must have improved it since then - it made portupgrade look positively snappy. Unsurprisingly, everything was/is controlled by adding options (mainly USE_FLAGS - eg '+gtk2 -kde') to make.conf. Tom Tom, It's gotten excruciatingly more complex with the introduction of Python, classes, and an increase in USE flags. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discovering list of open files from kernel level without using utils like lsof
On Mon, 9 Apr 2007, David Malone wrote: On Sun, Apr 08, 2007 at 11:05:48AM -0700, Garrett Cooper wrote: I'm trying to see whether it's possible to grab the list of files open from a kernel level on FreeBSD, using a userland library interface as opposed to lsof. Have a look at the source code for the fstat utility. It does this in a relatively clean way. David. Will do. Thanks a lot! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discovering list of open files from kernel level without using utils like lsof
On Mon, 9 Apr 2007, Dan Nelson wrote: In the last episode (Apr 08), Garrett Cooper said: I'm trying to see whether it's possible to grab the list of files open from a kernel level on FreeBSD, using a userland library interface as opposed to lsof. I'm trying to see if there's a simple tool that I could code in C/C++ if necessary to spin down disks automatically to save power and disk life. Plus, I think that lsof actually would probe the devices and 'wake them up' instead of keeping them as-is. However, I could be wrong so if I am please let me know. Take a look at how /usr/bin/fstat does it. There is apparently a kern.file sysctl that holds the open file table, but fstat digs through kernel memory. -- Dan Nelson [EMAIL PROTECTED] Ok, excellent. Thanks for more info. I'm thinking of changing spinning down to adjusting acoustics level, i.e. reduce spindle speed to avoid pricey spin-downs, which may cause long-term serious damage to disks. Trying to keep my electric bills down and keep my disk life up :). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discovering list of open files from kernel level without using utils like lsof
On Mon, 9 Apr 2007, Rick C. Petty wrote: On Sun, Apr 08, 2007 at 11:05:48AM -0700, Garrett Cooper wrote: I'm trying to see if there's a simple tool that I could code in C/C++ if necessary to spin down disks automatically to save power and disk life. Plus, I think that lsof actually would probe the devices and 'wake them up' instead of keeping them as-is. However, I could be wrong so if I am please let me know. I read somewhere once that keeping disks spinning makes them last 10x longer. Personally, I've seen more disk failures on workstations which are power-cycled regularly than on systems which are always running. I've also seen disks work just fine while powered that just plain quit immediately after a power cycle. So you may save power by spinning the disks down, but I doubt you're saving disk life (unless they're powered down for weeks at a time). -- Rick C. Petty Hence the followup post. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Examples on using RTC
Hello, I am trying to port a linux program to FreeBSD and I can't (from my knowledge) directly translate RTC code to FreeBSD because the methods used to accomplish stuff with RTC in Linux is different from FreeBSD. So I was wondering if there were any resources, or maybe ports that use a wide variety of rtc features that I could browse through and learn / play with, to test and/or accomplish the goals so I can appropriately abstract and implement RTC in the ported Linux application. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Examples on using RTC
On Fri, 16 Feb 2007 [EMAIL PROTECTED] wrote: Garret, On 2/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I am trying to port a linux program to FreeBSD and I can't (from my knowledge) directly translate RTC code to FreeBSD because the methods used to accomplish stuff with RTC in Linux is different from FreeBSD. So I was wondering if there were any resources, or maybe ports that use a wide variety of rtc features that I could browse through and learn / play with, to test and/or accomplish the goals so I can appropriately abstract and implement RTC in the ported Linux application. Thanks! -Garrett /usr/ports/emulators/rtc regards, usleep Already using / looked at that. I'm looking for something more in-depth. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Examples on using RTC
On Fri, 16 Feb 2007, Mike Silbersack wrote: On Fri, 16 Feb 2007 [EMAIL PROTECTED] wrote: /usr/ports/emulators/rtc regards, usleep Already using / looked at that. I'm looking for something more in-depth. -Garrett The rtc port's sole purpose is to make the vmware port happier. As you probably saw, it just fakes the functions of the linux rtc device. What other rtc functions do you need? Almost everything the linux rtc device does can be accomplished by raising your system hz and using usleep/select. Mike Silby Silbersack Hmmm.. well, I can't seem to find equivalent definitions for the Linux kernel macro RTC_PIE_OFF for instance and the emulators/rtc port isn't sufficiently documented for me to determine how the original author found out what signals RTC_PIE_ON and RTC_IRQP_* (whatever macro is also defined in /usr/local/include/linux/rtc.h). -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007, Coleman Kane wrote: On 2/15/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Olivier Warin [EMAIL PROTECTED] (from Wed, 14 Feb 2007 19:54:09 +0100): This issue is not only related to portupgrade, pkg_add a new port takes far too long now... and make index each time I upgrade my ports is awfull too. Regarding make index: try make fetchindex right after the cvsup. IT may not be up to the point with the cvsupped stuff, but not far off. Bye, Alexander. I don't think we who use the modular X.org tree can do this since a number of the ports won't be properly registered in the file (or am I off-base here?). -- Coleman Heh, that is a serious problem considering that modular Xorg would probably at max add about 100 ~ 150~some packages to the portage tree, depending on how things are done. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007, Michel Talon wrote: Give me a few weeks, and if I can band together with a few people I wanted to try and port sections of portupgrade and its related tools to C++ (and maybe do some code tweaks along the way). Most of the ruby files are over 400 lines long, sparsely commented, and I don't know ruby enough to port right now, but I've been making some headway lately so I'll try porting some stuff soon. I think that porting portupgrade to C++ would be time spent in vain. In my opinion, some of the basic ideas of portupgrade are deeply flawed, and as much as one polishes the algorithms it will not gain much. The idea of keeping state in databases is deeply flawed, it is constantly broken, and doesn't help in speed at all. This was one of the motivations of portmaster, get rid of database dependencies. In my opinion, upgrading progressiveley, that is, port by port, is deeply flawed. There is 90% chance that something will go wrong in the middle and you will be stuck with an half upgraded system. So in my opinion, what is needed is thinking radically new about the problem, write a prototype in a scripting language to experiment with the solutions, and then code it in C++. Personnally i have done that, i have written a python script, which can be found here: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (it needs the companion http://www.lpthe.jussieu.fr/~talon/save_pkg.py). For the time being, i still have bugs, that i am working on, but at least these bugs show that the problem is vastly more complicated that one can imagine at first. Why python? because it is much more readable than perl or ruby, and much more performant than ruby. In may opinion ruby is vastly hyperhyped, it is much closer to rubish than anything else. What ideas? Don't use any database, database connector, do everything in memory, recompute needed information on the fly. It works very well, one can count on something of the order of 1mn to 2mn to perform the necessary analysis for 700 ports. Second, download as much precompiled packages as possible, at full speed, that is with the same connection to the ftp server. This works very well, if you have a good internet connection, in 15 mn to 20 mn you have your packages. Why packages? because packages don't break when compiling. Compiling from source is asking for problems. If you minimise the number of compilations you minimise the risk of breakage. Moreover simultaneously with downloading one can backup old packages, and so, gain time. By contrast, for every packages, portupgrade first does dependency analysis that could be done once, then does backup, then fetches the binary package or compiles, then installs it, then discards backup. Al this is terrible loss of time. Finally my script produces a shell script able to do the upgrade. So you can look in written form to *exactly* what will be removed, what will be installed by binary packages, and what will be compiled. All necessary packages for installation are already present on the machine. There is absolutely no element of surprise, you can evaluate the risk soundly. These are the ideas i have explored. Now, performance wise, when you run the shell script it takes around 2 hours. This is entirely time spent by pkg_delete ( roughly 15 mn) and pkg_add (roughly 1h45mn) for around 500 ports replaced. This is very long, sure, but it can be optimized only by working on pkg_delete and pkg_add. No amount of work on portupgrade or a replacement will help in any way. As for the remaining bugs i have, they are entirely due to the crappy complexity that FreeBSD port developers introduce by constantly modifying the origins of the ports. So for a given program, i can have 3 different origins, one when the port was previously installed on the machine, another one when the last RELEASE was produced, and the last one if i compile now the port on the machine with the present state of the ports tree. These 3 origins may be different, i have examples. These morons are *constantly* modifying the names, as an exercice in bikeshed painting. For example pan - pan2 - pan, etc. Cycles don't worry them at all! Of course, for a given software, you may have all combinations, such as inexistant or existant at the time the machine was installed, at the time of the release, or at present. Compare that to the situation for Debian apt-get. The names are conserved. They have strict rules about package naming, they stick to them and don't change them arbitrarily. All packages exist in compiled form, you don't have to worry about prepackaged or to be compiled, so has 50% chance to break. You have only 2 states to consider instead of 3: the state on the machine and the state on the repository. Things are vastly simpler. No wonders that apt-get works and portupgrade doesn't. This has nothing to do with the fact that apt-get is written in C++ (sorry to cross post, but this thread is just as relevant to @ports as it is to @hackers) Well,
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007, Florent Thoumie wrote: [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007, Coleman Kane wrote: On 2/15/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Olivier Warin [EMAIL PROTECTED] (from Wed, 14 Feb 2007 19:54:09 +0100): This issue is not only related to portupgrade, pkg_add a new port takes far too long now... and make index each time I upgrade my ports is awfull too. Regarding make index: try make fetchindex right after the cvsup. IT may not be up to the point with the cvsupped stuff, but not far off. Bye, Alexander. I don't think we who use the modular X.org tree can do this since a number of the ports won't be properly registered in the file (or am I off-base here?). -- Coleman Heh, that is a serious problem considering that modular Xorg would probably at max add about 100 ~ 150~some packages to the portage tree, depending on how things are done. Yeah, I propose we just stay with X.org 6.9.0. PS: This is ports tree really, not portage tree. -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer Yes, you're right (about the PS). That was a silly misphrase on my part.. Just curious though: why stay with Xorg 6.9? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trying to join an already exited pthread
On Fri, 9 Feb 2007, Daniel Eischen wrote: On Thu, 8 Feb 2007, Garrett Cooper wrote: Actually, now that I think about it the calls I made with ps in the program are valid for Linux but not for FreeBSD (they're for getting thread listings). Hence error code 2. From intro(2): 2 ENOENT No such file or directory. A component of a specified pathname did not exist, or the pathname was an empty string. Didn't think that a bad command would return errno=2 though.. And hopefully you've realized that your code is totally bogus since pthread_foo() don't set errno. All the pthread_foo() functions _return_ the error. If your code is not checking the return values from those functions, it is wrong on every platform, not just FreeBSD. -- DE Well, right. I was just being lazy by checking errno, instead of checking the return value of pthread_*. It wasn't meant to be anything more than a simple set of tests. I thought that errno was set on errors though, but after reading the manpage more carefully it turns out that this is not the case. I'll see if I can fix my checks. Thanks for bringing this to my attention! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_upgrade (was Re: pkg_add does not backtrack, does it?)
On Fri, 9 Feb 2007, Mike Meyer wrote: In [EMAIL PROTECTED], Michel TALON [EMAIL PROTECTED] typed: Funny that i have just announced a program, that i have called pkgupgrade (by analogy with portupgrade, i was not aware of his other work), and whose aim is precisely to do the things you want - i don't pretend it succeeds perfectly, there may be bugs in it, but its aim is indeed to be a substitute to portupgrade, with some differences. Cool. On the downside, for some people it is written in python. Personally, I think that's cool, but it does means it won't go into the base system. Portupgrade would probably be in the base system if it were written in a language in the base system. mike -- Mike Meyer [EMAIL PROTECTED]http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. Would perl be close enough to count, or would it have to be C/C++? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_upgrade (was Re: pkg_add does not backtrack, does it?)
On Sat, 10 Feb 2007, Peter Jeremy wrote: On 2007-Feb-09 09:43:01 -0800, [EMAIL PROTECTED] wrote: On Fri, 9 Feb 2007, Mike Meyer wrote: Personally, I think that's cool, but it does means it won't go into the base system. Portupgrade would probably be in the base system if it were written in a language in the base system. Would perl be close enough to count, or would it have to be C/C++? Perl was removed in 5.x. Your options are shell, awk and C/C++. -- Peter Jeremy C++ would be it then. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel headers dependency graph ? (systm.h tangle)
On Thu, 8 Feb 2007, Luigi Rizzo wrote: Hi, Is there a tool to produce a dependency graph for C headers ? If that matters (i.e. someone has already studied it), i am interested in the header situation in the FreeBSD kernel. It may be a well known thing, but i just realized that sys/systm.h is entagled with sys/libkern.h and both bring in a lot of other headers, and you cannot bring in simply the string.h functions, or printf, because there is no leaf header for them. I don't know if this is the only case, or there are other 'classes' which are intermixed with lots of other stuff. I suppose the problem has been already discussed and it is just the result of historical reasons, but is there any reason other than ENOTIME why (to cite things that are trivial to fix while preserving compatibility): - we don't have sys/string.h with all the memcpy/bcopy and friends that are currently spread between systm.h and libkern.h - printf/scanf and strto*() are not in their own header; and so on ? cheers luigi Not sure if it's been done before, but it sounds like a good job for Perl or (I can't believe I'm suggesting this) Ruby. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Trying to join an already exited pthread
Just wondering: If I was to try and join a pthread that already exited, would there be an error message output and/or errno set to an error value, or would a system hang? It this variable on Unix OSes? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trying to join an already exited pthread
On Wed, 7 Feb 2007, Pietro Cerutti wrote: On 2/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Just wondering: If I was to try and join a pthread that already exited, would there be an error message output and/or errno set to an error value, or would a system hang? man pthread_join(3): ERRORS The pthread_join() function will fail if: [EINVAL] The implementation has detected that the value speci- fied by thread does not refer to a joinable thread. A pthread that already exited is considered non-joinable It this variable on Unix OSes? The pthread_join() function conforms to ISO/IEC 9945-1:1996 (``POSIX.1''). Excellent. Thank you very much for the info! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
