linux-staging/linux-next merge/build errors

linux-staging/linux-next merge/build errors

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Hi Greg,

Today I have done a test merge of linux-staging into linux-next.  I got
merge conflicts in drivers/char/agp/via-agp.c and drivers/misc/Makefile -
neither of which is really surprising and both tivial to fix up.

I then did an x86 allmodconfig build with these errors:

In file included from /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_drm.c:32:
/home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h: In function ‘IS_AGPHEADER_INV’:
/home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: ‘TRUE’ undeclared (first use in this function)
/home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: (Each undeclared identifier is reported only once
/home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: for each function it appears in.)
/home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:232: error: ‘FALSE’ undeclared (first use in this function)

And several new warnings (these may not be all):

/home/sfr/kernels/next/src/fs/novfs/inode.c:265: warning: initialization from incompatible pointer type
/home/sfr/kernels/next/src/fs/novfs/inode.c:267: warning: initialization from incompatible pointer type
/home/sfr/kernels/next/src/fs/novfs/inode.c:273: warning: initialization from incompatible pointer type
/home/sfr/kernels/next/src/fs/novfs/inode.c:275: warning: initialization from incompatible pointer type
In file included from /home/sfr/kernels/next/src/fs/novfs/daemon.c:24:
include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h
In file included from /home/sfr/kernels/next/src/fs/novfs/scope.c:26:
include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h
In file included from /home/sfr/kernels/next/src/fs/novfs/nwcapi.c:22:
include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-staging/linux-next merge/build errors

[Greg KH]

On Sat, Jun 21, 2008 at 12:40:17PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today I have done a test merge of linux-staging into linux-next.  I got
> merge conflicts in drivers/char/agp/via-agp.c and drivers/misc/Makefile -
> neither of which is really surprising and both tivial to fix up.
> 
> I then did an x86 allmodconfig build with these errors:
> 
> In file included from /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_drm.c:32:
> /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h: In function ‘IS_AGPHEADER_INV’:
> /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: ‘TRUE’ undeclared (first use in this function)
> /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: (Each undeclared identifier is reported only once
> /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:230: error: for each function it appears in.)
> /home/sfr/kernels/next/src/drivers/char/drm/via_chrome9_3d_reg.h:232: error: ‘FALSE’ undeclared (first use in this function)

Wierd, this passes allmodconfig on i386, something else must be
declaring TRUE and FALSE :)

I'll just go remove them entirely.

> And several new warnings (these may not be all):
> 
> /home/sfr/kernels/next/src/fs/novfs/inode.c:265: warning: initialization from incompatible pointer type
> /home/sfr/kernels/next/src/fs/novfs/inode.c:267: warning: initialization from incompatible pointer type
> /home/sfr/kernels/next/src/fs/novfs/inode.c:273: warning: initialization from incompatible pointer type
> /home/sfr/kernels/next/src/fs/novfs/inode.c:275: warning: initialization from incompatible pointer type
> In file included from /home/sfr/kernels/next/src/fs/novfs/daemon.c:24:
> include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h
> In file included from /home/sfr/kernels/next/src/fs/novfs/scope.c:26:
> include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h
> In file included from /home/sfr/kernels/next/src/fs/novfs/nwcapi.c:22:
> include2/asm/semaphore.h:1:2: warning: #warning Use linux/semaphore.h, not asm/semaphore.h

Yeah, we took a major update of novfs and some of my previous fixes like
this got lost.

I'll go resolve them now.

thanks,

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

How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Greg KH]

On Sat, Jun 21, 2008 at 12:40:17PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today I have done a test merge of linux-staging into linux-next.

Thanks for doing this.

I've been thinking this past week about how to properly handle the
linux-staging tree.

For some background, it came about because Ingo pointed out that it
seems hard to get new drivers merged into the main tree quickly, and
that perhaps we should have a drivers/staging/ directory in Linus's tree
where we can dump things in quickly and then clean them up later.

That got quickly vetoed by a number of other maintainers, and I brought
up the point of me just doing a separate -staging tree that would be
something like this, but not go into Linus's tree directly.

I originally sprung the idea on you of having you merge it into -next to
get testing and build coverage, but I've been thinking a lot more about
this, and I don't want to burden you with this, you have enough work to
do with trying to get the normal -next tree out :)

So, if you don't mind, and no one else objects, here's how I would like
to run the -staging tree:

  - It's a set of patches, in quilt form, that can be applied on top of
    a released kernel from Linus.
  - It will be rebased at the least with every -rc and -final release,
    and probably a lot more frequently with a few -git releases
    inbetween.
  - I will do a "roll-up" patch release for ever -final release and -rc
    release to make it easy for users to grab it and apply it to a
    release so that they can use the drivers/filesystems contained in
    it.
  - Once the patches in the -staging tree are nearing "cleaned up" stage
    (i.e. their TODO list is finished off), I will submit them to the
    proper subsystem maintainer for inclusion into their tree, on the
    way to Linus's tree eventually.

This process should allow for a much easier barrier to development and
using the drivers by everyone, instead of having to rebase on top of
-next, which can be hairy at times.  It also allows distros and anyone
else to grab the full patchset in a much easier manner for their users,
if they so desire.

Does that sound reasonable to everyone?

I'll go do a release for 2.6.26-rc7 to start it all off.

thanks,

greg k-h

Re: How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Peter Zijlstra]

