On Wed, 28 Nov 2018 16:45:44 +0200
Mike Rapoport wrote:
> The mm-api.rst covers variety of memory management APIs under "More Memory
> Management Functions" section. The descriptions included there are in a
> random order there are quite a few of them which makes the section too
> long.
>
>
On 06.12.18 01:26, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we are willing to have more
On Thu, Dec 06, 2018 at 08:26:22AM +0800, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we
Locking Internal section exists in core-api documentation, which is more
suitable for this.
This patch removes the duplication part here.
Signed-off-by: Wei Yang
Reviewed-by: David Hildenbrand
Acked-by: Mike Rapoport
---
Documentation/admin-guide/mm/memory-hotplug.rst | 40
Currently locking for memory hotplug is a little complicated.
Generally speaking, we leverage the two global lock:
* device_hotplug_lock
* mem_hotplug_lock
to serialise the process.
While for the long term, we are willing to have more fine-grained lock
to provide higher scalability.
This
On Wed, Dec 05, 2018 at 01:13:10PM +0100, Michal Hocko wrote:
>On Wed 05-12-18 10:34:26, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>>
>> Generally speaking, we leverage the two global lock:
>>
>> * device_hotplug_lock
>> * mem_hotplug_lock
>>
>> to
On Wed 05-12-18 10:34:26, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we are willing to
On Wed 05-12-18 10:34:25, Wei Yang wrote:
> Locking Internal section exists in core-api documentation, which is more
> suitable for this.
>
> This patch removes the duplication part here.
>
> Signed-off-by: Wei Yang
Yes this doesn't really make any sense in an admin guide. It is a pure
Signed-off-by: James (Qian) Wang
---
Documentation/gpu/drivers.rst| 1 +
Documentation/gpu/komeda-kms.rst | 483 +++
2 files changed, 484 insertions(+)
create mode 100644 Documentation/gpu/komeda-kms.rst
diff --git a/Documentation/gpu/drivers.rst
Signed-off-by: James (Qian) Wang
---
Documentation/gpu/drivers.rst| 1 +
Documentation/gpu/komeda-kms.rst | 483 +++
2 files changed, 484 insertions(+)
create mode 100644 Documentation/gpu/komeda-kms.rst
diff --git a/Documentation/gpu/drivers.rst
On Wed, Dec 05, 2018 at 10:40:45AM +0200, Mike Rapoport wrote:
>On Wed, Dec 05, 2018 at 10:34:26AM +0800, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>>
>> Generally speaking, we leverage the two global lock:
>>
>> * device_hotplug_lock
>> *
On Wed, Dec 05, 2018 at 09:08:47AM +0100, David Hildenbrand wrote:
>On 05.12.18 03:34, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>>
>> Generally speaking, we leverage the two global lock:
>>
>> * device_hotplug_lock
>> * mem_hotplug_lock
>>
>> to
On Wed, Dec 05, 2018 at 10:30:13AM +0200, Mike Rapoport wrote:
>On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
>> On 05.12.18 03:34, Wei Yang wrote:
>> > Locking Internal section exists in core-api documentation, which is more
>> > suitable for this.
>> >
>> > This patch
On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
>On 05.12.18 03:34, Wei Yang wrote:
>> Locking Internal section exists in core-api documentation, which is more
>> suitable for this.
>>
>> This patch removes the duplication part here.
>>
>> Signed-off-by: Wei Yang
>> ---
>>
On Wed, Dec 05, 2018 at 10:34:26AM +0800, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we
On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
> On 05.12.18 03:34, Wei Yang wrote:
> > Locking Internal section exists in core-api documentation, which is more
> > suitable for this.
> >
> > This patch removes the duplication part here.
> >
> > Signed-off-by: Wei Yang
> >
On 05.12.18 03:34, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
>
> Generally speaking, we leverage the two global lock:
>
> * device_hotplug_lock
> * mem_hotplug_lock
>
> to serialise the process.
>
> While for the long term, we are willing to have more
On 05.12.18 03:34, Wei Yang wrote:
> Locking Internal section exists in core-api documentation, which is more
> suitable for this.
>
> This patch removes the duplication part here.
>
> Signed-off-by: Wei Yang
> ---
> Documentation/admin-guide/mm/memory-hotplug.rst | 40
>
Currently locking for memory hotplug is a little complicated.
Generally speaking, we leverage the two global lock:
* device_hotplug_lock
* mem_hotplug_lock
to serialise the process.
While for the long term, we are willing to have more fine-grained lock
to provide higher scalability.
This
Locking Internal section exists in core-api documentation, which is more
suitable for this.
This patch removes the duplication part here.
Signed-off-by: Wei Yang
---
Documentation/admin-guide/mm/memory-hotplug.rst | 40 -
1 file changed, 40 deletions(-)
diff --git
--
Hello,
First of all i will like to apologies for my manner of communication
because you do not know me personally, its due to the fact that i have a
very important proposal for you.
--
Brauchen Sie einen Kredit?
RFC 5735 defines this subnets for documentation and example code:
192.0.2.0/24 as TEST-NET-1
198.51.100.0/24 as TEST-NET-2
203.0.113.0/24 as TEST-NET-3
Replace where possible the IP addresses in the documentation with
addresses belonging to the test subnets.
Signed-off-by: Matteo Croce
The mm-api.rst covers variety of memory management APIs under "More Memory
Management Functions" section. The descriptions included there are in a
random order there are quite a few of them which makes the section too
long.
Regrouping the documentation by subject and splitting the long "More
--
Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben
Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der
ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von
2% .reply, wenn nötig.
Good Day, We are a registered private money lender. We
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooparation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
On Thu, 22 Nov 2018 13:06:04 +0200
Sakari Ailus wrote:
> The kernel-doc attempts to clear the struct and struct member attributes
> from the API documentation it produces. It falls short of the job in the
> following respects:
>
> - extra whitespaces are left where __attribute__((...)) was
Hello,
First of all i will like to apologies for my manner of communication because
you do not know me personally, its due to the fact that i have a very important
proposal for you.
Hello,
First of all i will like to apologies for my manner of communication because
you do not know me personally, its due to the fact that i have a very important
proposal for you.
Hello,
First of all i will like to apologies for my manner of communication because
you do not know me personally, its due to the fact that i have a very important
proposal for you.
Hello,
First of all i will like to apologies for my manner of communication because
you do not know me personally, its due to the fact that i have a very important
proposal for you.
The kernel-doc attempts to clear the struct and struct member attributes
from the API documentation it produces. It falls short of the job in the
following respects:
- extra whitespaces are left where __attribute__((...)) was removed,
- only a single attribute is removed per struct,
-
On 11/14/2018 1:04 PM, Casey Schaufler wrote:
> On 10/24/2018 1:12 PM, Kees Cook wrote:
>> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler
>> wrote:
>>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
On 10/23/2018 11:50 AM, Kees Cook wrote:
> Did you poke around at my combined
On Sun, 11 Nov 2018 11:24:23 +0200
Mike Rapoport wrote:
> Signed-off-by: Mike Rapoport
> Reviewed-by: Randy Dunlap
> ---
>
> v2: address Matthew's feedback
>
> Documentation/admin-guide/mm/concepts.rst | 51
> ---
> 1 file changed, 26 insertions(+), 25
On Sun, 11 Nov 2018 18:48:44 +0200
Mike Rapoport wrote:
> Add references to GFP documentation and the memory-allocation.rst and remove
> GFP_USER, GFP_DMA and GFP_NOIO descriptions.
>
> While on it slightly change the formatting so that the list of GFP flags
> will be rendered as "description"
On Mon, 19 Nov 2018 08:00:49 -0800
Matthew Wilcox wrote:
> I just went looking for the memory allocation guide in the MM docs instead
> of in the core API. For the benefit of the next person who makes that
> mistake, link to it from the MM docs.
>
> Signed-off-by: Matthew Wilcox
Applied,
On Mon, Nov 19, 2018 at 08:00:49AM -0800, Matthew Wilcox wrote:
> I just went looking for the memory allocation guide in the MM docs instead
> of in the core API. For the benefit of the next person who makes that
> mistake, link to it from the MM docs.
>
> Signed-off-by: Matthew Wilcox
On Mon, Nov 19, 2018 at 2:54 AM, Pavel Machek wrote:
> On Mon 2018-11-05 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors refer to the old,
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 50ce1bddaf56..f91da3d0a67e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -670,7 +670,7 @@ PAGEFLAG_FALSE(DoubleMap)
> #define PAGE_TYPE_BASE 0xf000
> /* Reserve
I just went looking for the memory allocation guide in the MM docs instead
of in the core API. For the benefit of the next person who makes that
mistake, link to it from the MM docs.
Signed-off-by: Matthew Wilcox
diff --git a/Documentation/core-api/memory-allocation.rst
On 10/24/2018 1:12 PM, Kees Cook wrote:
> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler
> wrote:
>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>>
Did you poke around at my combined series?
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel
Add references to GFP documentation and the memory-allocation.rst and remove
GFP_USER, GFP_DMA and GFP_NOIO descriptions.
While on it slightly change the formatting so that the list of GFP flags
will be rendered as "description" in the generated html.
Signed-off-by: Mike Rapoport
---
Probably
Signed-off-by: Mike Rapoport
Reviewed-by: Randy Dunlap
---
v2: address Matthew's feedback
Documentation/admin-guide/mm/concepts.rst | 51 ---
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/Documentation/admin-guide/mm/concepts.rst
On Thu, 1 Nov 2018 09:57:17 -0400
Amir Livneh wrote:
> Trivial fixes to spelling mistakes in ftrace.rst
>
> v2: tripple -> triple
>
> Signed-off-by: Amir Livneh
Applied, thanks.
jon
Commit df06b37ffe5a ("mm/gup: cache dev_pagemap while pinning pages")
modified the signature of follow_page_mask() function but left the
parameter description behind.
Update the description to make the code and comments agree again.
While on it, update formatting of the return value description
On Mon, Nov 05, 2018 at 11:29:27PM -0800, Randy Dunlap wrote:
> On 11/5/18 10:35 PM, Mike Rapoport wrote:
> > On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
> >> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> >>> @@ -21,10 +21,10 @@ Virtual Memory Primer
> >>>
On 11/5/18 10:35 PM, Mike Rapoport wrote:
> On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
>> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
>>> @@ -21,10 +21,10 @@ Virtual Memory Primer
>>> The physical memory in a computer system is a limited resource and
>>>
On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> > @@ -21,10 +21,10 @@ Virtual Memory Primer
> > The physical memory in a computer system is a limited resource and
> > even for systems that support memory hotplug
On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> @@ -21,10 +21,10 @@ Virtual Memory Primer
> The physical memory in a computer system is a limited resource and
> even for systems that support memory hotplug there is a hard limit on
> the amount of memory that can be installed.
On 11/5/18 11:58 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Signed-off-by: Mike Rapoport
> Cc: Randy Dunlap
> ---
>
> There was a couple of grammar fixes Randy suggested a while ago, but it
> seems I've never sent them out.
>
> Documentation/admin-guide/mm/concepts.rst | 39
>
From: Mike Rapoport
Signed-off-by: Mike Rapoport
Cc: Randy Dunlap
---
There was a couple of grammar fixes Randy suggested a while ago, but it
seems I've never sent them out.
Documentation/admin-guide/mm/concepts.rst | 39 ---
1 file changed, 20 insertions(+), 19
On Mon, Nov 5, 2018 at 5:15 AM Martin Schwidefsky
wrote:
>
> This patch would work for me:
Thanks, applied,
Linus
On Mon, 5 Nov 2018 14:15:35 +0100
Martin Schwidefsky wrote:
>
> Follow-up question: the __no_sanitize_address_or_inline define has the
> 'notrace'
> option that is missing for __no_kasan_or_inline. We need that option for
> __load_psw_mask, if we do the replacement all users of
On Mon, 5 Nov 2018 07:02:56 +0100
Martin Schwidefsky wrote:
> On Fri, 2 Nov 2018 09:09:32 -0700
> Linus Torvalds wrote:
>
> > On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin
> > wrote:
> > >
> > > You're right, version checks shouldn't matter here. But
> > > __no_sanitize_address_or_inline
On Fri, 2 Nov 2018 09:09:32 -0700
Linus Torvalds wrote:
> On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin
> wrote:
> >
> > You're right, version checks shouldn't matter here. But
> > __no_sanitize_address_or_inline
> > shouldn't have been added in the first place, because we already have
> >
On 11/02/2018 07:11 PM, Linus Torvalds wrote:
> On Fri, Nov 2, 2018 at 6:16 AM Andrey Ryabinin
> wrote:
>>
>> On 11/02/2018 04:46 AM, Linus Torvalds wrote:
>>>
>>> So I _think_ the KASAN config should have a
>>>
>>> depends on CC_IS_GCC && GCC_VERSION >= 40902
>>>
>>> on it, but maybe
On Fri, Nov 2, 2018 at 6:16 AM Andrey Ryabinin wrote:
>
> On 11/02/2018 04:46 AM, Linus Torvalds wrote:
> >
> > So I _think_ the KASAN config should have a
> >
> > depends on CC_IS_GCC && GCC_VERSION >= 40902
> >
> > on it, but maybe there is something I'm missing.
>
> I'd rather use
On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin wrote:
>
> You're right, version checks shouldn't matter here. But
> __no_sanitize_address_or_inline
> shouldn't have been added in the first place, because we already have almost
> the same
>__no_kasan_or_inline:
Ahh, very good.
Vasily, Martin -
On 11/02/2018 04:46 AM, Linus Torvalds wrote:
> On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds
> wrote:
>>
>> The logic for using __no_sanitize_address *used* to be
>>
>> #if GCC_VERSION >= 40902
>
> Ok, looking around, I think this has less to do with the attribute
> being recognized,
On Fri, Nov 2, 2018 at 2:52 AM Linus Torvalds
wrote:
>
> Anyway, I decided to do the merge by just getting rid of the
> GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
> you enable KASAN, then a function with that marking just won't be
> marked inline.
I was a bit confused
On 11/01/2018 08:06 PM, Linus Torvalds wrote:
> On Mon, Oct 22, 2018 at 3:59 AM Miguel Ojeda
> wrote:
>>
>> Here it is the Compiler Attributes series/tree, which tries to disentangle
>> the include/linux/compiler*.h headers and bring them up to date.
>
> I've finally emptied the "normal" pull
On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds
wrote:
>
> The logic for using __no_sanitize_address *used* to be
>
> #if GCC_VERSION >= 40902
Ok, looking around, I think this has less to do with the attribute
being recognized, and simply just being because KASAN itself wants
gcc-4.9.2.
I'm
On Thu, Nov 1, 2018 at 6:06 PM Linus Torvalds
wrote:
>
> I'm not sure how much that matters (maybe the original check for 4.9.2
> was just a random pick by Andrey? Added to cc), but together with the
> movement to that looks like it also
> wouldn't want the CONFIG_KASAN tests, I wonder what the
On 2018-10-31 14:16, Amir Livneh wrote:
> @@ -2978,7 +2978,7 @@ The following commands are supported:
>When the function is hit, it will dump the contents of the ftrace
>ring buffer to the console. This is useful if you need to debug
>something, and want to dump the trace when a
Trivial fixes to spelling mistakes in ftrace.rst
Signed-off-by: Amir Livneh
---
Documentation/trace/ftrace.rst | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 7ea16a0ceffc..80fde12e6564
On Fri, 26 Oct 2018 16:43:28 +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Cc: Rob Herring
> Signed-off-by: Boris Brezillon
On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler wrote:
> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>
>>> Did you poke around at my combined series?
>>>
On 10/23/2018 12:05 PM, Casey Schaufler wrote:
> On 10/23/2018 11:50 AM, Kees Cook wrote:
>
>> Did you poke around at my combined series?
>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
> I hope to do that on the plane later today.
I had a
On 10/23/2018 11:50 AM, Kees Cook wrote:
> On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler
> wrote:
>> On 10/12/2018 12:01 PM, Kees Cook wrote:
>>> On Friday, October 12, 2018 3:19 AM, John Johansen
>>> wrote:
It isn't perfect but it manages consistency across distros as best as
can
On Mon, Oct 22, 2018 at 11:15 AM Bernd Petrovitsch
wrote:
>
> Hi all!
>
> On 22/10/18 19:54, Nick Desaulniers wrote:
> > On Mon, Oct 22, 2018 at 10:50 AM Bernd Petrovitsch
> > wrote:
> [...]
> >> PS: clang++ errors with "fallthrough annotation in unreachable code" if
> >> [[fallthrough]] is
Hi Linus,
Here it is the Compiler Attributes series/tree, which tries to disentangle
the include/linux/compiler*.h headers and bring them up to date.
The patches have been in linux-next for a while, *except* the last two
from Nick which came a bit later. Since AFAIU there will be no linux-next
From: Guillaume Dore
There was a typo in adding-syscalls.rst that could mislead developers
to add a C filename in a makefile instead of an object filename.
This error, while not keeping developers from contributing could slow
the development process down by introducing build errors.
On Thu, 18 Oct 2018 17:47:50 +0200
cor...@poussif.eu wrote:
> There was a typo in adding-syscalls.rst that could mislead developers
> to add a C filename in a makefile instead of an object filename.
> This error, while not keeping developers from contributing could slow
> the development process
Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 2,800,000.00EUR Ich
gewann die America Lottery im Wert von $ 758.7 Millionen und ich spende einen
Teil davon an fnf glckliche Menschen und
Wohlttigkeits-Huser in Erinnerung an meinen verstorbenen Ehemann,
der an Krebs gestorben ist.
On Mon, 15 Oct 2018 02:55:49 -0700
Christoph Hellwig wrote:
> > OK, I've had a long conversation with the LF lawyer, and she said clearly
> > that we really should not be introducing CC-SA material into the kernel
> > source tree. It's a pain; I really do like CC-SA better for
> >
On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000
> Dave Chinner wrote:
>
> > Can you let us know whether the CC-by-SA 4.0 license is acceptible
> > or not? That's really the only thing that we need clarified at this
> > point - if it's OK I'll
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000 Dave Chinner
> wrote:
>
> > Can you let us know whether the CC-by-SA 4.0 license is
> > acceptible or not? That's really the only thing that we need
> > clarified at this point - if it's OK I'll
On Sat, 6 Oct 2018 10:51:54 +1000
Dave Chinner wrote:
> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go
On Sun, Oct 07, 2018 at 08:46:40AM -0600, Jonathan Corbet wrote:
> On Fri, 5 Oct 2018 01:11:01 +0300
> Mike Rapoport wrote:
>
> > The memory hotplug notifier description is about kernel internals rather
> > than admin/user visible API. Place it appropriately.
> >
> > Signed-off-by: Mike
On Thu, 4 Oct 2018 18:06:03 -0700
"Darrick J. Wong" wrote:
> o my eyesight still hasn't fully recovered, so in the meantime it's
> been difficult to read the online documentation. Here's some stylesheet
> overrides I've been using to make it easier for me to read them:
>
On Fri, 5 Oct 2018 01:11:01 +0300
Mike Rapoport wrote:
> The memory hotplug notifier description is about kernel internals rather
> than admin/user visible API. Place it appropriately.
>
> Signed-off-by: Mike Rapoport
One little nit...
> Documentation/admin-guide/mm/memory-hotplug.rst|
On Fri, 5 Oct 2018 19:49:52 -0400
"Theodore Y. Ts'o" wrote:
> On Thu, Oct 04, 2018 at 05:59:44PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Move the ext4 data structures book to Documentation/filesystems/ext4/
> > since the administrative information moved elsewhere.
> >
On Sat, 6 Oct 2018 06:29:51 -0700
Matthew Wilcox wrote:
> I had an informal chat with Bradley Kuhn at LinuxCon Japan about using
> CC-BY-SA-4.0 and he indicated that I was probably better off using the
> GPL-2(+) for documentation. I've changed the XArray documentation from
> CC-BY-SA-4.0 to
On Sat, Oct 06, 2018 at 10:51:54AM +1000, Dave Chinner wrote:
> On Wed, Oct 03, 2018 at 09:18:11PM -0700, Darrick J. Wong wrote:
> > Hi all,
> >
> > This series converts the existing in-kernel xfs documentation to rst
> > format, links it in with the rest of the kernel's rst documetation, and
> >
On Sat, Oct 6, 2018 at 9:13 AM Sedat Dilek wrote:
>
> Hi Miguel,
>
> In my testoings I am booting in QEMU and on bare metal.
> Both tests were successful.
Wow! I only wanted to confirm it booted and/or run for a while -- but
having more information is always good. Thanks a *lot*!
I will add a
On Fri, Oct 05, 2018 at 07:01:20PM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000
> Dave Chinner wrote:
>
> > Can you let us know whether the CC-by-SA 4.0 license is acceptible
> > or not? That's really the only thing that we need clarified at this
> > point - if it's OK I'll
On Sat, 6 Oct 2018 10:51:54 +1000
Dave Chinner wrote:
> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go
On Wed, Oct 03, 2018 at 09:18:11PM -0700, Darrick J. Wong wrote:
> Hi all,
>
> This series converts the existing in-kernel xfs documentation to rst
> format, links it in with the rest of the kernel's rst documetation, and
> then begins pulling in the contents of the Data Structures & Algorithms
>
On Thu, Oct 04, 2018 at 06:06:03PM -0700, Darrick J. Wong wrote:
> Hi,
>
> So my eyesight still hasn't fully recovered, so in the meantime it's
> been difficult to read the online documentation. Here's some stylesheet
> overrides I've been using to make it easier for me to read them:
>
On Thu, Oct 04, 2018 at 05:59:44PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Move the ext4 data structures book to Documentation/filesystems/ext4/
> since the administrative information moved elsewhere.
>
> Signed-off-by: Darrick J. Wong
Thanks, applied and pushed out to the
On 10/5/18 8:22 AM, Theodore Y. Ts'o wrote:
> On Thu, Oct 04, 2018 at 07:48:31PM -0700, Randy Dunlap wrote:
>> Hi Darrick,
>>
>> I don't see patch 2/2 anywhere (my inbox, email archives)...
>
> Probably because it's moving a lot of files around, so the diffs were 276k.
Oh, yeah. Thanks.
--
On Thu, Oct 04, 2018 at 07:48:31PM -0700, Randy Dunlap wrote:
> Hi Darrick,
>
> I don't see patch 2/2 anywhere (my inbox, email archives)...
Probably because it's moving a lot of files around, so the diffs were 276k.
>
> --
> ~Randy
On 10/4/18 5:59 PM, Darrick J. Wong wrote:
> Hi all,
>
> This series fixes some problems that were brought up during review for
> the XFS documentation which I hadn't known about when pushing the ext4
> documentation during the 4.19 cycle.
>
> The first patch moves the ext4 mount option and
Hi,
So my eyesight still hasn't fully recovered, so in the meantime it's
been difficult to read the online documentation. Here's some stylesheet
overrides I've been using to make it easier for me to read them:
https://djwong.org/docs/kdoc/index.html
---
From: Darrick J. Wong
My eyesight is
From: Darrick J. Wong
Move the ext4 mount option and other administrative stuff to the Linux
administrator's guide.
Signed-off-by: Darrick J. Wong
---
Documentation/admin-guide/ext4.rst | 574 ++
Documentation/admin-guide/index.rst |1
Hi all,
This series fixes some problems that were brought up during review for
the XFS documentation which I hadn't known about when pushing the ext4
documentation during the 4.19 cycle.
The first patch moves the ext4 mount option and sysfs knob information
into the Linux administration guide.
The memory hotplug notifier description is about kernel internals rather
than admin/user visible API. Place it appropriately.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/mm/memory-hotplug.rst| 83 -
Documentation/core-api/index.rst | 2 +
1 - 100 of 17763 matches
Mail list logo
