On Sat, 24 Mar 2018, Andre McCurdy wrote:
On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky wrote:
On Sat, 24 Mar 2018, Burton, Ross wrote:
On 24 March 2018 at 20:12, Victor Kamensky wrote:
Here is another crazy idea how to deal with it, just
brainstorming what options are on the table: d
On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky wrote:
> On Sat, 24 Mar 2018, Burton, Ross wrote:
>> On 24 March 2018 at 20:12, Victor Kamensky wrote:
>>>
>>> Here is another crazy idea how to deal with it, just
>>> brainstorming what options are on the table: disable
>>> renameat2 with help of
On Sat, 24 Mar 2018, Burton, Ross wrote:
On 24 March 2018 at 20:12, Victor Kamensky wrote:
Here is another crazy idea how to deal with it, just
brainstorming what options are on the table: disable
renameat2 with help of seccomp and force coreutils to
use other calls. Something along the line
On 24 March 2018 at 20:12, Victor Kamensky wrote:
> Here is another crazy idea how to deal with it, just
> brainstorming what options are on the table: disable
> renameat2 with help of seccomp and force coreutils to
> use other calls. Something along the lines that were
> suggested with intercept
On Sat, 24 Mar 2018 15:22:47 -0500
Joshua Watt wrote:
> I don't think that is true. libc's syscall() must conform to the *C*
> ABI for the system... if the kernel does things that aren't in line
> with the C ABI (like return things in registers that aren't expected,
> fail to preserve registers t
On Sat, Mar 24, 2018 at 12:50 PM, Seebs wrote:
>
> pseudo's call sequence:
> various_setup()
> real_syscall() // sets a3
> other system calls // also set a3
> return
You don't need to know that the kernel returns a result in any
particular register. The libc syscal
On Sat, Mar 24, 2018 at 2:50 PM, Seebs wrote:
> On Sat, 24 Mar 2018 12:42:45 -0700
> Andre McCurdy wrote:
>
>> Right. The musl example is to show how it's possible to transparently
>> intercept and pass on any call to the syscall() ABI without
>> interpreting anything.
>
> Yes, if you don't need
Here is another crazy idea how to deal with it, just
brainstorming what options are on the table: disable
renameat2 with help of seccomp and force coreutils to
use other calls. Something along the lines that were
suggested with intercept of syscall function call, but
let kernel to do interception
On Sat, 24 Mar 2018 12:42:45 -0700
Andre McCurdy wrote:
> Right. The musl example is to show how it's possible to transparently
> intercept and pass on any call to the syscall() ABI without
> interpreting anything.
Yes, if you don't need to interpret things, and aren't making
additional other un
On Sat, Mar 24, 2018 at 12:24 PM, Seebs wrote:
>
> I didn't see a qualifier about it being only on a 32-bit architecture,
> it just says "EABI".
>
> But in general, this is the reason that musl's ability to work doesn't
> buy us guarantees; musl doesn't have to *interpret* the arguments. So
> for
On Sat, 24 Mar 2018 11:59:27 -0700
Andre McCurdy wrote:
> The EABI example applies to 64bit values on 32bit architectures. Since
> pointers are 32bit values on 32bit architectures the example doesn't
> apply to renameat2 (which only passes int's and pointers - nothing
> which would be a 64bit val
Hello,
It appears Xorg is deprecating most of it's proto header repos for a new
all-in-1 repo xorgproto. This will most likely affect down stream
layers. The question I have, is do we want this big churn to happen for
Sumo or wait for 2.6 ?
- armin
These are now included in xorgproto, the dep
On Sat, Mar 24, 2018 at 11:22 AM, Seebs wrote:
>
> Every other function we wrap *has* a meaningful prototype, with
> arguments in a knowable order. But look at the EABI example; if we want
> to actually *process* renameat2(), it's not enough to pass arguments on
> blindly, we have to be sure we kn
On Sat, 24 Mar 2018 11:12:20 -0700
Andre McCurdy wrote:
> If you can successfully intercept the libc syscall() API and return
> ENOTSUPP for the one specific case of renameat2 but pass on all other
> callers transparently then haven't you've already solved the bulk of
> the problem (for the non-G
On Sat, Mar 24, 2018 at 10:23 AM, Seebs wrote:
> On Sat, 24 Mar 2018 17:10:47 +
> "Burton, Ross" wrote:
>> On 24 March 2018 at 12:36, Richard Purdie
>> wrote:
>> > I think, at least in principle, pseudo could wrap that and intercept
>> > this particular syscall, check syscall_number (the num
Update to the latest stable release
Changes in this update:
Add the .pc file to the list of -dev files
Move py3cairo header to -dev package
Added a comment for why the .pc and .h file are re-installed
Verified native build and dependency builds (python3-pygobject and bootchart2)
Tested in q
On Sat, 24 Mar 2018 17:10:47 +
"Burton, Ross" wrote:
> On 24 March 2018 at 12:36, Richard Purdie
> wrote:
> > I think, at least in principle, pseudo could wrap that and intercept
> > this particular syscall, check syscall_number (the numbering having
> > its own set of issues) and then only
On 24 March 2018 at 12:36, Richard Purdie
wrote:
> I think, at least in principle, pseudo could wrap that and intercept
> this particular syscall, check syscall_number (the numbering having its
> own set of issues) and then only handle the specific problem case we
> have.
And to make things easie
Hello,
While working on updating the current bind to the next patch level, I
noticed our current version 9.10.6 will EOL June 2018. I know we are
under feature freeze for the Sumo release.
Could we make an exception and allow an update of bind to the ESV
version 9.11.3 ?, it EOL's Dec 2021.
rega
On Sat, 24 Mar 2018 12:36:28 +
Richard Purdie wrote:
> I think, at least in principle, pseudo could wrap that and intercept
> this particular syscall, check syscall_number (the numbering having
> its own set of issues) and then only handle the specific problem case
> we have.
I think the pro
Update the python{3}-setuptools to the latest stable version
Tested on the qemu with core-image-minimal
Signed-off-by: Derek Straka
---
meta/recipes-devtools/python/python-setuptools.inc| 4 ++--
.../{python-setuptools_39.0.0.bb => python-setuptools_39.0.1.bb} | 0
.../
Update to the latest stable version
Signed-off-by: Derek Straka
---
.../python/{python3-pip_9.0.2.bb => python3-pip_9.0.3.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-pip_9.0.2.bb =>
python3-pip_9.0.3.bb} (90%)
diff --g
On Fri, 2018-03-23 at 18:56 -0500, Seebs wrote:
> On Fri, 23 Mar 2018 23:47:30 +
> Richard Purdie wrote:
> > > I... am really unsure whether it's possible to catch that,
> > > because
> > > I really, really, don't want to try to intercept raw syscall()
> > > calls. I don't think that ends well
23 matches
Mail list logo