>>> Process checkpointing needs to bite the bullet and
>>> create its own API instead.
>>
>> This is bad approach as well. What we should do is come up with a sane
>> API that makes sense without the checkpoint-restore project _when_
>> _possible_.
>
> Coming up with a sane API in general isn't
Process checkpointing needs to bite the bullet and
create its own API instead.
This is bad approach as well. What we should do is come up with a sane
API that makes sense without the checkpoint-restore project _when_
_possible_.
Coming up with a sane API in general isn't easy.
That's
On Mon, Feb 11, 2013 at 3:53 PM, Pavel Emelyanov wrote:
> On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
>> On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
> I suppose I had wondered along similar lines, but in a slightly
> different direction: would the use of a /proc interface to
On 02/10, Andrew Vagin wrote:
>
> On Sat, Feb 09, 2013 at 11:53:04PM +0100, Michael Kerrisk (man-pages) wrote:
> >
> > This looks promising, but I am not sure I understand the user-space
> > API. Could you explain how it would look to (say) pull all per-thread
> > signals from user space?
> >
>
>
On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
> On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
I suppose I had wondered along similar lines, but in a slightly
different direction: would the use of a /proc interface to get the
queued signals make some sense?
>>>
>>> I think
On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
>> > I suppose I had wondered along similar lines, but in a slightly
>> > different direction: would the use of a /proc interface to get the
>> > queued signals make some sense?
>>
>> I think that /proc interface beats adding magic flags and
On Mon, Feb 11, 2013 at 10:29:50AM +0100, Denys Vlasenko wrote:
> On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
> > >> >Damn. But after I wrote this email I realized that llseek() probably
> > >> >can't
> > >> > work. Because peek_offset/f_pos/whatever has to be shared with
On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
> >> >Damn. But after I wrote this email I realized that llseek() probably can't
> >> > work. Because peek_offset/f_pos/whatever has to be shared with all
> >> > processes
> >> > which have this file opened.
> >
> > Yes. but I
On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
Damn. But after I wrote this email I realized that llseek() probably can't
work. Because peek_offset/f_pos/whatever has to be shared with all
processes
which have this file opened.
Yes. but I thought you decided
On Mon, Feb 11, 2013 at 10:29:50AM +0100, Denys Vlasenko wrote:
On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
Damn. But after I wrote this email I realized that llseek() probably
can't
work. Because peek_offset/f_pos/whatever has to be shared with all
On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin ava...@parallels.com wrote:
I suppose I had wondered along similar lines, but in a slightly
different direction: would the use of a /proc interface to get the
queued signals make some sense?
I think that /proc interface beats adding magic
On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin ava...@parallels.com wrote:
I suppose I had wondered along similar lines, but in a slightly
different direction: would the use of a /proc interface to get the
queued signals make some sense?
I think
On 02/10, Andrew Vagin wrote:
On Sat, Feb 09, 2013 at 11:53:04PM +0100, Michael Kerrisk (man-pages) wrote:
This looks promising, but I am not sure I understand the user-space
API. Could you explain how it would look to (say) pull all per-thread
signals from user space?
On Mon, Feb 11, 2013 at 3:53 PM, Pavel Emelyanov xe...@parallels.com wrote:
On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin ava...@parallels.com wrote:
I suppose I had wondered along similar lines, but in a slightly
different direction: would the
On Sat, Feb 09, 2013 at 07:22:39PM +0100, Oleg Nesterov wrote:
> On 02/08, Michael Kerrisk (man-pages) wrote:
> >
> > On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> > >
> > > Well. I do not know. Up to you and Michael.
> > >
> > > But honestly, I can't say this all looks really nice. And
On Sat, Feb 09, 2013 at 11:53:04PM +0100, Michael Kerrisk (man-pages) wrote:
> On Sat, Feb 9, 2013 at 7:22 PM, Oleg Nesterov wrote:
> > On 02/08, Michael Kerrisk (man-pages) wrote:
> >>
> >> On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> >> >
> >> > Well. I do not know. Up to you and
On Sat, Feb 09, 2013 at 11:53:04PM +0100, Michael Kerrisk (man-pages) wrote:
On Sat, Feb 9, 2013 at 7:22 PM, Oleg Nesterov o...@redhat.com wrote:
On 02/08, Michael Kerrisk (man-pages) wrote:
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov o...@redhat.com wrote:
Well. I do not know. Up
On Sat, Feb 09, 2013 at 07:22:39PM +0100, Oleg Nesterov wrote:
On 02/08, Michael Kerrisk (man-pages) wrote:
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov o...@redhat.com wrote:
Well. I do not know. Up to you and Michael.
But honestly, I can't say this all looks really nice. And
On Sat, Feb 9, 2013 at 7:22 PM, Oleg Nesterov wrote:
> On 02/08, Michael Kerrisk (man-pages) wrote:
>>
>> On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
>> >
>> > Well. I do not know. Up to you and Michael.
>> >
>> > But honestly, I can't say this all looks really nice. And why do we
>> >
On 02/08, Michael Kerrisk (man-pages) wrote:
>
> On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> >
> > Well. I do not know. Up to you and Michael.
> >
> > But honestly, I can't say this all looks really nice. And why do we
> > need SIGNALFD_PEEK then?
>
> It surely is no beauty. The hope
On 02/08, Michael Kerrisk (man-pages) wrote:
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov o...@redhat.com wrote:
Well. I do not know. Up to you and Michael.
But honestly, I can't say this all looks really nice. And why do we
need SIGNALFD_PEEK then?
It surely is no beauty. The hope
On Sat, Feb 9, 2013 at 7:22 PM, Oleg Nesterov o...@redhat.com wrote:
On 02/08, Michael Kerrisk (man-pages) wrote:
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov o...@redhat.com wrote:
Well. I do not know. Up to you and Michael.
But honestly, I can't say this all looks really nice. And
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> On 02/08, Andrey Wagin wrote:
>>
>> 2013/2/7 Oleg Nesterov :
>> > Andrey, sorry for delay.
>> >
>> > As for API, I leave this to you and Michael. Not that I like these
>> > new flags, but I agree that pread() hack was not pretty too.
>> >
>>
On 02/08, Andrey Wagin wrote:
>
> 2013/2/7 Oleg Nesterov :
> > Andrey, sorry for delay.
> >
> > As for API, I leave this to you and Michael. Not that I like these
> > new flags, but I agree that pread() hack was not pretty too.
> >
> > On 01/29, Andrey Vagin wrote:
> >> +static ssize_t
On 02/08, Andrey Wagin wrote:
2013/2/7 Oleg Nesterov o...@redhat.com:
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty too.
On 01/29, Andrey Vagin wrote:
+static ssize_t
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov o...@redhat.com wrote:
On 02/08, Andrey Wagin wrote:
2013/2/7 Oleg Nesterov o...@redhat.com:
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty
On Thu, Feb 7, 2013 at 10:13 PM, Andrey Wagin wrote:
> 2013/2/7 Oleg Nesterov :
>> Andrey, sorry for delay.
>>
>> As for API, I leave this to you and Michael. Not that I like these
>> new flags, but I agree that pread() hack was not pretty too.
>>
>> On 01/29, Andrey Vagin wrote:
[...]
>>Damn.
2013/2/7 Oleg Nesterov :
> Andrey, sorry for delay.
>
> As for API, I leave this to you and Michael. Not that I like these
> new flags, but I agree that pread() hack was not pretty too.
>
> On 01/29, Andrey Vagin wrote:
>> +static ssize_t signalfd_peek(struct signalfd_ctx *ctx,
>> +
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty too.
On 01/29, Andrey Vagin wrote:
> +static ssize_t signalfd_peek(struct signalfd_ctx *ctx,
> + siginfo_t *info, loff_t
2013/2/7 Oleg Nesterov o...@redhat.com:
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty too.
On 01/29, Andrey Vagin wrote:
+static ssize_t signalfd_peek(struct signalfd_ctx *ctx,
+
On Thu, Feb 7, 2013 at 10:13 PM, Andrey Wagin ava...@gmail.com wrote:
2013/2/7 Oleg Nesterov o...@redhat.com:
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty too.
On 01/29, Andrey Vagin
Andrey, sorry for delay.
As for API, I leave this to you and Michael. Not that I like these
new flags, but I agree that pread() hack was not pretty too.
On 01/29, Andrey Vagin wrote:
+static ssize_t signalfd_peek(struct signalfd_ctx *ctx,
+ siginfo_t *info, loff_t
2013/2/2 Michael Kerrisk (man-pages) :
>
> On Jan 30, 2013 8:05 AM, "Andrey Vagin" wrote:
>>
>> If signalfd is created with the flag SFD_PEEK, it reads siginfo-s
>> without dequeuing signals.
>>
>> For reading not first siginfo pread(fd, buf, size, pos) can be used,
>> where ppos /
2013/2/2 Michael Kerrisk (man-pages) mtk.manpa...@gmail.com:
On Jan 30, 2013 8:05 AM, Andrey Vagin ava...@openvz.org wrote:
If signalfd is created with the flag SFD_PEEK, it reads siginfo-s
without dequeuing signals.
For reading not first siginfo pread(fd, buf, size, pos) can be used,
If signalfd is created with the flag SFD_PEEK, it reads siginfo-s
without dequeuing signals.
For reading not first siginfo pread(fd, buf, size, pos) can be used,
where ppos / sizeof(signalfd_siginfo) is a sequence number of a signal
in a queue.
This functionality is required for checkpointing
If signalfd is created with the flag SFD_PEEK, it reads siginfo-s
without dequeuing signals.
For reading not first siginfo pread(fd, buf, size, pos) can be used,
where ppos / sizeof(signalfd_siginfo) is a sequence number of a signal
in a queue.
This functionality is required for checkpointing
36 matches
Mail list logo
