search for: readonly

...between 125MB and 133MB and "gdb maintenance > info sections" produces: > > --- snip --- > (gdb) maintenance info sections > Exec file: > ??? `/usr/libexec/dovecot/imap', file type elf64-x86-64. > ??? 0x00000238->0x00000254 at 0x00000238: .interp ALLOC LOAD READONLY > DATA HAS_CONTENTS > ??? 0x00000254->0x00000274 at 0x00000254: .note.ABI-tag ALLOC LOAD > READONLY DATA HAS_CONTENTS > ??? 0x00000274->0x00000298 at 0x00000274: .note.gnu.build-id ALLOC LOAD > READONLY DATA HAS_CONTENTS > ??? 0x00000298->0x00000a0c at 0x00000298: ....

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

...emory. However gcc now automatically supplies this information to us. I checked on my x86 linux box what gcc gives for the functions listed in those tables. While gcc mostly agrees with them, there are the following differences (using -ffast-math, otherwise gcc says that a bunch of math ones are readonly because they depend on the floating point mode; I think gcc is correct to say this): function LLVM says gcc says -------- --------- -------- isalnum readnone readonly isalpha readnone readonly iscntrl readnone readonly isgraph readnone readonly islower readnone readonly isprint readnone read...

...s blow up. The core file sizes are between 125MB and 133MB and "gdb maintenance info sections" produces: --- snip --- (gdb) maintenance info sections Exec file: `/usr/libexec/dovecot/imap', file type elf64-x86-64. 0x00000238->0x00000254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS 0x00000254->0x00000274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS 0x00000274->0x00000298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS 0x00000298->0x00000a0c at 0x00000298: .gnu.hash ALLOC LOAD READONLY...

I declare some checkboxes : <%= check_box_tag ''offers[]'', offer.id , @params[:offers].include?(offer.id.to_s) ,:readonly=>true %> the result is : <input checked="checked" id="offers[]" name="offers[]" readonly="readonly" type="checkbox" value="1" /> But readonly doesn''t work ??? -- Posted via http://www.ruby-forum.com/.

The previous patch argued that globally affecting .can_write based on '-r' (the global 'readonly') prevents the ability for a filter to call next_open(nxdata, true) to purposefully write to the plugin, even while advertising .can_write=0 to the client. But it also demonstrated that when a filter passes false to next_open, we were still making needless probes into the plugin, for something...

...m plugins, not filters. Filters should use the .open(...exportname) parameter if they need the export name. Filter .reopen also takes the exportname. The only filter that uses it (retry) must save the exportname from .open in order to pass it to .reopen. This filter already does the same for the readonly flag so this seems reasonable. The handling of NBD_OPT_SET_META_CONTEXT interacted with the export name (see commit 20b8509a9ccdab118ce7b7043be63bbad74f1e79). I have attempted to keep previous behaviour in this change, but note that there is no regression test for this. I added a debug message s...

...kit-filter.pod b/docs/nbdkit-filter.pod index 12343dbf..b6ed5504 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -403,7 +403,7 @@ Returns a copy of the C<i>'th export. =head2 C<.open> void * (*open) (nbdkit_next_open *next, void *nxdata, - int readonly, const char *exportname); + int readonly, const char *exportname, int is_tls); This is called when a new client connection is opened and can be used to allocate any per-connection data structures needed by the filter. @@ -420,8 +420,9 @@ error message and return C<NULL>....

