Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1657159 > unrolled thread

new tree for linux-next: uuid

Back to article view | Back to linux.kernel

Contents

  new tree for linux-next: uuid Christoph Hellwig <hch@lst.de> - 2017-06-04 22:20 +0200
    Re: new tree for linux-next: uuid Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-05 02:00 +0200
      Re: new tree for linux-next: uuid Christoph Hellwig <hch@lst.de> - 2017-06-05 10:10 +0200
        Re: new tree for linux-next: uuid Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-06-05 16:10 +0200
          Re: new tree for linux-next: uuid Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-05 16:30 +0200
            Re: new tree for linux-next: uuid Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-06-05 16:50 +0200
              Re: new tree for linux-next: uuid Christoph Hellwig <hch@lst.de> - 2017-06-05 17:00 +0200

#1657159 — new tree for linux-next: uuid

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.

[toc] | [next] | [standalone]

#1657193

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

[toc] | [prev] | [next] | [standalone]

#1657337

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?

[toc] | [prev] | [next] | [standalone]

#1657618

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

[toc] | [prev] | [next] | [standalone]

#1657629

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

[toc] | [prev] | [next] | [standalone]

#1657642

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

[toc] | [prev] | [next] | [standalone]

#1657647

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web