linux-kernel - Re: [ck] Re: Linus 2.6.23-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0707300008230.30928@enigma.security.iitk.ac.in>
Date:	Mon, 30 Jul 2007 00:24:35 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Martin Steigerwald <Martin@...htvoll.de>
cc:	ck@....kolivas.org, Sam Ravnborg <sam@...nborg.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	linux-kernel@...r.kernel.org, lkml@...anurb.dk
Subject: Re: [ck] Re: Linus 2.6.23-rc1

Hi Martin,


On Sun, 29 Jul 2007, Martin Steigerwald wrote:

> Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > > > I
> > > > > actually also think that the communication between Ingo and Con
> > > > > could have been better especially when Ingo decided to write CFS
> > > > > while Con was still working hard on SD.
> > > >
> > > > You realize that Ingo posted his code for anyone to look at/comment
> > > > at about 48 hours after he started to work on CFS?
> > >
> > > Yes.
> >
> > So whats wrong then?
> > Ingo decides to do a better scheduler - to some extent inspired by
> > Con's work. And after 48 hours he publish first version that _anyone_
> > can see and comment on. Whats wrong with that?
> >
> > Did you expect some lengthy discussion before the coding phase started
> > or what?
> >
> > Just trying to understand what you are arguing about.
> 
> If I tried to rewrite a kernel subsystem - should I ever happen to dig 
> that deep into kernel matters - while I actually know that someone 
> already spent countless hours on exactly rewriting the exact same 
> subsystem, I think I would have told that other developer about it as 
> soon as I started coding on it. And if it just was a
> 
> "Hi Con,
> 
> I reconsidered the scheduling ideas again you brought to the Linux kernel 
> world. Instead of using your scheduler tough I like to try to write a new 
> one with fairness in mind, cause I think this, this and this can be 
> improved upon.
> 
> I would like to hear your ideas about that as soon as possible and would 
> like you to contribute your ideas and also code, where you see hit. You 
> can find the git / bazaar / whatever repository where I do my 
> developments at: someurl.
> 
> Regards, Ingo"

Sending out the code (and early enough, 48 hours /is/ early enough) *is*
the normal (and good) way to do exactly the communication you described
above, IMHO.

> I believe that Ingo did not meant any bad at all. I think its just the way 
> he works, he likes to have code before saying anything. But still I 
> believe before I'd go about replacing someone else code completely I 
> would inform that developer beforehand, even if it then turns out not to 
> be feasible at all. No need to anounce it to the world already, but I 
> would have informed that developer.

IMHO, what you're suggesting is: (1) not the way development normally
happens in Linux, and, (2) not the way it /should/ happen, either. If
there's something (subsystem, any code big or small) I think I can do
better or have an idea for, I /should/ be able to just hack on it a bit
and then send it out so everybody can comment on it. Why should I be
forced to dance/discuss around with some other people, when the faster
and more effective way would be just present the code/patch that I
have in my mind as an RFC?

See, Martin, in the end it's not about developer A vs developer B. It's
about making the kernel the best out there -- that's what the users want,
anyway. Yes, I fully understand (and have said so earlier myself) that
there's a very important "social" aspect to development on such projects,
but it's best if developer B understands that this is the way things do
(and should) happen and adapt to it. [ It's not like I've been around for
long, however, but the above is still my opinion, fwiw. ]

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/