Re: SoC2009: libpkg, pkg tools rewrite
On Sat, Apr 25, 2009 at 03:20:59PM -0400, David Forsythe wrote: This summer I'll be working on creating a package library and using that library to rewrite the pkg tools. Jeremy Lea wrote: Since I've already done most of the work on this already, please, please, please, don't ignore what I have done. Garrett Cooper wrote: There's also http://libpkg.berlios.de/ that you could use as a starting point, and please, PLEASE, don't neglect the SoC work that was done last year by Anders Nore. It was committed to p4, but hasn't made it upstream to CVS yet... Good architectural summaries would help here; I know David already has a lot of background reading planned before start-of-coding this summer. Can you provide pointers to design documents or email threads discussing any of these? I'm not familiar with Anders work; what is the current status of it? Why hasn't it been pushed into SVN yet? Is there a good summary of what it does so far and what remains to be done? Cheers, Tim ___ 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: SoC2009: libpkg, pkg tools rewrite
Jeremy Lea: > 1. The library needs a global "package manager". This needs to perform > all of the tasks, and it should ideally do this through a task queue > (which I didn't implement). See the lib/lib.h header in FreePKG. This sounds like a good idea to implement ... eventually. First job is to identify the tasks and a way to implement them. It's relatively straightforward to add a task queue wrapper later on. > 4. bsd.port.mk should do everything through the tools. It should have > no knowledge of the contents of /var/db/pkg. I agree with this in principle, but I think it would be better to avoid touching bsd.port.mk at all in this iteration. Certainly, it's worthwhile to read bsd.port.mk carefully to try to understand the capabilities missing from the current tools with an eye to supporting those in a future iteration, but I think it's more important to keep the scope of this summer's work as narrow as possible. > 1. I made the file->pkg database to sensitive. If there is a miss it > rebuilds the database for scratch - it should do a search through the > +CONTENTS files and only rebuild it if there was a hit (meaning the > database was wrong). I'm going to show my ignorance here: Why is this database necessary at all? On my system with just over 500 packages, it takes <1s to read all of /var/db/pkg with a warm cache (~10s cold cache), and I can only think of a couple of cases where the file->pkg database is useful at all. I fear that maintaining a file->pkg database is a lot of extra effort for very little gain. I would be more interested in experimenting with using extended attributes directly on the files to record what package they came from. In particular, that provides much more robust handling for a variety of use cases, including conflicts, stale files, and manually-updated files. > 2. There needs to be a pkgname and origin database, which can be loaded > at startup to prime the package manager. The dependency graph should > also be stored in a database. These should be rebuilt if any directory > in /var/db/pkg has a mtime later than the database (so could the file > database). Again, I'm a little skeptical of the need for separate databases here at all. In the current system, /var/db/pkg and the package archives themselves have to be authoritative, so any package system has to be able to work directly from that information. Building a separate database from that information seems like a lot of extra work that will pay off someday but can be largely avoided for the current iteration. Remember that the Single Point of Truth for any package manager is the files on disk. If someone deletes the files from disk, then the package is not installed, regardless of what any "package database" might say. In the case of the FreeBSD package system, /var/db/pkg is therefore secondary data and any additional databases you compute from /var/db/pkg are tertiary. This is getting pretty far from the SPoT and is going to lead to increasing consistency problems. If we can avoid these additional databases, we'll get a simpler, more robust system. > 3. There needs to be a set of flags which indicate how a package got > installed (as a dependency or by the user), and if it has been upgraded > in-place and might have old leftover libraries. These could go in > +CONTENTS. Yes, these are the kind of features that should be easy to add after the package tools have been rewritten around libpkg. But first we need a basic libpkg that works and a set of package tools that use it. > In addition I also began the design of a new on disk package format. I'm pretty firmly opposed to this. I think that the INDEX, /var/db/pkg, and binary format for package archives all need to be kept essentially unchanged, simply because of the growing number of third-party tools that interact with them. Eventually, such tools may all be rewritten to use libpkg, at which point it may be reasonable to reconsider, but for the foreseeable future, any changes to these would cause a lot of pain for little gain. There may be some incremental changes (such as the installation flags you mention above) that would help, but I think we're stuck with the current formats for the time being. I'll also observe that some of the concerns that drove your new package archive design are no longer relevant; libarchive allows us to use tar format without forking the tar executable. Tim ___ 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"
ZFS ARC Cache: What is the lowest tested size
Hello List Worked on breaking ZFS we came across a interesting question; What is the lowest tested ZFS ARC Cache size ? Also could you reliably run with it set to 0 ? -- Mark Saad ms...@datapipe.com () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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"
VirtualBox on FreeBSD
Looks like the VirtualBox developers at Sun ported VirtualBox to FreeBSD in their spare time: http://www.freebsdnews.net/2009/05/02/sun-virtualbox-on-freebsd/ They're looking for developers/testers to checkout the source and try it out :-) -matt ___ 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: VirtualBox on FreeBSD
On Mon, May 04, 2009 at 10:25:58AM -0700, Matt Olander wrote: > Looks like the VirtualBox developers at Sun ported VirtualBox to > FreeBSD in their spare time: > http://www.freebsdnews.net/2009/05/02/sun-virtualbox-on-freebsd/ > > They're looking for developers/testers to checkout the source and try > it out :-) Awesome! I will test it out, if it works out that means I could change my GFs desktop to FreeBSD. ^_^ -- Guillermo Antonio Amaral Bastidas (gamaral) Free/Libre/Open-Source Software Developer : http://www.guillermoamaral.com/ KDE Official Representative MX: http://www.kde.org/ PC-BSD Official Representative MX : http://www.pcbsd.org/ GPG Fingerprint: E068 811D 4AA2 7FDA A327 38BD 640D 014C 76FE 7D5A pgpJVSQa188q4.pgp Description: PGP signature
bootstrapping gnat GCC on amd64
Hello. I'm attempting to compile GNAT on AMD64 with an eye to extending support to the platform (the gnat-gcc43 port is ONLY_FOR_ARCH=i386). GNAT obviously requires an Ada compiler to bootstrap. What are my options here? I suspect that I need to create an i386 jail to build a cross compiler but am not sure. Any help would be appreciated. xw ___ 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: bootstrapping gnat GCC on amd64
On Mon, 4 May 2009, xorquew...@googlemail.com wrote: Hello. I'm attempting to compile GNAT on AMD64 with an eye to extending support to the platform (the gnat-gcc43 port is ONLY_FOR_ARCH=i386). GNAT obviously requires an Ada compiler to bootstrap. What are my options here? I suspect that I need to create an i386 jail to build a cross compiler but am not sure. Is that your only system (amd64)? I originally ported GNAT to FreeBSD x86 from a solaris-sparc32 system. I built a sparc-sun-freebsd GNAT cross compiler using the native Solaris GNAT binary and its associated sources. I also (first) had to cross build binutils similarly. This made a cross compiler that ran on Solaris and built ELF binaries for FreeBSD. I then used this cross compiler to rebuild GNAT as a FreeBSD binary. So it was 2 major steps: build a cross compiler, then use the cross to build a native compiler. It's been years since I've done that. I don't know how much has changed, but you probably have to do something similar. -- DE ___ 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: bootstrapping gnat GCC on amd64
On 2009-05-04 14:44:52, Daniel Eischen wrote: > Is that your only system (amd64)? I originally > ported GNAT to FreeBSD x86 from a solaris-sparc32 system. > I built a sparc-sun-freebsd GNAT cross compiler using > the native Solaris GNAT binary and its associated > sources. I also (first) had to cross build binutils > similarly. This made a cross compiler that ran on > Solaris and built ELF binaries for FreeBSD. I then > used this cross compiler to rebuild GNAT as a FreeBSD > binary. So it was 2 major steps: build a cross compiler, > then use the cross to build a native compiler. > > It's been years since I've done that. I don't know > how much has changed, but you probably have to do > something similar. > > -- > DE Hello. I have a debian system with a working x86 gnat gcc 4.3.3 and a freebsd x86 system running gnat gcc 4.3.2. I guess the first step will be an i386->amd64 cross compiler then. Thanks, xw ___ 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: bootstrapping gnat GCC on amd64
On Mon, 4 May 2009, xorquew...@googlemail.com wrote: On 2009-05-04 14:44:52, Daniel Eischen wrote: Is that your only system (amd64)? I originally ported GNAT to FreeBSD x86 from a solaris-sparc32 system. I built a sparc-sun-freebsd GNAT cross compiler using the native Solaris GNAT binary and its associated sources. I also (first) had to cross build binutils similarly. This made a cross compiler that ran on Solaris and built ELF binaries for FreeBSD. I then used this cross compiler to rebuild GNAT as a FreeBSD binary. So it was 2 major steps: build a cross compiler, then use the cross to build a native compiler. It's been years since I've done that. I don't know how much has changed, but you probably have to do something similar. -- DE Hello. I have a debian system with a working x86 gnat gcc 4.3.3 and a freebsd x86 system running gnat gcc 4.3.2. I guess the first step will be an i386->amd64 cross compiler then. Right, you should be able to do it from either of those, but perhaps the freebsd x86 may be easier. I would use a PREFIX other than /usr/local (or something different than whatever your actual PREFIX is) for the builds. I was looking around for my notes but can't find them. If I do find them, I'll post them. -- DE ___ 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: Definition of NULL
On Saturday 02 May 2009 11:59:03 am Andrew Brampton wrote: > I'm writing a C++ Kernel Module, and one thing that has been bugging > me is the kernel's definition of NULL. > > sys/sys/_null.h (in CURRENT): > > #if defined(_KERNEL) || !defined(__cplusplus) > #define NULL((void *)0) > #else > #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 > #define NULL__null > #else > #if defined(__LP64__) > #define NULL(0L) > #else > #define NULL0 > #endif /* __LP64__ */ > #endif /* __GNUG__ */ > #endif /* _KERNEL || !__cplusplus */ > > >From what I've read online the definition of NULL in C is (void *)0, > whereas in C++ it should be 0, or 0L (on 64bit machines). > > Now, my C++ kernel module is built with _KERNEL definited, like any > other C kernel module. This leads to NULL being defined incorrectly. > > So I have a question and two suggestions. Firstly, why is the #if > defined(_KERNEL) in _null.h? Is it to stop userland application > applications picking up this definition? Or for another reason? Yes. NULL used to be 0. When it was changed to '(void *)0' I believe it broke several applications in ports. As a compromise, NULL was restored back to 0 in userland and only set to '(void *)0' in the kernel. > and two, how about we change the first line of _null.h so that we use > a && instead of a || like so: > #if defined(_KERNEL) && !defined(__cplusplus) I think this would be ok to let C++ work in the kernel. "Embedded" C++ (no exceptions and no dynamic_cast<>) should work fine in theory. I would not change the value of NULL that userland sees though as I think that may be too risky. -- John Baldwin ___ 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: ZFS ARC Cache: What is the lowest tested size
On Mon, May 4, 2009 at 10:12 AM, Mark Saad wrote: > > Hello List > Worked on breaking ZFS we came across a interesting question; > What is the lowest tested ZFS ARC Cache size ? I haven't tested it with just over 64MB, but the code indicates that that is the lowest you should try. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c 3500 /* 3501 * Allow the tunables to override our calculations if they are 3502 * reasonable (ie. over 64MB) 3503 */ 3504 if (zfs_arc_max > 64<<20 && zfs_arc_max < physmem * PAGESIZE) 3505 arc_c_max = zfs_arc_max; 3506 if (zfs_arc_min > 64<<20 && zfs_arc_min <= arc_c_max) 3507 arc_c_min = zfs_arc_min; >Also could you reliably > run with it set to 0 ? For better and worse, ZFS isn't primarily a file system. It is a transactional object store that has a file system as one type of object. The ARC is not a file system buffer cache, it caches virtual device blocks. You might think of it as being more like a very large write-back drive cache. It might work with less than 64MB, but the ARC buffers are what ZIO sends down to disk so it certainly would not work with zero. Cheers, Kip ___ 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: bootstrapping gnat GCC on amd64
On 2009-05-04 15:03:32, Daniel Eischen wrote: > Right, you should be able to do it from either of those, > but perhaps the freebsd x86 may be easier. > > I would use a PREFIX other than /usr/local (or something > different than whatever your actual PREFIX is) for the > builds. > > I was looking around for my notes but can't find them. > If I do find them, I'll post them. I've built an i386 jail and am currently building the gnat-gcc43 port to compile a GNAT cross-compiler (i386 -> amd64). There are two reasons for this whole exercise: I just moved over to amd64 and want a native toolchain and I also have a lot of software written in Ada that I'd like to submit to FreeBSD ports but can't due a lack of an Ada compiler on amd64. I noticed that the gnat-gcc43 port downloads a rather anonymous set of gcc 4.1 bootstrap binaries. I assume I'd have to provide my own in the same manner to create a port? xw ___ 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: bootstrapping gnat GCC on amd64
On Tue, 5 May 2009, xorquew...@googlemail.com wrote: On 2009-05-04 15:03:32, Daniel Eischen wrote: Right, you should be able to do it from either of those, but perhaps the freebsd x86 may be easier. I would use a PREFIX other than /usr/local (or something different than whatever your actual PREFIX is) for the builds. I was looking around for my notes but can't find them. If I do find them, I'll post them. I've built an i386 jail and am currently building the gnat-gcc43 port to compile a GNAT cross-compiler (i386 -> amd64). There are two reasons for this whole exercise: I just moved over to amd64 and want a native toolchain and I also have a lot of software written in Ada that I'd like to submit to FreeBSD ports but can't due a lack of an Ada compiler on amd64. I noticed that the gnat-gcc43 port downloads a rather anonymous set of gcc 4.1 bootstrap binaries. I assume I'd have to provide my own in the same manner to create a port? Yes, you can look at my lang/gnat port to find its bootstrap compiler. I would recommend making a binary bootstrap compiler on the earliest version of FreeBSD amd64 as you can. If you use 8.0-current for instance, others will not be able to build the port on 7.x. -- DE ___ 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: bootstrapping gnat GCC on amd64
On 2009-05-04 20:54:46, Daniel Eischen wrote: > Yes, you can look at my lang/gnat port to find its > bootstrap compiler. I would recommend making a binary > bootstrap compiler on the earliest version of FreeBSD > amd64 as you can. If you use 8.0-current for instance, > others will not be able to build the port on 7.x. Earliest version of FreeBSD that fully supports this hardware is 7.2, so I personally can't go back to an earlier release than that. ___ 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: bootstrapping gnat GCC on amd64
On Tue, 5 May 2009, xorquew...@googlemail.com wrote: On 2009-05-04 20:54:46, Daniel Eischen wrote: Yes, you can look at my lang/gnat port to find its bootstrap compiler. I would recommend making a binary bootstrap compiler on the earliest version of FreeBSD amd64 as you can. If you use 8.0-current for instance, others will not be able to build the port on 7.x. Earliest version of FreeBSD that fully supports this hardware is 7.2, so I personally can't go back to an earlier release than that. Keep good notes - maybe someone else can do it once you have the procedure down and working ;-) -- DE ___ 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: NetBSD 5.0 statistics
On Thu, Apr 30, 2009 at 01:41:42PM -0700, Marcel Moolenaar wrote: > I recall that our "make -j X" actually limits the number > of make processes/jobs to X. I don't know anything about > build.sh, so I don't know if our make is at all being > involved, but it would be good to know how the load varies > per OS. build.sh is using NetBSD's make for all but the tool build and the tool build is not included in the stats. Joerg ___ 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: Definition of NULL
On Mon, May 04, 2009 at 10:46:02AM -0400, John Baldwin wrote: > I think this would be ok to let C++ work in the kernel. "Embedded" C++ (no > exceptions and no dynamic_cast<>) should work fine in theory. I would not > change the value of NULL that userland sees though as I think that may be too > risky. Well, use __null if present all the time, fallback to the alternatives as currently defined. Joerg ___ 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"
