Re: Request for linux-next inclusion of the voyager tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, 10 Jun 2009, Thomas Gleixner wrote:
> > 
> > > Alan is definitely right that we're likely to see more of the "non-PC" 
> > > platforms as x86 tries to do embedded.
> > 
> > I agree, but the way voyager is done is _not_ a good example for the
> > embedded x86 folks who will probably start to send in their scoop in
> > the foreseable future.
> > 
> > I'm not fundamentally against bringing Voyager back, but it 
> > needs to go through a useful patch submission and review process 
> > and not by forcing voyager wreckage into our code base.
> 
> Ok, thanks. This was exactly the kind of thing I wanted to hear. 
> It does sound like the Voyager tree is doing things I myself 
> wouldn't approve of as a maintainer, so I can't really say that 
> I'm upset by the x86 maintainers then not pulling it.

I also take back the "it's obsolete" and "it didnt even build" 
portion of my NAK - that was overboard as Alan and you pointed it 
out.

I think we can work out something and a clear(er) platform driver 
interface abstraction with a thin cross section to generic x86 code 
will be helpful to a lot more than just Voyager.

In fact we have implemented that largely and it went upstream in 
2.6.30, via the massive changes around this bit:

  6bda2c8: x86: remove subarchitecture support

This is what _already_ happened to other (ex-)subarchitecture code: 
visws, numaq were frequent trouble spots too, and with the 
x86-quirks model they basically vanished from our regression lists.

So it's a successful model in practice, and if Voyager is done in a 
similar way we wont see many Voyager problems in the future either.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux