Jiri Slaby <[EMAIL PROTECTED]> writes:
> If you, Sergei, can test it, it would be great. [Note, that this is actually
> a patch for mxser_new after renaming.]
Where is the reference git tree for this patch? Or, in other words,
which tree do I use if I want to test this patch (I'm afraid the
Jiri Slaby [EMAIL PROTECTED] writes:
If you, Sergei, can test it, it would be great. [Note, that this is actually
a patch for mxser_new after renaming.]
Where is the reference git tree for this patch? Or, in other words,
which tree do I use if I want to test this patch (I'm afraid the latest
"Satyam Sharma" <[EMAIL PROTECTED]> writes:
[...]
> And yet another patch falls victim to format=flowed ...
>
> I need some ideas here myself:
>
> I don't want to subscribe from my university mail account -- I like
> to keep important messages on server, and the account has a
> 100 MB or so limit
Satyam Sharma [EMAIL PROTECTED] writes:
[...]
And yet another patch falls victim to format=flowed ...
I need some ideas here myself:
I don't want to subscribe from my university mail account -- I like
to keep important messages on server, and the account has a
100 MB or so limit that
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 15 Feb 2007, Sergei Organov wrote:
>>
>> I agree that if the warning has no true positives, it sucks. The problem
>> is that somehow I doubt it has none. And the reasons for the doubt are:
>
> Why do you harp
Bodo Eggert <[EMAIL PROTECTED]> writes:
> On Fri, 16 Feb 2007, Sergei Organov wrote:
[...]
> I'll say it again: Either the code using unspecified chars is correct, or
> it isn't. If it's correct, neither using with signed nor with unsigned
> chars is a bug and you shou
Rene Herman <[EMAIL PROTECTED]> writes:
[...]
> Given char's special nature, shouldn't the conclusion of this thread
> have long been simply that gcc needs -Wno-char-pointer-sign? (with
> whatever default, as far as I'm concerned).
I entirely agree that all the char business in C is messy enough
Bodo Eggert <[EMAIL PROTECTED]> writes:
> On Fri, 16 Feb 2007, Sergei Organov wrote:
>> Bodo Eggert <[EMAIL PROTECTED]> writes:
>> > Sergei Organov <[EMAIL PROTECTED]> wrote:
>> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
[...
Bodo Eggert [EMAIL PROTECTED] writes:
On Fri, 16 Feb 2007, Sergei Organov wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
[...]
If we start talking about the C language, my opinion is that it's C
problem
Rene Herman [EMAIL PROTECTED] writes:
[...]
Given char's special nature, shouldn't the conclusion of this thread
have long been simply that gcc needs -Wno-char-pointer-sign? (with
whatever default, as far as I'm concerned).
I entirely agree that all the char business in C is messy enough to
Bodo Eggert [EMAIL PROTECTED] writes:
On Fri, 16 Feb 2007, Sergei Organov wrote:
[...]
I'll say it again: Either the code using unspecified chars is correct, or
it isn't. If it's correct, neither using with signed nor with unsigned
chars is a bug and you should not warn at all, and if it's
Linus Torvalds [EMAIL PROTECTED] writes:
On Thu, 15 Feb 2007, Sergei Organov wrote:
I agree that if the warning has no true positives, it sucks. The problem
is that somehow I doubt it has none. And the reasons for the doubt are:
Why do you harp on no true positives?
Because if somebody
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
>>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>>> something li
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> Using signed chars for strings is wrong in most countries on earth. It was
> wrong when the first IBM PC came out in 1981,
Bodo Eggert [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
[...]
Using signed chars for strings is wrong in most countries on earth. It was
wrong when the first IBM PC came out in 1981, and creating a compiler in
1987 defaulting
Bodo Eggert [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Exactly because char *by*definition* is indeterminate sign as far as
something like strlen() is concerned.
Thanks, I now understand that you either don't see
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
>> I agree that making strxxx() family special is not a good idea. So what
>> do we do for a random foo(char*) called with an 'unsigned char*'
>> argu
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 15 Feb 2007, Sergei Organov wrote:
[...Skip things I agree with...]
>> > But if you have
>> >
>> >unsigned char *mystring;
>> >
>> >len = strlen(mystring);
>> >
>>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
[...]
> BUT (and this is a big but) within the discussion of "strlen()", that is
> no longer true. "strlen()" exists _outside_ of a single particular
> implementa
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
>>
>> Sorry, what do you do with "variable 'xxx' might be used uninitialized"
>> warning when it's false? Turn it off? Annotate the source? Assign fake
>> i
Linus Torvalds [EMAIL PROTECTED] writes:
On Tue, 13 Feb 2007, Sergei Organov wrote:
Sorry, what do you do with variable 'xxx' might be used uninitialized
warning when it's false? Turn it off? Annotate the source? Assign fake
initialization value? Change the compiler so that it does
Linus Torvalds [EMAIL PROTECTED] writes:
On Tue, 13 Feb 2007, Sergei Organov wrote:
[...]
BUT (and this is a big but) within the discussion of strlen(), that is
no longer true. strlen() exists _outside_ of a single particular
implementation. As such, implementation-defined is no longer
Linus Torvalds [EMAIL PROTECTED] writes:
On Thu, 15 Feb 2007, Sergei Organov wrote:
[...Skip things I agree with...]
But if you have
unsigned char *mystring;
len = strlen(mystring);
then please tell me how to fix that warning without making the code
*worse* from a type
Olivier Galibert [EMAIL PROTECTED] writes:
On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
I agree that making strxxx() family special is not a good idea. So what
do we do for a random foo(char*) called with an 'unsigned char*'
argument? Silence? Hmmm... It's not immediately
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
[...]
>> May I suggest another definition for a warning being entirely sucks?
>> "The warning is entirely sucks if and only if it never has true
>> pos
Olivier Galibert [EMAIL PROTECTED] writes:
On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
[...]
May I suggest another definition for a warning being entirely sucks?
The warning is entirely sucks if and only if it never has true
positives. In all other cases it's only more
"Pekka Enberg" <[EMAIL PROTECTED]> writes:
> On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
>> With almost any warning out there one makes more or less efforts to
>> suppress the warning where it gives false positives, isn't it?
>
> Yes, as long
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
>> >
>> >"I want a char of indeterminate sign"!
>>
>> I'm afraid I don't follow. Do we have a way to say "I want an int of
>> indeterminate sign&
"Pekka Enberg" <[EMAIL PROTECTED]> writes:
> On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
>> May I suggest another definition for a warning being entirely sucks?
>> "The warning is entirely sucks if and only if it never has true
>> posit
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Sergei Organov wrote:
>>
>> Why strlen() should be allowed to be called with an incompatible pointer
>> type? My point is that gcc should issue *different warning*, -- the same
>> warning it issu
Linus Torvalds [EMAIL PROTECTED] writes:
On Mon, 12 Feb 2007, Sergei Organov wrote:
Why strlen() should be allowed to be called with an incompatible pointer
type? My point is that gcc should issue *different warning*, -- the same
warning it issues here:
I agree that strlen() per se isn't
Pekka Enberg [EMAIL PROTECTED] writes:
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote:
May I suggest another definition for a warning being entirely sucks?
The warning is entirely sucks if and only if it never has true
positives. In all other cases it's only more or less sucks, IMHO
Linus Torvalds [EMAIL PROTECTED] writes:
On Tue, 13 Feb 2007, Sergei Organov wrote:
I want a char of indeterminate sign!
I'm afraid I don't follow. Do we have a way to say I want an int of
indeterminate sign in C? The same way there doesn't seem to be a way
to say I want a char
Pekka Enberg [EMAIL PROTECTED] writes:
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote:
With almost any warning out there one makes more or less efforts to
suppress the warning where it gives false positives, isn't it?
Yes, as long it's the _compiler_ that's doing the effort.
You
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Sergei Organov wrote:
>>
>> As far as I can read the C99 standard, the "char", "signed char", and
>> "unsigned char", are all different types:
>
> Indeed. Search fo
Linus Torvalds [EMAIL PROTECTED] writes:
On Fri, 9 Feb 2007, Sergei Organov wrote:
As far as I can read the C99 standard, the char, signed char, and
unsigned char, are all different types:
Indeed. Search for pseudo-unsigned, and you'll see more. There are
actually cases where char can act
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Feb 8 2007 08:33, Linus Torvalds wrote:
>>
[...]
> What C needs is a distinction between char and int8_t, rendering "char"
> an unsigned at all times basically and making "unsigned char" and
> "signed char" illegal types in turn.
AFAIK, C already
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
>>
>> But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
>> implementation-defined, so if you call "strcmp()", you are already
>> basically saying: I don't care (and I _cannot_ care) what
Linus Torvalds [EMAIL PROTECTED] writes:
On Thu, 8 Feb 2007, Linus Torvalds wrote:
But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of char is
implementation-defined, so if you call strcmp(), you are already
basically saying: I don't care (and I _cannot_ care) what sign you are
Jan Engelhardt [EMAIL PROTECTED] writes:
On Feb 8 2007 08:33, Linus Torvalds wrote:
[...]
What C needs is a distinction between char and int8_t, rendering char
an unsigned at all times basically and making unsigned char and
signed char illegal types in turn.
AFAIK, C already has 3
Add PCMCIA IDs for Quatech DSP-100 dual RS232 adapter.
Signed-off-by: Sergei Organov <[EMAIL PROTECTED]>
---
diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index 431433f..5757442 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -249,6 +
Add PCMCIA IDs for Quatech DSP-100 dual RS232 adapter.
Signed-off-by: Sergei Organov [EMAIL PROTECTED]
---
diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index 431433f..5757442 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -249,6 +249,10
Alan <[EMAIL PROTECTED]> writes:
>> 3. Vendor driver is rather close to the generic one being in the kernel,
>>so maybe it's better to improve generic one instead of adding yet
>>another driver to the tree.
>
> Firstly can you post a patch which adds the relevant identifiers to the
>
Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> [...]
>> >> And there are plenty of documented devices that no one cares enough
>> >> about to submi
Greg KH [EMAIL PROTECTED] writes:
On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
Greg KH [EMAIL PROTECTED] writes:
[...]
And there are plenty of documented devices that no one cares enough
about to submit a driver for.
Any specific examples? I have a long list
Alan [EMAIL PROTECTED] writes:
3. Vendor driver is rather close to the generic one being in the kernel,
so maybe it's better to improve generic one instead of adding yet
another driver to the tree.
Firstly can you post a patch which adds the relevant identifiers to the
current pcmcia
Greg KH <[EMAIL PROTECTED]> writes:
[...]
>> And there are plenty of documented devices that no one cares enough
>> about to submit a driver for.
>
> Any specific examples? I have a long list of people who wish to write
> new drivers but just don't know which hardware is not yet supported.
Maybe
Greg KH [EMAIL PROTECTED] writes:
[...]
And there are plenty of documented devices that no one cares enough
about to submit a driver for.
Any specific examples? I have a long list of people who wish to write
new drivers but just don't know which hardware is not yet supported.
Maybe not
Jiri Slaby <[EMAIL PROTECTED]> writes:
> mxser_new, fix twice resource releasing
>
Hi Jiri,
I've noticed the patch(es) and will be happy to test them after the
holidays.
Thank you very much for working on these issues and Happy New Year!
-- Sergei.
-
To unsubscribe from this list: send the
Jiri Slaby [EMAIL PROTECTED] writes:
mxser_new, fix twice resource releasing
Hi Jiri,
I've noticed the patch(es) and will be happy to test them after the
holidays.
Thank you very much for working on these issues and Happy New Year!
-- Sergei.
-
To unsubscribe from this list: send the line
[] handle_IRQ_event+0x1a/0x3f
[] handle_edge_irq+0xde/0x109
[] do_IRQ+0x7d/0xa4
[] common_interrupt+0x1a/0x20
[] mwait_idle_with_hints+0x3b/0x3f
[] mwait_idle+0xc/0x1b
[] cpu_idle+0x9f/0xb9
[] start_kernel+0x39f/0x3a7
[] unknown_bootoption+0x0/0x206
===
handlers:
Disabling IRQ #
Jiri Slaby <[EMAIL PROTECTED]> writes:
[...]
>> # rmmod mxser_new
>> Trying to free already-free IRQ 58
>> Trying to free nonexistent resource <9000-903f>
>> Trying to free nonexistent resource <8800-8800>
>
> Thanks, I'll fix this and let you
Jiri Slaby [EMAIL PROTECTED] writes:
[...]
# rmmod mxser_new
Trying to free already-free IRQ 58
Trying to free nonexistent resource 9000-903f
Trying to free nonexistent resource 8800-8800
Thanks, I'll fix this and let you know. Does this
--
Sergei Organov.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby <[EMAIL PROTECTED]> writes:
>> Jiri Slaby <[EMAIL PROTECTED]> writes:
>>
>> > Could you test the patch below, if something changes?
>>
>> Just tested with low_latency commented out. Still oopses:
>>
>> BUG: unable to handle kernel NULL pointer dereference at virtual address
>>
Jiri Slaby [EMAIL PROTECTED] writes:
Jiri Slaby [EMAIL PROTECTED] writes:
Could you test the patch below, if something changes?
Just tested with low_latency commented out. Still oopses:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip:
Jiri Slaby <[EMAIL PROTECTED]> writes:
>> Jiri Slaby <[EMAIL PROTECTED]> writes:
>>
>> > Could you test the patch below, if something changes?
>>
>> Just tested with low_latency commented out. Still oopses:
>>
>> BUG: unable to handle kernel NULL pointer dereference at virtual address
>>
Jiri Slaby <[EMAIL PROTECTED]> writes:
>> Jiri Slaby <[EMAIL PROTECTED]> writes:
>>
>> > Could you test the patch below, if something changes?
>>
>> Just tested with low_latency commented out. Still oopses:
>>
>> BUG: unable to handle kernel NULL pointer dereference at virtual address
>>
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea
Jiri Slaby [EMAIL PROTECTED] writes:
Jiri Slaby [EMAIL PROTECTED] writes:
Could you test the patch below, if something changes?
Just tested with low_latency commented out. Still oopses:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip:
Jiri Slaby [EMAIL PROTECTED] writes:
Jiri Slaby [EMAIL PROTECTED] writes:
Could you test the patch below, if something changes?
Just tested with low_latency commented out. Still oopses:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip:
Jiri Slaby <[EMAIL PROTECTED]> writes:
> Sergei Organov wrote:
>> Jiri Slaby <[EMAIL PROTECTED]> writes:
>>
>>> [EMAIL PROTECTED] wrote:
>>>> Hi Jiri,
>>>>
>>>> I've figured out that both old and new mxser drivers have two
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any idea
Jiri Slaby [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
Jiri,
Jiri Slaby <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite
Jiri,
Jiri Slaby [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Jiri,
I've figured out that both old and new mxser drivers have two similar
problems:
1. When there are data coming to a port, sometimes opening of the port
entirely locks the box. This is quite reproducible. Any
Alan Cox <[EMAIL PROTECTED]> writes:
> At the moment tty buffers are attached directly to the tty. This is
> causing a lot of the problems related to tty layer locking, also
> problems at high speed and also with bursty data (such as occurs in
> virtualised environments)
>
> I'm working on
Alan Cox [EMAIL PROTECTED] writes:
At the moment tty buffers are attached directly to the tty. This is
causing a lot of the problems related to tty layer locking, also
problems at high speed and also with bursty data (such as occurs in
virtualised environments)
I'm working on ripping out
David Woodhouse <[EMAIL PROTECTED]> writes:
> On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
> > PS. Don't bother telling me about subversion. If you must, start reading
> > up on "monotone". That seems to be the most viable alternative, but don't
> > pester the developers so much that
77 matches
Mail list logo
