2003-01-12 01:36:24

by Joe

[permalink] [raw]
Subject: [OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

Rob Wilkens wrote:

>I'd say terribly presumptuous, but I don't think it is presumptuous to
>say that if there are many patches (bug fixes, mostly) coming in that
>the code that was originally there was of questionable quality.
>

Your statements are at once so arrogant, yet
so ignorant, it's hard to know where to even
begin - but you are quite mistaken on several
fronts; each new message from you reveals an
unbridgeable gulf, of which you do not even
seem aware.

I won't even begin to put together a point by
point correction, it's all too tedious, and it's
possible that you are here just to annoy and
wear down the developers anyway -

Please start sending in patches or discussing
kernel code, or even doing testing - if not, you
might wish to seek out a different forum for
your messages, where you might find a more
receptive audience - I'll refrain from making
specific suggestions at this time.

Best Regards,

Joe



2003-01-12 03:11:17

by Rob Wilkens

[permalink] [raw]
Subject: Re: [OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

On Sat, 2003-01-11 at 20:44, J Sloan wrote:
> I won't even begin to put together a point by
> point correction, it's all too tedious, and it's
> possible that you are here just to annoy and
> wear down the developers anyway -

I've only written a total of maybe 5-6 messages to the list, and maybe 4
of them were off topic because of a previous off-topic message by
somebody else (such as yours). I don't see how "i" am specifically
designed to wear down developers, though I'll apologize for any comments
I made earlier about the simplicity of kernel development: I should
comment that it was kernel development I was doing (professionally) when
I had my first two mental breakdowns, so it should be no surprise to
discover that despite the fact that superficially it seemed like easy
work at the time, it can be a stress inducing kind of work which is
somewhat tedious in nature (trying to get various hardware to work just
right, or reversing bit/byte orders for various platforms or that sort
of thing).

> Please start sending in patches or discussing
> kernel code, or even doing testing - if not, you
> might wish to seek out a different forum for
> your messages, where you might find a more
> receptive audience - I'll refrain from making
> specific suggestions at this time.

I fixed a bug in my kernel (2.4.20), and here's the unified diff with
the hack I put in place, it's not a fix because I don't know enough
about the floppy driver to fix it the right way--- it's called a hack.
I'm sure if I looked at the problem longer I could fix it right, but it
looks like in 2.5.56 the floppy driver has been rewritten somewhat, but
the problem, I believe, is still there and reproducable (code to
reproduce it is below).

<---Begin--->

--- floppy.c.orig 2003-01-07 21:51:49.000000000 -0500
+++ floppy.c 2003-01-10 15:54:56.000000000 -0500
@@ -3874,7 +3874,7 @@
UCLEARF(FD_DISK_CHANGED);
if (cf)
UDRS->generation++;
- if (NO_GEOM){
+ if (/*NO_GEOM*/1){
/* auto-sensing */
int size = floppy_blocksizes[MINOR(dev)];
if (!size)


<---End--->

Please note that the above error fixes the following test case. IF you
have no floppy in the A: drive and run the following test.c code
repeatedly you will find you get different results every time you run
it. I left the commented sections in the code to illustrate that it
only happens with fd0u1440 as opposed to fd0.

<---Begin--->
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>

#define O_LARGEFILE 0100000

main()
{
int fd,bits;

/* fd=open("/dev/fd0",O_WRONLY|O_CREAT|O_TRUNC);*/

/*fd=open("/dev/fd0",O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE);*/
fd=open("/dev/fd0u1440",O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE);

printf ("fd=%d\n",fd);
perror("error was: ");
}
<---End--->

Note that O_LARGEFILE isn't meaningful, it was put there because I was
imitating a system call that I saw the "dd" command making when doing an
"strace" (System Call Trace) do when it was failing.

This is a silly and trivial bug, but someone reported it. Until I get
some acknowledgement of any kind on my first kernel patch submittal, it
seems silly to submit more, even if the acknowledgement is someone
telling me "try to fix it the right way so it doesn't break anything
else" which may involve adding a few more lines of code.

-Rob

2003-01-12 04:00:29

by Scott Murray

[permalink] [raw]
Subject: Re: [OT] Noise on lkml (was Re: Nvidia and its choice to read the GPL "differently")

On Sat, 11 Jan 2003, Rob Wilkens wrote:

> On Sat, 2003-01-11 at 20:44, J Sloan wrote:
> > I won't even begin to put together a point by
> > point correction, it's all too tedious, and it's
> > possible that you are here just to annoy and
> > wear down the developers anyway -
>
> I've only written a total of maybe 5-6 messages to the list, and maybe 4
> of them were off topic because of a previous off-topic message by
> somebody else (such as yours).
[snip]

FYI, looking in my l-k folder, with the next message you sent, you have
posted 22 messages in the last 3 days, only 3 of which had subject lines
not related to the ongoing flamewar.

Scott


--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]