new tree for linux-next: uuid

new tree for linux-next: uuid

[Christoph Hellwig]

Hi Stephen,

can you please include my uuid tree at:

	git://git.infradead.org/users/hch/uuid.git for-next

into linux-next?  We've been doing a fair amount of work on the
uuid library and I plan to send it and some work that will pile
up on top of it to Linus for the next merge window.

Re: new tree for linux-next: uuid

[Stephen Rothwell]

Hi Christoph,

On Sun, 4 Jun 2017 22:14:13 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> can you please include my uuid tree at:
> 
> 	git://git.infradead.org/users/hch/uuid.git for-next
> 
> into linux-next?  We've been doing a fair amount of work on the
> uuid library and I plan to send it and some work that will pile
> up on top of it to Linus for the next merge window.

Added from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Re: new tree for linux-next: uuid

[Christoph Hellwig]

Meh, thanks.  This has been throught the buildbot countless times
without a report.  But I guess a less generic name might be a good
idea to start with.

Andy: do you think UUID_INIT/GUID_INIT make sense to your?
or _INITIALIZER?

Re: new tree for linux-next: uuid

[Andy Shevchenko]

On Mon, 2017-06-05 at 10:07 +0200, Christoph Hellwig wrote:
> Meh, thanks.  This has been throught the buildbot countless times
> without a report.  But I guess a less generic name might be a good
> idea to start with.
> 
> Andy: do you think UUID_INIT/GUID_INIT make sense to your?
> or _INITIALIZER?

I'm a bit out of context. Where this will be used?

P.S. W/o context latter sounds better to me, but... see above.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: new tree for linux-next: uuid

[Stephen Rothwell]

Hi Andy,

On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, 2017-06-05 at 10:07 +0200, Christoph Hellwig wrote:
> > Meh, thanks.  This has been throught the buildbot countless times
> > without a report.  But I guess a less generic name might be a good
> > idea to start with.
> > 
> > Andy: do you think UUID_INIT/GUID_INIT make sense to your?
> > or _INITIALIZER?  
> 
> I'm a bit out of context. Where this will be used?

include/uapi/linux/uuid.h (after the uuid lib changes) contains a
definition of the macro GUID() which is probably a bit generic a name
for a uapi include file.  It also clashes with a couple of other uses
of that macro name already in the kernel (one of which produced several
warnings in linux-next today).

It produces an initializer for a guid_t (structure).

-- 
Cheers,
Stephen Rothwell

Re: new tree for linux-next: uuid

[Andy Shevchenko]

On Tue, 2017-06-06 at 00:29 +1000, Stephen Rothwell wrote:
> Hi Andy,
> 
> On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko <andriy.shevchenko@
> linux.intel.com> wrote:
> > 
> > On Mon, 2017-06-05 at 10:07 +0200, Christoph Hellwig wrote:
> > > Meh, thanks.  This has been throught the buildbot countless times
> > > without a report.  But I guess a less generic name might be a good
> > > idea to start with.
> > > 
> > > Andy: do you think UUID_INIT/GUID_INIT make sense to your?
> > > or _INITIALIZER?  
> > 
> > I'm a bit out of context. Where this will be used?
> 
> include/uapi/linux/uuid.h (after the uuid lib changes) contains a
> definition of the macro GUID() which is probably a bit generic a name
> for a uapi include file.  It also clashes with a couple of other uses
> of that macro name already in the kernel (one of which produced
> several
> warnings in linux-next today).
> 
> It produces an initializer for a guid_t (structure).

Just had read and finished answering to a warning.
In kernel users shouldn't really use so generic names, we may fix it.

OTOH, for user space I dunno if need to export that at all.
If we need by some reason, shorter version looks better, GUID_INIT(),
UUID_INIT()...

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: new tree for linux-next: uuid

[Christoph Hellwig]

On Mon, Jun 05, 2017 at 05:43:18PM +0300, Andy Shevchenko wrote:
> On Tue, 2017-06-06 at 00:29 +1000, Stephen Rothwell wrote:
> > Hi Andy,
> > 
> > On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko <andriy.shevchenko@
> > linux.intel.com> wrote:
> > > 
> > > On Mon, 2017-06-05 at 10:07 +0200, Christoph Hellwig wrote:
> > > > Meh, thanks.  This has been throught the buildbot countless times
> > > > without a report.  But I guess a less generic name might be a good
> > > > idea to start with.
> > > > 
> > > > Andy: do you think UUID_INIT/GUID_INIT make sense to your?
> > > > or _INITIALIZER?  
> > > 
> > > I'm a bit out of context. Where this will be used?
> > 
> > include/uapi/linux/uuid.h (after the uuid lib changes) contains a
> > definition of the macro GUID() which is probably a bit generic a name
> > for a uapi include file.  It also clashes with a couple of other uses
> > of that macro name already in the kernel (one of which produced
> > several
> > warnings in linux-next today).
> > 
> > It produces an initializer for a guid_t (structure).
> 
> Just had read and finished answering to a warning.
> In kernel users shouldn't really use so generic names, we may fix it.
> 
> OTOH, for user space I dunno if need to export that at all.
> If we need by some reason, shorter version looks better, GUID_INIT(),
> UUID_INIT()...

I'll fix it up without resending the whole series.  I'll also apply your
ACPI changes and if there is no major fallout we can declare the
branch stable for drm in a few days.