...=head2 Next config, open and close @@ -355,7 +355,7 @@ from the layer below. Without error checking it would look like this: struct nbdkit_export e; char *name, *desc; - exports2 = nbdkit_exports_new (default_only); + exports2 = nbdkit_exports_new (); next_list_exports (nxdata, readonly, default_only, exports); for (i = 0; i < nbdkit_exports_count (exports2); ++i) { e = nbdkit_get_export (exports2, i); @@ -376,11 +376,9 @@ an error message and return C<-1>. Two functions are provided to filters only for allocating and freeing the list: - struct nbdkit_exports...

...Iend, Jstr,Jend INTEGER :: i, j REAL*8, INTENT(INOUT) :: a(Li:,Lj:) REAL*8, INTENT(IN) :: b(Li:,Lj:) --snip-- I got the below LLVM IR, the parameters received. --snip-- ; Function Attrs: norecurse nounwind define void @test_(i64* noalias nocapture %a, i64* noalias nocapture readonly %b, i64* noalias nocapture readonly %li, i64* noalias nocapture readonly %lj, i64* noalias nocapture readonly %istr, i64* noalias nocapture readonly %iend, i64* noalias nocapture readonly %jstr, i64* noalias nocapture readonly %jend, i64* noalias nocapture readonly %"a$sd", i64* noalias n...

Seeing `g.add_drive_opt :readonly => 1` allows one to imply that ensuring writable access to drive should happen via `g.add_drive_opt :readonly => 0`. However, the passed option value gets passed down to C according to Ruby Boolean semantics, that is, any value apart from `false` and `nil` will be true (see RTEST in Ruby C AP...

...; > On Sun, Mar 8, 2015 at 9:55 AM, Nicholas Chapman > <admin at indigorenderer.com <mailto:admin at indigorenderer.com>> wrote: > > Hi all, > I have identified what seems to be a limitation of LLVM with > regard to marking 'sret functions' as pure/readonly. > > For some context - I have some JITed code produced by LLVM, and > that code calls back into the host application occasionally. > Since my language is purely functional, no functions have > side-effects. Therefore I would like to be able to cache the > val...

...!invariant.group effectively > useless for describing constant fields which are constant per instance > rather than per-class. > Yes, this family of examples scares me. :) It seems we've discovered a new device testing IR soundness. We used it to build a test case that shows that 'readonly' on arguments without 'nocapture' doesn't let you forward stores across such a call. Consider this pseudo-IR and some possible transforms that I would expect to be semantics preserving: void f(i32* readonly %a, i32* %b) { llvm.assume(%a == %b) store i32 42, i32* %b } ... %...

Hi all, I have identified what seems to be a limitation of LLVM with regard to marking 'sret functions' as pure/readonly. For some context - I have some JITed code produced by LLVM, and that code calls back into the host application occasionally. Since my language is purely functional, no functions have side-effects. Therefore I would like to be able to cache the value of identical calls back into the host appli...

Hi Holger, > Note that I did specify "-g", but not any "-Ox" switches. That > made the size of all *.o files together being 143 MB. LLVM represents debug info as explicit calls to intrinsics. This approach has many advantages, but a possible disadvantage is that it can significantly increase the size of the bitcode. I don't know if that explains your observations.

Hi, All, These four patches are all related to ocfs2 on hard readonly mount. patch 1 fix oops when umount ocfs2 on hard readonly device. Because ocfs2_dismount_volume() will call ocfs2_cluster_hangup() and then call ocfs2_stack_driver_put(), will hit BUG_ON(active_stack == NULL). patch 2 fix oops when do ls or cat in ocfs2 on hard readonly device. Because ocfs2_ope...

Hello Is there a way to mount a directory as readonly when using LXC with libvirt? Something like: <filesystem type="mount"> <source dir="/sw/py27/python2.7_x86_64"/> <target dir="/opt//py27"/> <readonly/>...

Hi I am trying to Run AsteriskNow 1.5 which uses Centos 5.3 Distribution with Readonly Root Filesytem. Right now if I shutdown the system abrupty or there is power failure linux kernel doesn't not boot "Kernel panic" and other short of issues.prb due to corrupted files. Thats why i want to make root filesystem as read-only and placing some directories /var and /etc/as...

...4 23:13:46 Richard W.M. Jones wrote: > diff --git a/src/drives.c b/src/drives.c > index 2c85b52..68e37f7 100644 > --- a/src/drives.c > +++ b/src/drives.c > @@ -115,7 +115,8 @@ static struct drive * > create_drive_file (guestfs_h *g, const char *path, > bool readonly, const char *format, > const char *iface, const char *name, > - const char *disk_label, const char *cachemode) > + const char *disk_label, const char *cachemode, > + enum discard discard) > { > struct dr...

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t...