search for: vlen

...rn NULL; + } + } + if (end_stringsbuf (&ret) == -1) { + free_stringsbuf (&ret); + return NULL; + } + + return take_stringsbuf (&ret); +} + static int compare_xattrs (const void *vxa1, const void *vxa2) { @@ -106,7 +135,8 @@ getxattrs (const char *path, { ssize_t len, vlen; CLEANUP_FREE char *buf = NULL; - size_t i, j; + CLEANUP_FREE_STRING_LIST char **names = NULL; + size_t i; guestfs_int_xattr_list *r = NULL; buf = _listxattrs (path, listxattr, &len); @@ -114,18 +144,17 @@ getxattrs (const char *path, /* _listxattrs issues reply_with_perror a...

...odup (&ret, &buf[i]) == -1) + return NULL; + } + if (end_stringsbuf (&ret) == -1) + return NULL; + + return take_stringsbuf (&ret); +} + static int compare_xattrs (const void *vxa1, const void *vxa2) { @@ -106,7 +132,8 @@ getxattrs (const char *path, { ssize_t len, vlen; CLEANUP_FREE char *buf = NULL; - size_t i, j; + CLEANUP_FREE /* not string list */ char **names = NULL; + size_t i; guestfs_int_xattr_list *r = NULL; buf = _listxattrs (path, listxattr, &len); @@ -114,18 +141,17 @@ getxattrs (const char *path, /* _listxattrs issues reply_wit...

v1 here: https://www.redhat.com/archives/libguestfs/2020-March/msg00099.html This one fixes most of the points picked up in review, and does not strdup the strings which should keep down memory usage if that is a concern. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1811539 Commands including virt-diff which read extended attributes will sometimes fail on NTFS filesystems that are using system compressed. The reason is complex, see comment 5 of the bug linked above. This patch filters out the troublesome xattr. For justification, see the comment I added in patch 3. Patch 1 & 2 are refactoring. I was on the

Hi, attached there is a prototype of patch for adding a new copy-attributes command. Such command would allow copy the attributes of a "file" to another, so for example in guestfish: copy-attributes foo bar permissions:true xattributes:false would only copy the permissions of foo to bar, not copying its extended attributes too. Just few notes: - my first daemon command, so

...buntu 10.10 probably had only some of them. We don't care about RHEL 5 since it now has its own branch ("oldlinux"), so the code might be made simpler by an accompanying patch which reduces all of the HAVE_*XATTR* macros down to a single one (HAVE_LINUX_XATTRS). > + ssize_t len, vlen, ret; > + CLEANUP_FREE char *buf = NULL, *attrval = NULL; > + size_t i, attrval_len = 0; > + > + CHROOT_IN; > + len = listxattr (src, NULL, 0); > + CHROOT_OUT; > + if (len == -1) { > + reply_with_perror ("listxattr: %s", src); > + goto error; > +...

...mon/xattr.c b/daemon/xattr.c index ebacc02..abed5ff 100644 --- a/daemon/xattr.c +++ b/daemon/xattr.c @@ -541,8 +541,77 @@ do_lgetxattr (const char *path, const char *name, size_t *size_r) return buf; /* caller frees */ } +int +copy_xattrs (const char *src, const char *dest) +{ + ssize_t len, vlen, ret, attrval_len = 0; + CLEANUP_FREE char *buf = NULL, *attrval = NULL; + size_t i; + + buf = _listxattrs (src, listxattr, &len); + if (buf == NULL) + /* _listxattrs issues reply_with_perror already. */ + goto error; + + /* What we get from the kernel is a string "foo\0bar\0baz...

...lyline is defined by two vectors, one for the x coordinates, one for the y coordinates, you can try the following library(NISTunits) polyangles <- function(xV,yV) { stopifnot( (length(xV)==length(yV)) && (length(xV) >= 3)) v <- function(i) { c( xV[i]-xV[i-1], yV[i]-yV[i-1])} vlen <- function(v) { sqrt(sum(v*v)) } lV <- rep(NA_real_,length(xV)) for ( i in 2:(length(xV)-1) ) lV[i] <- acos( sum(v(i)*v(i+1))/(vlen(v(i))*vlen(v(i+1))) ) angleV <- NISTunits::NISTradianTOdeg(lV) angleV } # example x <- c(0:3) y <- c(0,0,1,1) polyangles( x, y ) # NA...

...NTRY_TYPE_BINARY = 2, /* Binary blob */ + REGISTRY_TABLE_ENTRY_TYPE_STRING = 3, /* Null-terminated string */ +}; + +/** + * registry_list_entry - linked list member for a registry key/value + * @head: list_head struct + * @type: dword, binary, or string + * @klen: the length of name of the key + * @vlen: the length of the value + * @v.dword: the data, if REGISTRY_TABLE_ENTRY_TYPE_DWORD + * @v.binary: the data, if TYPE_BINARY or TYPE_STRING + * @key: the key name + * + * Every registry key/value is represented internally by this struct. + * + * Type DWORD is a simple 32-bit unsigned integer, and it...

...time a function is called, a positive integer called the *dynamic vector length* is determined in an unspecified way. The dynamic vector length can differ not only between different functions, but also between different calls to the same function. The exception is that functions with the `inherits_vlen` attribute get the same dynamic vector length as their caller (Note: this attribute is a straw man, target-specific calling conventions may work better for this purpose). A new instruction `vlentoken` is added, which has no operands and is of type `token`. This token represents the dynamic vector...

.... From what I gather, you're just interested in the former, >> so is there a good reason "<n x 1 x <ty>>" wouldn't work for your use case? >> The 'n' is just a term to indicate it's a multiple only known at runtime; >> you've used 'vlen', and there are other suggested names, but there's >> nothing to tie it to an exact size -- if your dynamic vlen changes with >> each function, the 'n'/'vlen' just represents the current value. >> > > If the vector length changes at run time, some opt...

...rminated string > > */ > > +}; > > + > > +/** > > + * registry_list_entry - linked list member for a registry key/value > > + * @head: list_head struct > > + * @type: dword, binary, or string > > + * @klen: the length of name of the key > > + * @vlen: the length of the value > > + * @v.dword: the data, if REGISTRY_TABLE_ENTRY_TYPE_DWORD > > + * @v.binary: the data, if TYPE_BINARY or TYPE_STRING > > + * @key: the key name > > + * > > + * Every registry key/value is represented internally by this struct. > > +...

...ith the same number of bits. From what I gather, you're just interested in the former, so is there a good reason "<n x 1 x <ty>>" wouldn't work for your use case? The 'n' is just a term to indicate it's a multiple only known at runtime; you've used 'vlen', and there are other suggested names, but there's nothing to tie it to an exact size -- if your dynamic vlen changes with each function, the 'n'/'vlen' just represents the current value. If the vector length changes at run time, some optimizations that otherwise make perfe...

I think you and I are talking two different things. As far as Intel’s vector function ABI is concerned, unless the programmer specifically says otherwise, given an OpenMP declare simd function, compiler will deduce the VF from HW vector register size and other function signatures. Of course, there can be different vector function ABIs for different targets. Intel compiler cost model uses vector

...called, a positive integer called the *dynamic > vector length* is determined in an unspecified way. The dynamic vector > length can differ not only between different functions, but also between > different calls to the same function. The exception is that functions with > the `inherits_vlen` attribute get the same dynamic vector length as their > caller (Note: this attribute is a straw man, target-specific calling > conventions may work better for this purpose). > > A new instruction `vlentoken` is added, which has no operands and is of > type `token`. This token repres...

...> mechanism. Loops are supposed to be designed to run a few more times on > lower spec'd hardware. > > Robin, what's your thoughts there? > Software should be portable across different RVV implementations, in particular across different values of the impl-defined constants VLEN, ELEN, SLEN. But being portable does not mean software must never mention these (and derived quantities such as vscale or, in the RVV spec, VLMAX) at all, just that it has to work correctly no matter which value they have. And in fact, there is a published (written out in the spec) mechanism for ob...

...one for the x > coordinates, one for the y coordinates, you can try the following > > library(NISTunits) > polyangles <- function(xV,yV) { > stopifnot( (length(xV)==length(yV)) && (length(xV) >= 3)) > v <- function(i) { c( xV[i]-xV[i-1], yV[i]-yV[i-1])} > vlen <- function(v) { sqrt(sum(v*v)) } > > lV <- rep(NA_real_,length(xV)) > for ( i in 2:(length(xV)-1) ) > lV[i] <- acos( sum(v(i)*v(i+1))/(vlen(v(i))*vlen(v(i+1))) ) > angleV <- NISTunits::NISTradianTOdeg(lV) > angleV > } > > # example > x <- c(...

...rcstat.st_mode & 0777)); > > I suspect you want 07777 in order to copy sticky/setuid/setgid bits. > Perhaps those should be a separate flag, but we definitely want to > copy them! Right, fixed to be part of the permissions (or mode actually, see below). > > + ssize_t len, vlen, ret; > > + CLEANUP_FREE char *buf = NULL, *attrval = NULL; > > + size_t i, attrval_len = 0; > > + > > + CHROOT_IN; > > + len = listxattr (src, NULL, 0); > > + CHROOT_OUT; > > + if (len == -1) { > > + reply_with_perror ("listxattr: %s&qu...

...fully support these targets from the start. Without these generic intrinsics, we would either need to emit target specific ones or go through the painful process of VLA-style reduction trees with loops or the like. -- setting the vector length (MVL) -- I really like the idea of the `inherits_vlen` attribute. Absence of this attribute in a callee means we can safely stop tracking the vector length across the call boundary. However, i think there are some issues with the `vlen token` approach. * Why do you need an explicit vlen token if there is a 1 : 1-0 correspondence between functions...

...example I anticipate having vector operations calling for shifting. I'll be shifting vectors to the right (or left) like below while maintaining the length and filling with zeros. Keep in mind I'll ultimately be dealing with vectors with very large length. >x <- c(0,3,2,1,0,0,0) >vlen <- length(x) [1] 7 One solution to accomplish the right shift is to do something like: >x=c(0,x[1:vlen-1]) >x 1] 0 0 3 2 1 0 0 this does the trick though I'm wondering if this is in the spirit of "Vectorization". I could make recursive function that would cycle through the...