Re: [linuxsh-dev] Re: [linux-sh:01908] Re: 2.4.7 unaligned user space access problems

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Wed, Aug 01, 2001:

> 
> I found that it seems that you don't read the code which I sent, and
> you just asked me not to include it.  At least for me, it's not crap.
> Yes, we have disagreement here.  I haven't though that the
> disagreement is big enough.  I'm sorry.  I think that putting the code
> for the review or use is good thing.
> 

It doesn't matter how many times I read the code, it still sucks.  I read
it when Yaegashi originally posted the link, and it sucked.  I read it when
you sent it to me yesterday, and it still sucked.  Like I said, the
original NetBSD implementation left a lot to be desired as far as
cleanliness of the code.  As a matter of fact, it's mostly based off of the
original Sega BIOS GD-ROM driver, and please, don't get me started on that
one.

Now, you wanna base a Linux driver off a poorly-written NetBSD driver, and
call it quality?  If you seriously think this is a good piece of code, then
there's other issues that need to be addressed.

I'm more of the idea that Function follows Form.

> 
> You can critisize me, because I did wrong thing (not confirm your
> suggestion and do it on my dicision), but please don't insult the work
> others did.
> 

I don't want to dictate anything to anyone, that's not what this is about.
But c'mon, at least hear what I have to say.  I do have a bit of experience
on the Dreamcast side of things, I've been playing with code and
reverse-engineering since late last year.  There are blatant design
violations in Marcus', Bero's and your code in regards to the best way to
use the GDC.  And the fact the code is ugly as hell.  I guess I should've
made that more clear in my inital response, and maybe that would've
strengthed my position.

I'm not going to back down from my stance in regards to listening to
developers because this isn't the first time something like this has happened.
Regarding the situation where you didn't include DC drivers because of
contention at Sega, that did nothing but impede the overall progress of DC
support in the kernel.  One cool thing about Linux is, even if "Yoo hoo"
corporation tries to snuff it on their platform for whatever reason, there
are still others willing to port it anyway.  That's why LinuxDC was able to
add driver support, because I was fueled by the fact that Sega didn't want
it, and that was all the more reason to work on it anyway.

Now, while you were waiting for the Dreamcast to die, I was working on
drivers, and all of the sudden (much to my charign) in pops Yaegashi's DC
drivers - out of the blue.  Imagine how I feel after all those months
working on drivers with not a inch of support (by support I mean
encouragement, blessing, whatever) from you or Yaegashi and my work is
superceded.  It was the fact that you could have easily added that support
months ago, and we could've spent that time improving those drivers, rather
than reinventing the wheel.

Hey, you can say my opinion was irrelevant back then, but the problem was I
wasn't the only one asking for that release.  Sega didn't want it, so you
didn't do it.  (If anyone thinks I'm talking out of my ass here, John Byrd
of Sega specifically said Sega didn't want Linux, because of the GPL, and
that he favored BSD, because of the BSD license - and that's just coming
from Sega of America, I don't know SOJ's position).

> 
> It would be good idea.  Actually, I did follow such a style last year,
> but I thought that it did not functional (most of the time, I wrote, I
> reviewed, I decided).  It made me bit lazy.   Will do.
> 

Tossing the flames aside, I've been working on an RFC over the last few
days that brings some of these issues to light, for everyone to comment on.
I'm trying to get it to the list by this afternoon.

> 
> I didn't see such a change by anyone else.  If there's such a
> breakage, it's almost always my fault most of the time.  When I import
> the changes from mainline (that's my task), sometimes it introduced
> breaks, and ad hoc hack by me is even too bad, I admit it.
> 

Ok, I'll back off on this in the RFC, since it's already been said and
done.

> 
> ??? Do you mean, the feedback from users?  I'm same situation on you.
> I don't remember the feedback from the users of this list these days.
> I didn't get the feedback of 1120 version.  In May 2000 or earlier I
> got the feedback and discussed about the approach.  It seems people
> doesn't ahve enough interest...
>

Heh, well the way around this is to do another survey, explicitly asking
for thoughts and ideas around this.  Then if people don't respond, you have
all the reason/right to do what you will with the patches.

> Or do you mean the patches for GCC?  We're working for 3.0 and
> mainline (3.1) too, and the both patches (you may say it's ad hoc) are
> available on the Web as usual (by Kazmoto Kojima).
> 

What I meant by ad hoc was, I've looked (i.e. read) at the patches, and
some of the fixes, etc. step over certain parts of gcc that it probably
shouldn't.  Also, ad hoc means that I can't build a sh4-linux compiler with
out them, and that makes it more difficult for newbies to start kernel
development, and makes it tougher to do package maintenence for the
toolchain.

> We continue the effort to mainline for GCC, GNU C library, GNU
> Binutils, GNU Libtool, and config.sub/config.guess of GNU.  When I
> think that the patch is good enough, I sent it to mainline and discuss
> it.  It is same thing for Linux kernel mainline merge.

Ok, I'll touch briefly on this in the RFC.

Like I said, it's a RFC so that everyone in the LinuxSH community can
speak, and right now I'm going to stop flaming and finish it up.

Marcus