On Sat, 2008-06-21 at 00:19 -0700, Greg KH wrote:
> On Sat, Jun 21, 2008 at 12:40:17PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today I have done a test merge of linux-staging into linux-next.
> 
> Thanks for doing this.
> 
> I've been thinking this past week about how to properly handle the
> linux-staging tree.
> 
> For some background, it came about because Ingo pointed out that it
> seems hard to get new drivers merged into the main tree quickly, and
> that perhaps we should have a drivers/staging/ directory in Linus's tree
> where we can dump things in quickly and then clean them up later.
> 
> That got quickly vetoed by a number of other maintainers, and I brought
> up the point of me just doing a separate -staging tree that would be
> something like this, but not go into Linus's tree directly.
> 
> I originally sprung the idea on you of having you merge it into -next to
> get testing and build coverage, but I've been thinking a lot more about
> this, and I don't want to burden you with this, you have enough work to
> do with trying to get the normal -next tree out :)
> 
> So, if you don't mind, and no one else objects, here's how I would like
> to run the -staging tree:
> 
>   - It's a set of patches, in quilt form, that can be applied on top of
>     a released kernel from Linus.
>   - It will be rebased at the least with every -rc and -final release,
>     and probably a lot more frequently with a few -git releases
>     inbetween.
>   - I will do a "roll-up" patch release for ever -final release and -rc
>     release to make it easy for users to grab it and apply it to a
>     release so that they can use the drivers/filesystems contained in
>     it.
>   - Once the patches in the -staging tree are nearing "cleaned up" stage
>     (i.e. their TODO list is finished off), I will submit them to the
>     proper subsystem maintainer for inclusion into their tree, on the
>     way to Linus's tree eventually.
> 
> This process should allow for a much easier barrier to development and
> using the drivers by everyone, instead of having to rebase on top of
> -next, which can be hairy at times.  It also allows distros and anyone
> else to grab the full patchset in a much easier manner for their users,
> if they so desire.
> 
> Does that sound reasonable to everyone?

So what motivates people to keep working on items in your tree if
distros are already shipping their stuff?

Will you drop drivers that stagnate?

Re: How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Greg KH]

On Sat, Jun 21, 2008 at 03:00:08PM +0200, Peter Zijlstra wrote:
> 
> So what motivates people to keep working on items in your tree if
> distros are already shipping their stuff?

The fact that the code still isn't upstream?

And I'm not betting on distros picking this tree up, but it is in an
easy form if they wish to do so :)

> Will you drop drivers that stagnate?

Heh, most of the drivers are in my tree because they were stagnating
somewhere else :)

Hopefully no, it's trivial to drag them along forever, but I'll be
working to get them upstream as fast as I can, and it also provides a
very nice project for someone to pick up and work on, as a number of
developers already have.

thanks,

greg k-h

Re: How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Peter Zijlstra]

On Sat, 2008-06-21 at 10:50 -0700, Greg KH wrote:
> On Sat, Jun 21, 2008 at 03:00:08PM +0200, Peter Zijlstra wrote:
> > 
> > So what motivates people to keep working on items in your tree if
> > distros are already shipping their stuff?
> 
> The fact that the code still isn't upstream?
> 
> And I'm not betting on distros picking this tree up, but it is in an
> easy form if they wish to do so :)

The point was that for some people being carried by distos is upstream
enough.

So I would discourage distros form picking up this tree.

The scenario I was thinking about is some HW vendor writing a shitty
driver, dumping it in your tree - getting picked up by $DISTRO and
saying, job done, people can use it. Leaving you to pick up the pieces -
which, with you not having hw-docs, is a hard job.

> > Will you drop drivers that stagnate?
> 
> Heh, most of the drivers are in my tree because they were stagnating
> somewhere else :)
> 
> Hopefully no, it's trivial to drag them along forever, but I'll be
> working to get them upstream as fast as I can, and it also provides a
> very nice project for someone to pick up and work on, as a number of
> developers already have.

Good stuff ;-)

Re: How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Greg KH]

On Sat, Jun 21, 2008 at 08:02:22PM +0200, Peter Zijlstra wrote:
> The point was that for some people being carried by distos is upstream
> enough.
> 
> So I would discourage distros form picking up this tree.

I wouldn't, as some of the drivers work just fine on some arches, but
not all, that is why they are not in mainline yet (the network drivers
in there right now are an example of this.)

> The scenario I was thinking about is some HW vendor writing a shitty
> driver, dumping it in your tree - getting picked up by $DISTRO and
> saying, job done, people can use it. Leaving you to pick up the pieces -
> which, with you not having hw-docs, is a hard job.

If this happens, I'll deal with it then :)

thanks,

greg k-h

Re: How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

[Ingo Molnar]

* Greg KH <greg@kroah.com> wrote:

> On Sat, Jun 21, 2008 at 08:02:22PM +0200, Peter Zijlstra wrote:
> > The point was that for some people being carried by distos is upstream
> > enough.
> > 
> > So I would discourage distros form picking up this tree.
> 
> I wouldn't, as some of the drivers work just fine on some arches, but 
> not all, that is why they are not in mainline yet (the network drivers 
> in there right now are an example of this.)

.. and it's all source code, so it's not really different to distros 
than a number of other patches they regularly pick up. If there's too 
much mess there's always the option to look into the fine source code 
and fix things up.

If a driver ended up not mattering at all in the long run then nobody 
will ever fix it up - and we dont even care that much - it's almost as 
if it didnt even exist.

The other alternative is much more harmful: vendors release binary-only 
drivers. That only works on x86 and they are utterly unfixable as well 
and have a lot of other disadvantages.

So we really have to balance the natural desire for pure upstream 
drivers against the real dangers of vendors doing bin-only modules just 
for the convenience of distribution.

... all in one: kudos Greg for doing the linux-staging tree! :-) It will 
help a lot.

	Ingo