[PATCH] open_memstream() and open_wmemstream()
I've written an implementation of open_memstream() and open_wmemstream() along with a set of regression tests. I'm pretty sure open_memstream() is correct, and I believe open_wmemstream() is correct for expected usage. The latter might even do the right thing if you split a multi-byte character across multiple writes. One question I have is if my choice to discard any pending multi-byte state in the stream anytime a seek changes the effective position in the output stream. I think this is correct as stdio will flush any pending data before doing a seek, so if there is a partially parsed character we aren't going to get the rest of it. http://www.FreeBSD.org/~jhb/patches/open_memstream.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: LK_RETRY set with incompatible flags
Sergey Kandaurov wrote:
On 5 February 2013 04:13, Rick Macklem rmack...@uoguelph.ca wrote:
Sergey Kandaurov wrote:
On 4 February 2013 06:32, Rick Macklem rmack...@uoguelph.ca
wrote:
Konstantin Belousov wrote:
On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
Andriy Gapon wrote:
on 31/01/2013 15:29 Sergey Kandaurov said the following:
Hi.
Got this assertion on idle NFS server while `ls -la
/.zfs/shares/'
issued on NFS client.
Ok, here's a snippet of zfs_dirlook() from zfs_dir.c:
388 } else if (name[0] == '.' name[1] == '.' name[2] == 0)
{
389 zfsvfs_t *zfsvfs = dzp-z_zfsvfs;
390
391 /*
392 * If we are a snapshot mounted under .zfs, return
393 * the vp for the snapshot directory.
394 */
395 if ((error = sa_lookup(dzp-z_sa_hdl,
396 SA_ZPL_PARENT(zfsvfs), parent, sizeof (parent))) != 0)
397 return (error);
398 if (parent == dzp-z_id zfsvfs-z_parent != zfsvfs) {
399 error = zfsctl_root_lookup(zfsvfs-z_parent-z_ctldir,
400 snapshot, vpp, NULL, 0, NULL, kcred,
401 NULL, NULL, NULL);
402 return (error);
403 }
Just reading the comment, I don't know what it is referring to by
snapshot directory. Would that be shares for Sergey's case?
It seems too obvious, but maybe the lookup of .. is returning
the
vnode for /.zfs/shares for this case?
I don't know why this wouldn't have shown up before, but maybe it
usually
replies from its cache (I think zfs_lookup() calls it a fast
path).
It might still be interesting to replace zfs_vnops.c line# 1451
with:
if ((cnp-cn_flags ISDOTDOT) *vpp != dvp)
and see what happens?
With this change `ls /home/user1001/.zfs/shares/' lists empty
directory
(although the relevant dataset has snapshot, but that's a different
story :)).
Great!
Nothing panics/asserts/etc, just seemingly unrelated LOR
Yes, I think the patch is relatively safe, since lookup() checks for
same vnode and does a vrele() instead of a vput() when they are the
same,
at least for a plain lookup without wantparent.
So, since I've never used ZFS, what does a ls -la
/home/user1001/.zfs/shares/
give you when done locally one the server?
On server (with unmodified kernel):
# ls -la /pool1/user1001/.zfs/share
total 2
dr-xr-xr-x 2 root wheel 2 Feb 2 20:06 .
dr-xr-xr-x 4 root wheel 4 Feb 2 20:06 ..
It crashes only when .zfs/share is accessed via NFS
(with and without snapshots), and not when accessed locally.
I'm not surprised. If it crashed for local accesses, I would
suspect people would have reported it much sooner.
I also suspect it only happens for NFSv4 mounts, since those
try and cross server mount points.
Since I don't understand ZFS, I have just posted a query on
freebsd-fs@, which I hope will get noticed by people who
may know why ZFS is doing this.
rick
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Cross-architecture package installs
I'm working on tools to build ARM system images. Usually, these tools run on x86, which creates a problem for packages. I would like to install packages onto the image as it's built. So I've been experimenting with variations of pkg -c DESTDIR add package files I'm running into a few problems but I think they can all be solved. Only the first is critical; the rest are relatively minor annoyances. 1) Pre-install/post-install scripts. These obviously don't work since the DESTDIR is for a different architecture. At least for post-install, it should be possible to record which packages still need their post-install scripts run and arrange to run them after first boot. I'm picturing an rc.d script that invokes pkg with appropriate options to find all packages that still need their post-install run and runs them. This won't work for pre-install, but those are rarer and we can hopefully work around them on a case-by-case basis. 2) The chroot happens before opening the package files. It's possible to work around this by copying all of the package files into DESTDIR first, but that's both time-consuming and rather awkward. (And quite tricky if you're installing directly onto a mounted image that has very little free space.) It should be feasible to open the package files first and then chroot. Then the actual installation still happens entirely inside DESTDIR. 3) Bogus failed to install messages. As far as I can tell, if bar depends on foo, then pkg add bar foo will do this: Installing bar … Installing foo … done done Installing foo … foo already installed. Failed to install the following package: foo. This is surprising since foo did in fact get installed. In my case, I want to say pkg add * and just have it DTRT. It mostly does get the ordering right (I'm impressed!) but the error message is a bit odd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Need to test new patch of Ethernet Switch Framework
Hi, I saw a report that covers FreeBSD-related projects between October and December 2010 and I observe that it have new patch for Ethernet Switch Framework, I have also seen a little bit inside the code of patch( http://loos.no-ip.org/rspro/switch-1.diff). I downloaded fresh code of FreeBSD v9 and apply command git apply switch-1.diff but it shows me these errors: Code: switch.diff:397: trailing whitespace. printf(\tphy %d , ifmr.ifm_phy); switch.diff:445: trailing whitespace. printb(options, ifswr.ifsw_flags, IFSWBITS); switch.diff:486: trailing whitespace. printf(\tvlans: ); switch.diff:869: trailing whitespace. } switch.diff:1826: trailing whitespace. } warning: sbin/ifconfig/Makefile has type 100755, expected 100644 error: patch failed: sbin/ifconfig/Makefile:23 error: sbin/ifconfig/Makefile: patch does not apply error: patch failed: sys/mips/atheros/ar71xx_machdep.c:144 error: sys/mips/atheros/ar71xx_machdep.c: patch does not apply error: patch failed: sys/mips/atheros/if_arge.c:565 error: sys/mips/atheros/if_arge.c: patch does not apply I am very interested to test this patch, can anyone help me out to do this... Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cross-architecture package installs
On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote: I'm working on tools to build ARM system images. Usually, these tools run on x86, which creates a problem for packages. First Yes cross-installation of packages is something we highly want in pkgng and is plan since the beginning, that is one of the reason pkg -c is readig the ABI from the DESTDIR, to make sure we only install things that are abi compatible.. I would like to install packages onto the image as it's built. So I've been experimenting with variations of pkg -c DESTDIR add package files I'm running into a few problems but I think they can all be solved. Only the first is critical; the rest are relatively minor annoyances. 1) Pre-install/post-install scripts. These obviously don't work since the DESTDIR is for a different architecture. At least for post-install, it should be possible to record which packages still need their post-install scripts run and arrange to run them after first boot. I'm picturing an rc.d script that invokes pkg with appropriate options to find all packages that still need their post-install run and runs them. This won't work for pre-install, but those are rarer and we can hopefully work around them on a case-by-case basis. This is imho the main problem, and one of the long term goal of pkgng is to remove as much as possible any pre-instal/post-install scripts. The second problem you will get into is the API that call system()/exec()/etc for example all the call the pw_mkdb from libutil :( We are open for all suggestions here 2) The chroot happens before opening the package files. It's possible to work around this by copying all of the package files into DESTDIR first, but that's both time-consuming and rather awkward. (And quite tricky if you're installing directly onto a mounted image that has very little free space.) It should be feasible to open the package files first and then chroot. Then the actual installation still happens entirely inside DESTDIR. In fact pkg add is only mean to be used in special case if in that particular case you would have used pkg -c DESTDIR install packagename using a repository you would have created on your host using pkg repo to create the metadata thing necessary. problem your packagesite should served via a http/ftp not file except if the files are also locate inside the chroot. 3) Bogus failed to install messages. As far as I can tell, if bar depends on foo, then pkg add bar foo will do this: Installing bar … Installing foo … done done Installing foo … foo already installed. Yeah as said above pkg add as to be forgotten as much as possible, it has been created mostly for the ports tree and the ports build script so that they don't need too much changes other that s/pkg_add/pkg add/g Failed to install the following package: foo. This is surprising since foo did in fact get installed. In my case, I want to say pkg add * and just have it DTRT. It mostly does get the ordering right (I'm impressed!) but the error message is a bit odd. Just do pkg install -x . or pkg install -g * ordering would be ok without odd message. pkg add does not ordering, I'm surprised you got it right :) regards, Bapt PS: I CCed freebsd-pkg@, which is a new mailing list dedicated to this kind of discussion pgpRhzn7RWBEQ.pgp Description: PGP signature
Re: Cross-architecture package installs
On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote: I'm working on tools to build ARM system images. Usually, these tools run on x86, which creates a problem for packages. fwiw, before the intrusion 3 months ago, I had been able to build native ARM packages with a loaned system. Now, granted, this was pretty slow, but it was a useful reference point. Unfortunately none of the packages or logfiles are online at this time. When I was at MeetBSD in California, I learned that the Foundation is sponsoring an effort to get emulation for tier-2 machines in working order, and that this will be the plan for package building going forwards. This is just FYI so you don't spend a great deal of time on each individual port. I know the problems will be hard to solve. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
