On Fri, Nov 02, 2012 at 11:37:10PM +0100, "Jan H. Schönherr" wrote:
> Am 02.11.2012 04:53, schrieb Kay Sievers:
> > On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
> >> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
> >
> Jan,
> any updates, did you try something else?
> Or
Am 02.11.2012 04:53, schrieb Kay Sievers:
> On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
>> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
>
Jan,
any updates, did you try something else?
Or should we merge the first version for now?
>>>
>>> I'm working on it, though I can
On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
>>> Jan,
>>> any updates, did you try something else?
>>> Or should we merge the first version for now?
>>
>> I'm working on it, though I cannot spend as much time as I want. :)
>>
>> My curren
On Mon, 2012-10-08 at 21:54 +0200, "Jan H. Schönherr" wrote:
> Am 08.10.2012 21:24, schrieb Kay Sievers:
> > On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
> >> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
> >>> Given that I'm able to fix the racing case, would you be in favor of
> >>>
On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
wrote:
> Am 08.10.2012 21:24, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
>>> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>>
Given that I'm able to fix the racing case, would you be in favor of
th
Am 08.10.2012 21:24, schrieb Kay Sievers:
> On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
>> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>
>>> Given that I'm able to fix the racing case, would you be in favor of
>>> this approach, or should we stick to the earlier version?
>>
>> I'm
On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>> Given that I'm able to fix the racing case, would you be in favor of
>> this approach, or should we stick to the earlier version?
>
> I'm open to everything that makes sense. Let's see how
On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
wrote:
> Am 28.09.2012 16:34, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
>> The current behaviour has the advantage, that non-cont users will not
>> race against a cont user (which is like 99.x% of the races I exp
Am 28.09.2012 16:34, schrieb Kay Sievers:
> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
> That fails the racing task test, and a cont user that was nicely
> merged before is now all in separate records.
I guess, I need to extend my test cases. Do you have something
ready that I could use?
On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
wrote:
>> If really, really everything passes through vprintk_emit()
>> then we could keep all info about the previous message
>> there and definitely decide whether the current message continues
>> the previous one.
>>
>> Then, we wouldn't need
Am 27.09.2012 18:04, schrieb Jan H. Schönherr:
> Am 27.09.2012 17:46, schrieb Jan H. Schönherr:
>> If we say "if LOG_CONT is set, this message continues the previous one",
>> we can also say "there is no prefix on this message". Then on the other
>> hand, we would need a "whatever comes next, it do
On Thu, Sep 27, 2012 at 5:46 PM, "Jan H. Schönherr"
wrote:
> Am 27.09.2012 15:39, schrieb Kay Sievers:
>> It is a flag that we have not been able to merge a continuation line
>> in the buffer, because we had a race with another thread, or the
>> console lock was taken for a long time and we could
Am 27.09.2012 17:46, schrieb "Jan H. Schönherr":
> If we say "if LOG_CONT is set, this message continues the previous one",
> we can also say "there is no prefix on this message". Then on the other
> hand, we would need a "whatever comes next, it does not continue this
> message"
Thinking a bi
Am 27.09.2012 15:39, schrieb Kay Sievers:
> On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
> wrote:
>> "Tested" as in: it fixes my use case: multiple printk()s shortly after each
>> other -- with KERN_prefix but without a newline at the end. Those were
>> sometimes concatenated since that pr
On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
wrote:
> Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
>> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>>> Against v3.6-rc7, only lightly tested.
>>
>> Well, against linux-next and highly tested would be best. It's a bit
Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>> Against v3.6-rc7, only lightly tested.
>
> Well, against linux-next and highly tested would be best. It's a bit
> late to get this into linux-next for 3.7, how important is it r
On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
> From: Jan H. Schönherr
>
> The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
> ending, or middle fragment. Unfortunately, this cannot be inferred from
> the LOG_PREFIX and LOG_NEWLINE flags, as they are
17 matches
Mail list logo
