apply(1) and libsbuf
Hi, I was looking to fix a bug (bin/95079) in apply(1) and found it easy to fix it using a sbuf buffer. Does anyone see a problem with adding libsbuf dependency for an utility such apply(1)? Nothing in usr.bin seems to use libsbuf currently. The patch: http://people.freebsd.org/~jh/patches/apply-sbuf.diff -- Jaakko ___ 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: Building FreeBSD on a linux FC11 box.
On Sat, 20.02.2010 at 13:03:14 -0800, R. Tyler Ballance wrote: > On Sat, 20 Feb 2010, Patrick Mahan wrote: > > Hopefully, this is not too ignorant a question. But has anyone every > > built the FreeBSD sources, both kernel and apps, on a linux platform? > > > > I did a google on 'cross-compile freebsd (linux)' and found (mostly) > > discussions regarding building the linux apps for FreeBSD, but not > > for building a FreeBSD kernel and world. There was a brief discussion > > on the mailing list back in 2005, but the poster never reported if > > he had success or failure. Also, there were discussions about building > > freebsd amd64 on a freebsd i386. > > > > I have done lots of development in linux using cross-compilers (mips > > embedded systems, powerpc, etc). But not with FreeBSD. > > > > I know I'll need to use 'bsdmake' no gnu 'make'. The other worry is > > kernel-toolchain target. I guess I'll just dive in and swim around > > and see what happens. > > You might want to ask the Debian GNU/kFreeBSD guys: > http://www.debian.org/ports/kfreebsd-gnu/ > > I bet they've got a good idea :) They are using the kernel only, though. Before you reinvent the wheel, take a look at NetBSD, they are known for their cross-compilation work. Uli ___ 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: GEOM_ULZMA
On Sat, 20 Feb 2010 21:43:03 -0800 Tim Kientzle wrote: > b. f. wrote: > >>> The code organization depends on what you want to do with it and how you > >>> want to update the code in the future, if your lzma library is third > >>> party. > >> LZMA made by Igor Pavlov, and since 4.62 it licensed under Public Domain. > >> So we can use it, if we need. > >> > >>> If you never intend to update the lzma code then I guess it's fine to > >>> embed it in a big .c file. For a port, it doesn't matter much since it > >>> is your own thing. There are stricter rules on maintainability and style > >>> if you want it in the base system. > >> So, I think right place for lzma library under sys/contrib directory, if I > >> "promise" >maintain it? > > > > There are already long-standing plans to import lzma compression > > libraries into the base system, by the libarchive maintainers. > > Libarchive has hooks to support the liblzma library > from Lasse Collin's "xz utils" package. When linked > against this library, libarchive (and hence bsdtar) > has full support for "bare" lzma streams and for > Collin's "xz" format (which is a big improvement over > bare lzma streams). Like Igor Pavlov's original > code, the "xz utils" code is in the public domain. > > Officially, xz utils is in version 4.999.8beta; Collin > has promised to bump the version to 5.0 once he feels > the code is sufficiently stable. As far as I can > tell, it's actually in pretty good shape now; the > changes going in seem to mostly be minor portability > fixes. I see no reason to not import the current > version into the FreeBSD base system. I plan > to do so but may not get to it very soon; I > certainly would not complain if someone else > beat me to it. ;-) > > There are other lzma libraries around, of course. > In particular, I've seen references to the lzma libraries > distributed with lzip. Unfortunately, lzip is GPLv3 > so is not a candidate for inclusion in FreeBSD's base > system. > > Tim > Thanks for that info. GEOM_ULZMA contain two parts mkulzma and GEOM module. libarchive can help for mkulzma utility, but how they can help for GEOM module? I need to know, where correct place for lzma code in kernel tree? -- Alex RAY ___ 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: junior tasks wiki page - please add stuff
On Fri, Feb 19, 2010 at 12:13 AM, Garrett Cooper wrote: > On Thu, Feb 18, 2010 at 11:22 AM, Eitan Adler > wrote: >> I made a wiki page[1] to list small odd-jobs that beginners to work >> on. It is intended to answer the question "I'm just starting out with >> coding, what can I help with?" The tasks put on the wiki page should >> be things that require little programming skill. >> >> It would become a lot more useful if people added things to do. >> >> [1] http://wiki.freebsd.org/JuniorJobs > > 1. Who should the wiki content `regulators' be (i.e. project-only > folks, outside folks, etc)? Anyone can sign up for an account and > because the information reflects on the project, it would be best > (IMO) if `proposals' // `tasks' were vetted by someone in the project > with sufficient say to prioritize the item. I could see a number of ways to deal with this. Ideally this list would be integrated with the PR database. However this requires a lot of time on the part of people with access to the PR database. Another possibility is just "mailing list proposals". People ask on -questions if something could be implemented which gets a lot of positive responses. Someone notices and adds it to the list. Alternatively it could be used as a semi request - not everything the list will make it in - it would just be a starting point. > 2. Would it be a good idea to also provide a list of tasks that > are non-coding related (or at least have a smaller scope) so that > others could assist with in the project to help free up resources? We have http://wiki.freebsd.org/WantedPorts for ports For instance, some folks (like linimon@) really need a junior person (I've > debated whether or not I should do it, but I don't want to assume too > much responsibility) to do semi-menial tasks like bug triage, > feedback, basic administration items, etc to free up Mark's time. That > way it would allow someone with less background and exposure to the > project to become more integrated with the project, outside of doing > an SoC project for instance. Agreed - I think that doing some small project on this list might be a good way to start. > Just curious... > Thanks, > -Garrett > ___ 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: GEOM_ULZMA
I see no reason to not import the current version [of liblzma and xz] into the FreeBSD base system. I plan to do so but may not get to it very soon; I certainly would not complain if someone else beat me to it. ;-) Thanks for that info. GEOM_ULZMA contain two parts mkulzma and GEOM module. libarchive can help for mkulzma utility, but how they can help for GEOM module? I need to know, where correct place for lzma code in kernel tree? I think you mean "liblzma" can help. I plan to import liblzma into FreeBSD base system as /usr/lib/liblzma.a and /usr/lib/liblzma.so (that may change to /lib/liblzma.so), with the headers in /usr/include/. I expect xz to end up as /usr/bin/xz. I'm not familiar enough with kernel development processes to understand the implications there. 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"
`make cleanworld` and /usr/obj/lib32/usr/src
hi there, anybody fancy the idea of including /usr/obj/lib32/usr/src in the cleanworld target on amd64? cheers. alex ___ 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: "tar tfv /dev/cd0" speedup patch
Juergen, Could you try the current version of read_open_filename from: http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c You should be able to just copy it into your FreeBSD source tree and recompile. Duane Hesser's comments clarified for me that disk and tape I/O do require fundamentally different strategies, so I refactored this code to clearly break out those strategies. This in turn allowed me to do some straightforward I/O optimization of the disk case, which sped up your example by about 100x. I have a 2G DVD here on which "tar tvf /dev/acd0" took 90s originally, takes 14s with your patch, and now takes only 0.6s. For comparison, after mounting the disk, "find /mnt" takes 1.6s (which drops to .1s after the cache is warmed). It would be interesting to also compare two ways of copying all of the files: "tar xvf /dev/acd0" on an unmounted disk and "cp -R" on a mounted disk. The non-disk cases are all still handled generically, but there are now clearly-labeled holes where someone could add optimized I/O strategies for tapes, sockets, etc. I've even included a number of TODO comments about what strategies I think are worth exploring, including tricks like using MTIO ioctls on tape, mmap() for disk, and nonblocking I/O for sockets and pipes. I expect any one of these is around a dozen lines of code, so should be within the reach of even fairly junior developers. 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"
