[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
Greg> Yes, that doesn't matter. But it seems that the svn tree is Greg> vastly different from the in-kernel code. So much so that Greg> some companies feel that the in-kernel stuff just isn't Greg> worth running at all. I don't want to belabor this issue... but the svn tree is not vastly different than what's in the kernel. It has some things that aren't upstream yet, and which are important to some people. For example, the IBM ehca driver we're talking about, as well as the PathScale driver, SDP (sockets direct protocol), etc. It just takes time for this new code to get to the point where both the developers of the new stuff feel it's ready to be merged, and the kernel community agrees that it should be merged. Greg> Yes, that does make me happy. But it doesn't make me happy Greg> to see IBM not being able to participate in kernel Greg> development by posting and defending their own code to lkml. Greg> I thought IBM knew better than that... Agreed. But let's not get sidetracked on that internal IBM issue. The ehca developers have assured me that they can and will participate in the thread reviewing their driver. It seems like it's better for me to help them work around their internal problems by acting as a proxy, than for me to delay merging their driver just because someone in IBM management is clueless. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 01:31:52PM -0800, Roland Dreier wrote: > Greg> Sorry, I didn't mean to say "private", but rather, > Greg> "seperate". Doing kernel development in a seperate > Greg> development tree from the mainline kernel is very > Greg> problematic, as has been documented many times in the past. > > As a general rule I agree with that. However, the openib svn tree > we're talking about is not some project that is off in space never > merging with the kernel; as Christoph said, it's really just a staging > area for stuff that isn't ready for upstream yet.n > > Perhaps it would be more politically correct to use git to develop > kernel code, but in the end that's really just a technical difference > that shouldn't matter. Yes, that doesn't matter. But it seems that the svn tree is vastly different from the in-kernel code. So much so that some companies feel that the in-kernel stuff just isn't worth running at all. > Roland> Distro politics are just distro politics -- and there will > Roland> always be pressure on distros to ship stuff that's not > Roland> upstream yet. > > Greg> Luckily the distros know better than to accept this anymore, > Greg> as they have been burned too many times in the past... > > OK, that's great. But now I don't understand your original point. > You say there are people putting pressure on distros to ship what's in > openib svn rather than the upstream kernel, but if the distros are > going to ignore them, what does it matter? It takes a _lot_ of effort to ignore them, as it's very difficult to do so. Especially when companies try to play the different distros off of each other, but that's not an issue that the mainline kernel developers need to worry about :) > And this thread started with me trying to help the IBM people make > progress towards merging a big chunk of that svn tree upstream. That > should make you happy, right? Yes, that does make me happy. But it doesn't make me happy to see IBM not being able to participate in kernel development by posting and defending their own code to lkml. I thought IBM knew better than that... thanks, greg k-h ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
Greg> Sorry, I didn't mean to say "private", but rather, Greg> "seperate". Doing kernel development in a seperate Greg> development tree from the mainline kernel is very Greg> problematic, as has been documented many times in the past. As a general rule I agree with that. However, the openib svn tree we're talking about is not some project that is off in space never merging with the kernel; as Christoph said, it's really just a staging area for stuff that isn't ready for upstream yet.n Perhaps it would be more politically correct to use git to develop kernel code, but in the end that's really just a technical difference that shouldn't matter. Roland> Distro politics are just distro politics -- and there will Roland> always be pressure on distros to ship stuff that's not Roland> upstream yet. Greg> Luckily the distros know better than to accept this anymore, Greg> as they have been burned too many times in the past... OK, that's great. But now I don't understand your original point. You say there are people putting pressure on distros to ship what's in openib svn rather than the upstream kernel, but if the distros are going to ignore them, what does it matter? And this thread started with me trying to help the IBM people make progress towards merging a big chunk of that svn tree upstream. That should make you happy, right? - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 10:52:58AM -0800, Roland Dreier wrote: > Greg> Checking stuff into a private svn tree is vastly different > Greg> from posting to lkml in public. In fact, it looks like the > Greg> svn tree is so far ahead of the in-kernel stuff, that most > Greg> people are just using it instead of the in-kernel code. > > It's not a private svn tree -- the IBM ehca development is available > to anyone via svn at > https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/hw/ehca Sorry, I didn't mean to say "private", but rather, "seperate". Doing kernel development in a seperate development tree from the mainline kernel is very problematic, as has been documented many times in the past. > Distro politics are just distro politics -- and there will always be > pressure on distros to ship stuff that's not upstream yet. Luckily the distros know better than to accept this anymore, as they have been burned too many times in the past... thanks, greg k-h ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
Greg> Checking stuff into a private svn tree is vastly different Greg> from posting to lkml in public. In fact, it looks like the Greg> svn tree is so far ahead of the in-kernel stuff, that most Greg> people are just using it instead of the in-kernel code. It's not a private svn tree -- the IBM ehca development is available to anyone via svn at https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/hw/ehca Greg> I know at least one company has asked a distro to just Greg> accept the svn snapshot over the in-kernel IB code, which Greg> makes me wonder if the in-kernel stuff is even useful to Greg> people? Why have it, if companies insist on using the Greg> out-of-tree stuff instead? The IB driver stack is still in its early stages, so although I'm pushing for things to be merged as fast as possible, the unfortunate fact is that lots of things that people want to use (including the IBM ehca driver) are not upstream and are not ready to go upstream yet. But that doesn't mean we should give up on merging them. Distro politics are just distro politics -- and there will always be pressure on distros to ship stuff that's not upstream yet. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 10:15:09AM -0800, Greg KH wrote: > On Sat, Feb 18, 2006 at 08:32:28AM -0800, Roland Dreier wrote: > > Arjan> The bigger issue is: if people can't be bothered to do > > Arjan> those steps, why would they be bothered to do this for > > Arjan> maintenance and bugfixes etc etc? Basically it's now > > Arjan> already a de-facto unmaintained driver > > > > I don't think that's really a fair statement. The IBM people have > > been active and responsive in maintaining their driving in the > > openib.org svn tree. However, they asked me to post their driver for > > review because it would be difficult for them to do it. > > Checking stuff into a private svn tree is vastly different from posting > to lkml in public. In fact, it looks like the svn tree is so far ahead > of the in-kernel stuff, that most people are just using it instead of > the in-kernel code. > > I know at least one company has asked a distro to just accept the svn > snapshot over the in-kernel IB code, which makes me wonder if the > in-kernel stuff is even useful to people? Why have it, if companies > insist on using the out-of-tree stuff instead? The openib tree isn't private. It's mostly just a staging area for development. Any company that wants it included into a distro release is completely clueless. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 08:32:28AM -0800, Roland Dreier wrote: > Arjan> The bigger issue is: if people can't be bothered to do > Arjan> those steps, why would they be bothered to do this for > Arjan> maintenance and bugfixes etc etc? Basically it's now > Arjan> already a de-facto unmaintained driver > > I don't think that's really a fair statement. The IBM people have > been active and responsive in maintaining their driving in the > openib.org svn tree. However, they asked me to post their driver for > review because it would be difficult for them to do it. Checking stuff into a private svn tree is vastly different from posting to lkml in public. In fact, it looks like the svn tree is so far ahead of the in-kernel stuff, that most people are just using it instead of the in-kernel code. I know at least one company has asked a distro to just accept the svn snapshot over the in-kernel IB code, which makes me wonder if the in-kernel stuff is even useful to people? Why have it, if companies insist on using the out-of-tree stuff instead? thanks, greg k-h ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, 2006-02-18 at 08:32 -0800, Roland Dreier wrote: > Arjan> The bigger issue is: if people can't be bothered to do > Arjan> those steps, why would they be bothered to do this for > Arjan> maintenance and bugfixes etc etc? Basically it's now > Arjan> already a de-facto unmaintained driver > > I don't think that's really a fair statement. It's a concern at least; if they're just having trouble posting really big files that's one thing.. if they're not allowed to post at all that's another. > IBM people: can you clarify the restrictions you have? Why do you > feel you can't post your own driver for review? Will you be able to > post smaller patches to lkml in the future if the driver is merged? And can you respond to questions and user questions on lkml? ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
Arjan> The bigger issue is: if people can't be bothered to do Arjan> those steps, why would they be bothered to do this for Arjan> maintenance and bugfixes etc etc? Basically it's now Arjan> already a de-facto unmaintained driver I don't think that's really a fair statement. The IBM people have been active and responsive in maintaining their driving in the openib.org svn tree. However, they asked me to post their driver for review because it would be difficult for them to do it. IBM people: can you clarify the restrictions you have? Why do you feel you can't post your own driver for review? Will you be able to post smaller patches to lkml in the future if the driver is merged? Thanks, Roland ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, 2006-02-18 at 14:26 +0200, Muli Ben-Yehuda wrote: > On Sat, Feb 18, 2006 at 12:20:11PM +, Christoph Hellwig wrote: > > > > Well, the eHCA guys tell me that they can't post patches to lkml. > > > > Then they lie. And not posting to lkml is a good reason not to merge > > an otherwise perfect driver. (which this one is far from) > > I don't speak for IBM or the authors, but there are perfectly > reasonable reasons to ask someone else to post a patch on your behalf > - including but not limited to to only being able to use Lotus Notes > with one's IBM email. I'm sure you've all seen the travesties that > Notes inflicts on inline patches. there are ways around that with webmail etc. The bigger issue is: if people can't be bothered to do those steps, why would they be bothered to do this for maintenance and bugfixes etc etc? Basically it's now already a de-facto unmaintained driver ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 02:26:31PM +0200, Muli Ben-Yehuda wrote: > I don't speak for IBM or the authors, but there are perfectly > reasonable reasons to ask someone else to post a patch on your behalf > - including but not limited to to only being able to use Lotus Notes > with one's IBM email. I'm sure you've all seen the travesties that > Notes inflicts on inline patches. sure. and there's free webmail accounts that take about 10 minutes to setup as well as various people offering shell access to linux machines if you ask nicely. so this really is not an issue. I think this is more about ibm politics (espeically in boeblingen) sometimes making it pretty hard to post things. But that doesn't mean it's impossible, it just means they didn't try hard enough. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Sat, Feb 18, 2006 at 12:20:11PM +, Christoph Hellwig wrote: > > Well, the eHCA guys tell me that they can't post patches to lkml. > > Then they lie. And not posting to lkml is a good reason not to merge > an otherwise perfect driver. (which this one is far from) I don't speak for IBM or the authors, but there are perfectly reasonable reasons to ask someone else to post a patch on your behalf - including but not limited to to only being able to use Lotus Notes with one's IBM email. I'm sure you've all seen the travesties that Notes inflicts on inline patches. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Fri, Feb 17, 2006 at 06:04:56PM -0800, Roland Dreier wrote: > Greg> Roland, your comments are fine, but what about the original > Greg> author's descriptions of what each patch are? > > This is actually me breaking up a giant driver into pieces small > enough to post to lkml without hitting the 100 KB limit. > > This is just an RFC -- I assume the driver is going to get merged in > the end as one big git changeset with a changelog like "add driver for > IBM eHCA InfiniBand adapters". > > Greg> Come on, IBM allows developers to post code to lkml, just > Greg> look at the archives for proof. For them to use a proxy > Greg> like this is very strange, and also, there is no > Greg> Signed-off-by: record from the original authors, which is > Greg> not ok. > > Well, the eHCA guys tell me that they can't post patches to lkml. Then they lie. And not posting to lkml is a good reason not to merge an otherwise perfect driver. (which this one is far from) ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Fri, Feb 17, 2006 at 04:57:07PM -0800, Roland Dreier wrote: > From: Roland Dreier <[EMAIL PROTECTED]> > > This is a very large file with way too much code for a .h file. > The functions look too big to be inlined also. Is there any way > for this code to move to a .c file? > --- > > drivers/infiniband/hw/ehca/hcp_if.h | 2022 > +++ > +#include "ehca_tools.h" > +#include "hipz_structs.h" > +#include "ehca_classes.h" > + > +#ifndef EHCA_USE_HCALL > +#include "hcz_queue.h" > +#include "hcz_mrmw.h" > +#include "hcz_emmio.h" > +#include "sim_prom.h" > +#endif > +#include "hipz_fns.h" > +#include "hcp_sense.h" > +#include "ehca_irq.h" > + > +#ifndef CONFIG_PPC64 > +#ifndef Z_SERIES > +#warning "included with wrong target, this is a p file" > +#endif > +#endif > + > +#ifdef EHCA_USE_HCALL > + > +#ifndef EHCA_USERDRIVER > +#include "hcp_phyp.h" > +#else > +#include "testbench/hcallbridge.h" > +#endif > +#endif the ifdefs should all go away and the build system should make sure it's only built for the right platforms. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
> Come on, IBM allows developers to post code to lkml, just look at the > archives for proof. For them to use a proxy like this is very strange, Things aren't always that easy at IBM. You should know best :) Heiko ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
Greg> Roland, your comments are fine, but what about the original Greg> author's descriptions of what each patch are? This is actually me breaking up a giant driver into pieces small enough to post to lkml without hitting the 100 KB limit. This is just an RFC -- I assume the driver is going to get merged in the end as one big git changeset with a changelog like "add driver for IBM eHCA InfiniBand adapters". Greg> Come on, IBM allows developers to post code to lkml, just Greg> look at the archives for proof. For them to use a proxy Greg> like this is very strange, and also, there is no Greg> Signed-off-by: record from the original authors, which is Greg> not ok. Well, the eHCA guys tell me that they can't post patches to lkml. You're right that the final merge will have to have an IBM Signed-off-by: line but as I said this is just an RFC. There are many reasons beyond patch format issues that make this stuff unmergeable as-is. Greg> And why aren't you using the standard firmware interface in Greg> the kernel? This is actually stuff to talk to the firmware that sits below the kernel on IBM ppc64 machines, not an interface to load device firmware from userspace. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH 02/22] Firmware interface code for IB device.
On Fri, Feb 17, 2006 at 04:57:07PM -0800, Roland Dreier wrote: > From: Roland Dreier <[EMAIL PROTECTED]> > > This is a very large file with way too much code for a .h file. > The functions look too big to be inlined also. Is there any way > for this code to move to a .c file? Roland, your comments are fine, but what about the original author's descriptions of what each patch are? Come on, IBM allows developers to post code to lkml, just look at the archives for proof. For them to use a proxy like this is very strange, and also, there is no Signed-off-by: record from the original authors, which is not ok. And why aren't you using the standard firmware interface in the kernel? > +#ifndef CONFIG_PPC64 > +#ifndef Z_SERIES > +#warning "included with wrong target, this is a p file" > +#endif > +#endif It's a "p" file? What's that? Is this even needed? thanks, greg k-h ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
