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.
Hi Christoph,
Quoted 8 lines · On Sun, 4 Jun 2017 22:14:13 +0200 Christoph Hellwig <[email protected]> wrote:
can you please include my uuid tree at:
git://git.infradead.org/users/hch/uuid.gitfor-nextinto 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.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected]
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?
Quoted 6 lines · 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?
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.
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Hi Andy,
Quoted 10 lines · On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko…
Quoted 6 lines · 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?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).
Signature · 2 lines
Cheers, Stephen Rothwell
Quoted 15 lines · Stephen Rothwell
Hi Andy,
Quoted 10 lines · On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko <andriy.shevchenko@…
Quoted 6 lines · 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?I'm a bit out of context. Where this will be used?
Quoted 8 lines
include/uapi/linux/uuid.h(after the uuid lib changes) contains a definition of the macroGUID()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()...
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 23 lines · Andy Shevchenko
Quoted 22 lines · Stephen Rothwell
Hi Andy,
Quoted 10 lines · On Mon, 05 Jun 2017 17:06:45 +0300 Andy Shevchenko <andriy.shevchenko@…
Quoted 6 lines · 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?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 macroGUID()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).
Quoted 8 lines
Quoted 1 line
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.