Linux 5.0-rc1

Linux 5.0-rc1

[Linus Torvalds]

So this was a fairly unusual merge window with the holidays, and as a
result I'm not even going to complain about the pull requests that
ended up coming in late. It all mostly worked out fine, I think. And
lot of people got their pull requests in early, and hopefully had a
calm holiday season. Thanks again to everybody.

The numbering change is not indicative of anything special. If you
want to have an official reason, it's that I ran out of fingers and
toes to count on, so 4.21 became 5.0. There's no nice git object
numerology this time (we're _about_ 6.5M objects in the git repo), and
there isn't any major particular feature that made for the release
numbering either. Of course, depending on your particular interests,
some people might well find a feature _they_ like so much that they
think it can do as a reason for incrementing the major number.

So go wild. Make up your own reason for why it's 5.0.

Because as usual, there's a lot of changes in there. Not because this
merge window was particularly big - but even our smaller merge windows
aren't exactly small. It's a very solid and average merge window with
just under 11k commits (or about 11.5k if you count merges).

The stats look fairly normal. About 50% is drivers, 20% is
architecture updates, 10% is tooling, and the remaining 20% is all
over (documentation, networking, filesystems, header file updates,
core kernel code..). Nothing particular stands out, although I do like
seeing how some ancient drivers are getting put out to pasture
(*cought*isdn*cough*).

As usual even the shortlog is much too big to post, so the summary
below is only a list of the pull requests I merged.

Go test. Kick the tires. Be the first kid on your block running a 5.0
pre-release kernel.

              Linus

---

Al Viro (2):
    trivial vfs updates
    vfs mount API prep

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andrew Morton (2):
    misc updates
    more updates

Andy Shevchenko (1):
    x86 platform driver updates

Anna Schumaker (1):
    NFS client updates

Arnd Bergmann (2):
    arch/sh syscall table scripting
    y2038 updates

Bartlomiej Zolnierkiewicz (1):
    fbdev updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (1):
    hwspinlock updates

Bjorn Helgaas (1):
    PCI updates

Bob Peterson (1):
    gfs2 updates

Boris Brezillon (2):
    initial i3c support
    mtd updates

Borislav Petkov (4):
    EDAC updates
    x86 cache control updates
    x86 microcode loading updates
    x86 RAS updates

Bruce Fields (1):
    nfsd updates

Christoph Hellwig (2):
    DMA mapping updates
    dma-mapping fixes

Dan Williams (2):
    libnvdimm updates
    dax fix

Daniel Thompson (1):
    kgdb updates

Darrick Wong (4):
    XFS updates
    iomap update
    xfs fixlets
    iomap maintainer update

Dave Airlie (3):
    drm updates
    more drm updates
    drm fixes

David Miller (3):
    sparc updates
    networking updates
    networking fixes

David Sterba (1):
    btrfs updates

David Teigland (1):
    dlm updates

Dennis Zhou (1):
    percpu update

Dmitry Torokhov (1):
    input updates

Dominique Martinet (1):
    9p updates

Eduardo Valentin (1):
    thermal SoC updates

Geert Uytterhoeven (1):
    m68k updates

Greentime Hu (1):
    nds32 updates

Greg KH (5):
    USB/PHY updates
    tty/serial driver updates
    staging/IIO driver updates
    driver core updates
    char/misc driver updates

Guenter Roeck (1):
    hwmon updates

Guo Ren (1):
    arch/csky updates

Helge Deller (2):
    parisc updates
    parisc fix

Herbert Xu (1):
    crypto updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (15):
    RCU updates
    EFI updates
    locking updates
    perf updates
    scheduler updates
    x86 AMD northbridge updates
    x86 asm updates
    x86 boot updates
    x86 build updates
    x86 cleanups
    x86 cpu updates
    x86 fpu updates
    x86 mm updates
    x86 platform update
    scheduler fix

Jacek Anaszewski (1):
    LED updates

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (1):
    SCSI updates

James Morris (5):
    general security subsystem updates
    integrity updates
    seccomp updates
    smack updates
    TPM updates

Jan Kara (2):
    fsnotify updates
    ext2, udf, and quota update

Jason Gunthorpe (2):
    rdma updates
    rdma fixes

Jassi Brar (1):
    mailbox updates

Jeff Layton (2):
    file locking updates
    file locking bugfix

Jens Axboe (6):
    block updates
    aio updates
    libata updates
    libata fix
    more block updates
    block updates and fixes

Jessica Yu (1):
    modules updates

Jiri Kosina (2):
    livepatch update
    HID updates

Joerg Roedel (1):
    IOMMU updates

Jonathan Corbet (2):
    documentation update
    documentation fixes

Juergen Gross (1):
    xen updates

Kees Cook (2):
    pstore updates
    gcc-plugins update

Linus Walleij (2):
    GPIO updates
    pin control updates

Mark Brown (3):
    regulator updates
    spi updates
    regmap updates

Martin Schwidefsky (1):
    s390 updates

Masahiro Yamada (4):
    Kbuild updates
    Kconfig updates
    Kconfig file consolidation
    more Kbuild updates

Matt Turner (1):
    alpha architecture updates

Mauro Carvalho Chehab (2):
    media updates
    more media updates

Max Filippov (1):
    Xtensa updates

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (1):
    virtio/vhost updates

Michal Simek (1):
    arch/microblaze updates

Mike Snitzer (1):
    device mapper updates

Olof Johansson (5):
    arm SoC platform updates
    ARM SoC driver updates
    ARM Device-tree updates
    ARM SoC defconfig updates
    more ARM SoC updates

Palmer Dabbelt (1):
    RISC-V updates

Paolo Bonzini (1):
    KVM updates

Paul Burton (2):
    MIPS updates
    MIPS fixes

Paul Moore (2):
    audit updates
    selinux patches

Petr Mladek (1):
    printk updates

Rafael Wysocki (4):
    power management updates
    ACPI updates
    device properties framework updates
    device properties framework fixes

Richard Weinberger (1):
    UML updates

Rob Herring (1):
    Devicetree updates

Russell King (1):
    ARM updates

Sebastian Reichel (2):
    power supply and reset updates
    HSI update

Shuah Khan (1):
    Kselftest updates

Stafford Horne (1):
    OpenRISC update

Stefan Richter (1):
    firewire fixlet

Stephen Boyd (2):
    clk updates
    more clk updates

Steve French (2):
    cifs updates
    smb3 fixes

Steven Rostedt (2):
    tracing updates
    ftrace sh build fix

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (3):
    ext4 updates
    ext4 bug fixes
    fscrypt updates

Tejun Heo (1):
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (3):
    irq updates
    timer updates
    x86 pti updates

Tony Luck (1):
    ia64 updates

Ulf Hansson (1):
    MMC updates

Vinod Koul (1):
    dmaengine updates

Will Deacon (2):
    arm64 festive updates
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Yoshinori Sato (1):
    h8300 fix

Zhang Rui (1):
    thermal management updates

linux-next: stats (was: Linux 5.0-rc1)

[Stephen Rothwell]

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

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20181224 was the last linux-next before
the merge window opened.)

Commits in v5.0-rc1 (relative to v4.20):           10843
Commits in next-20181224:                          10867
Commits with the same SHA1:                        10044
Commits with the same patch_id:                      301 (1)
Commits with the same subject line:                   52 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20181224:     10397 95%

Some breakdown of the list of extra commits (relative to next-20181224)
in -rc1:

Top ten first word of commit summary:

     49 drm
     26 cifs
     24 perf
     19 net
     16 um
     16 thermal
     16 dt-bindings
     16 csky
     11 arm64
      9 pci

Top ten authors:

     20 yamada.masahiro@socionext.com
     15 ren_guo@c-sky.com
     12 torvalds@linux-foundation.org
     12 palcantara@suse.de
     11 anton.ivanov@cambridgegreys.com
     11 acme@redhat.com
     10 vvs@virtuozzo.com
     10 hch@lst.de
      9 julia.lawall@lip6.fr
      9 daniel@iogearbox.net

Top ten commiters:

     51 davem@davemloft.net
     46 alexander.deucher@amd.com
     29 acme@redhat.com
     28 stfrench@microsoft.com
     23 torvalds@linux-foundation.org
     22 edubezval@gmail.com
     19 yamada.masahiro@socionext.com
     19 ren_guo@c-sky.com
     17 richard@nod.at
     14 axboe@kernel.dk

There are also 470 commits in next-20181224 that didn't make it into
v5.0-rc1.

Top ten first word of commit summary:

     43 asoc
     37 mm
     23 mfd
     23 arm
     19 vfs
     18 leaking_addresses
     15 xtensa
     13 nios2
     11 nfc
     11 dt-bindings

Top ten authors:

     34 dhowells@redhat.com
     32 akpm@linux-foundation.org
     18 me@tobin.cc
     17 kuninori.morimoto.gx@renesas.com
     13 olof@lixom.net
     13 jcmvbkbc@gmail.com
     13 ebiggers@google.com
     11 npiggin@gmail.com
     10 david@redhat.com
      9 dan.carpenter@oracle.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

    125 sfr@canb.auug.org.au
     45 broonie@kernel.org
     36 dhowells@redhat.com
     26 lee.jones@linaro.org
     25 tytso@mit.edu
     18 me@tobin.cc
     16 jcmvbkbc@gmail.com
     13 p.zabel@pengutronix.de
     13 olof@lixom.net
     13 ley.foon.tan@intel.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Linux 5.0-rc1 (test results)

[Guenter Roeck]

On Sun, Jan 06, 2019 at 06:14:15PM -0800, Linus Torvalds wrote:
> So this was a fairly unusual merge window with the holidays, and as a
> result I'm not even going to complain about the pull requests that
> ended up coming in late. It all mostly worked out fine, I think. And
> lot of people got their pull requests in early, and hopefully had a
> calm holiday season. Thanks again to everybody.
> 
> The numbering change is not indicative of anything special. If you
> want to have an official reason, it's that I ran out of fingers and
> toes to count on, so 4.21 became 5.0. There's no nice git object
> numerology this time (we're _about_ 6.5M objects in the git repo), and
> there isn't any major particular feature that made for the release
> numbering either. Of course, depending on your particular interests,
> some people might well find a feature _they_ like so much that they
> think it can do as a reason for incrementing the major number.
> 
> So go wild. Make up your own reason for why it's 5.0.
> 
> Because as usual, there's a lot of changes in there. Not because this
> merge window was particularly big - but even our smaller merge windows
> aren't exactly small. It's a very solid and average merge window with
> just under 11k commits (or about 11.5k if you count merges).
> 
> The stats look fairly normal. About 50% is drivers, 20% is
> architecture updates, 10% is tooling, and the remaining 20% is all
> over (documentation, networking, filesystems, header file updates,
> core kernel code..). Nothing particular stands out, although I do like
> seeing how some ancient drivers are getting put out to pasture
> (*cought*isdn*cough*).
> 
> As usual even the shortlog is much too big to post, so the summary
> below is only a list of the pull requests I merged.
> 
> Go test. Kick the tires. Be the first kid on your block running a 5.0
> pre-release kernel.
> 

For v5.0-rc1-1-g3bd6e94bec12:

Build results:
	total: 158 pass: 155 fail: 3
Failed builds: 
	csky:defconfig 
	csky:allnoconfig
	csky:tinyconfig 
Qemu test results:
	total: 332 pass: 332 fail: 0

mm/memory.c: In function ‘__pte_alloc’:
mm/memory.c:406:18: error: too few arguments to function ‘pte_alloc_one’

mm/memory.c: In function ‘__pte_alloc_kernel’:
mm/memory.c:439:15: error: too few arguments to function ‘pte_alloc_one_kernel’

mm/memory.c: In function ‘do_fault_around’:
mm/memory.c:3363:23: error: too few arguments to function ‘pte_alloc_one’

Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
argument from pte_alloc functions"). Interesting - wasn't that supposed
to be automatic ?

csky does use the the removed address argument, so I won't even try to
provide a patch. Copying csky maintainer instead.

Guenter

---
# bad: [3bd6e94bec122a951d462c239b47954cf5f36e33] arch: restore generic-y += shmparam.h for some architectures
# good: [3fed6ae4b027f9c93be18520f87bd06bdffd196b] ia64: fix compile without swiotlb
git bisect start 'HEAD' '3fed6ae4b027'
# bad: [e9666d10a5677a494260d60d1fa0b73cc7646eb3] jump_label: move 'asm goto' support test to Kconfig
git bisect bad e9666d10a5677a494260d60d1fa0b73cc7646eb3
# bad: [b23b0ea3708c3dec599966fc856836aca48835b9] Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad b23b0ea3708c3dec599966fc856836aca48835b9
# bad: [9ee3b3f4a5eb523ef27675ac2fcd2269b9d68767] Merge tag 'csky-for-linus-4.21' of git://github.com/c-sky/csky-linux
git bisect bad 9ee3b3f4a5eb523ef27675ac2fcd2269b9d68767
# good: [655c16a8ce9c15842547f40ce23fd148aeccc074] exec: separate MM_ANONPAGES and RLIMIT_STACK accounting
git bisect good 655c16a8ce9c15842547f40ce23fd148aeccc074
# bad: [a65981109f294ba7e64b33ad3b4575a4636fce66] Merge branch 'akpm' (patches from Andrew)
git bisect bad a65981109f294ba7e64b33ad3b4575a4636fce66
# bad: [3bb5f4ac55dd91d516e7e36b45c94bd57efbb068] kernel/locking/mutex.c: remove caller signal_pending branch predictions
git bisect bad 3bb5f4ac55dd91d516e7e36b45c94bd57efbb068
# good: [b058809bfc8faeb7b7cae047666e23375a060059] scripts/gdb: fix lx-version string output
git bisect good b058809bfc8faeb7b7cae047666e23375a060059
# bad: [4cf58924951ef80eec636b863e7a53973c44261a] mm: treewide: remove unused address argument from pte_alloc functions
git bisect bad 4cf58924951ef80eec636b863e7a53973c44261a
# good: [ff1522bb7d98450c72aea729f0b4147bc9986aed] initramfs: cleanup incomplete rootfs
git bisect good ff1522bb7d98450c72aea729f0b4147bc9986aed
# first bad commit: [4cf58924951ef80eec636b863e7a53973c44261a] mm: treewide: remove unused address argument from pte_alloc functions

Re: Linux 5.0-rc1 (test results)

[Linus Torvalds]

On Mon, Jan 7, 2019 at 11:26 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
> argument from pte_alloc functions"). Interesting - wasn't that supposed
> to be automatic ?
>
> csky does use the the removed address argument, so I won't even try to
> provide a patch. Copying csky maintainer instead.

Hmm. Interesting. The csky code seems to have some odd "poison pte
contents with ones if the address has the high bit set".

Which makes little or no sense. The "high bit set" case is for kernel
page tables, but that's exactly the "pte_alloc_one()" vs
"pte_alloc_one_kernel()" distinction.

So testing the address seems entirely wrong.

But there's other strangeness in there too. For example,
pte_alloc_one_kernel() will just write directly to the page. And
pte_alloc_one() will do a "kmap_atomic()" on the page it allocates,
except since it uses GFP_KERNEL, that's entirely pointless.

Is the alloc_pages() in pte_alloc_one() perhaps meant to use
GFP_HIGHUSER instead? Is this perhaps some copy-paste issue?

So I *think* the removal of the 'address' use in csky should be
simple, but yes, this needs a csky maintainer to look at.

Thanks,

                Linus

Re: Linux 5.0-rc1 (test results)

[Guo Ren]

Hi Linus,
On Mon, Jan 07, 2019 at 03:21:45PM -0800, Linus Torvalds wrote:
> On Mon, Jan 7, 2019 at 11:26 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
> > argument from pte_alloc functions"). Interesting - wasn't that supposed
> > to be automatic ?
> >
> > csky does use the the removed address argument, so I won't even try to
> > provide a patch. Copying csky maintainer instead.
> 
> Hmm. Interesting. The csky code seems to have some odd "poison pte
> contents with ones if the address has the high bit set".
PTE contents is the only _PAGE_GLOBAL bit which could let mmu ignore the
ASID. One tlb entry is composed of 2 pfns and there is one GLOBAL bit in
the tlb entry. When C-SKY MMU hard-refill a tlb entry into the TLB buffer,
it will get pfn0-GLOBAL & pfn1-GLOBAL from the memory and put the result
into the TLB buffer.

If pfn0 is valid & pfn1 is invalid, we also must keep invalid pte_t with GLOBAL
bit set for C-SKY MMU.

Also see pte_clear() and pte_none() in pgtable.h.

> 
> Which makes little or no sense. The "high bit set" case is for kernel
> page tables, but that's exactly the "pte_alloc_one()" vs
> "pte_alloc_one_kernel()" distinction.
> 
> So testing the address seems entirely wrong.
Yes, testing address is no necessary, I'll remove it.

> 
> But there's other strangeness in there too. For example,
> pte_alloc_one_kernel() will just write directly to the page. And
> pte_alloc_one() will do a "kmap_atomic()" on the page it allocates,
> except since it uses GFP_KERNEL, that's entirely pointless.
> 
> Is the alloc_pages() in pte_alloc_one() perhaps meant to use
> GFP_HIGHUSER instead?
No GFP_HIGHUSER, kmap_atomic should be removed and I'll use __GFP_ZERO
instead.

> Is this perhaps some copy-paste issue?
:P

> 
> So I *think* the removal of the 'address' use in csky should be
> simple, but yes, this needs a csky maintainer to look at.
> 
Here is my new implementation:

static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
{
	pte_t *pte;
	unsigned long i;

	pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
						     ^^^^^^^^^^^^^^^^^^^
						     It's necessary ?
						     x86 & arm don't use
						     it.
	if (!pte)
		return NULL;

	for (i = 0; i < PAGE_SIZE/sizeof(pte_t); i++)
		(pte + i)->pte_low = _PAGE_GLOBAL;

	return pte;
}

static inline struct page *pte_alloc_one(struct mm_struct *mm)
{
	struct page *pte;

	pte = alloc_pages(GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_ZERO, 0);
	if (!pte)
		return NULL;

	if (!pgtable_page_ctor(pte)) {
		__free_page(pte);
		return NULL;
	}

	return pte;
}

Best Regards
 Guo Ren

Re: Linux 5.0-rc1 (test results)

[Michal Hocko]

On Tue 08-01-19 17:51:07, Guo Ren wrote:
[...]
> static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> {
> 	pte_t *pte;
> 	unsigned long i;
> 
> 	pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> 						     ^^^^^^^^^^^^^^^^^^^
> 						     It's necessary ?
> 						     x86 & arm don't use
> 						     it.
> 	if (!pte)
> 		return NULL;

That depends on whether you want OOM killer to be triggered for these
allocations. If you add the flag then the allocation bails out with a
failure rather than kill an oom victim.
-- 
Michal Hocko
SUSE Labs

Re: Linux 5.0-rc1 (test results)

[Guo Ren]

Thx Michal,

On Tue, Jan 08, 2019 at 04:40:31PM +0100, Michal Hocko wrote:
> On Tue 08-01-19 17:51:07, Guo Ren wrote:
> [...]
> > static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> > {
> > 	pte_t *pte;
> > 	unsigned long i;
> > 
> > 	pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> > 						     ^^^^^^^^^^^^^^^^^^^
> > 						     It's necessary ?
> > 						     x86 & arm don't use
> > 						     it.
> > 	if (!pte)
> > 		return NULL;
> 
> That depends on whether you want OOM killer to be triggered for these
> allocations. If you add the flag then the allocation bails out with a
> failure rather than kill an oom victim.

Yes, in page_alloc.c: 
	if (gfp_mask & __GFP_RETRY_MAYFAIL)
		goto out;
	...
	if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
            ^^^^^^^^^^^^^ OOM kill victim
	...
		if (gfp_mask & __GFP_NOFAIL)
			page = __alloc_pages_cpuset_fallback(gfp_mask, order,
					ALLOC_NO_WATERMARKS, ac);
	}

Seems it could affect the behavior of the system which is out of memory.
OOM killer could help to get_page for current. So keep the same as x86 &
arm here. I'll remove __GFP_RETRY_MAYFAIL in patch.

Best Regards
 Guo Ren

Re: Linux 5.0-rc1 (test results)

[Michal Hocko]

On Wed 09-01-19 00:16:59, Guo Ren wrote:
> Thx Michal,
> 
> On Tue, Jan 08, 2019 at 04:40:31PM +0100, Michal Hocko wrote:
> > On Tue 08-01-19 17:51:07, Guo Ren wrote:
> > [...]
> > > static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> > > {
> > > 	pte_t *pte;
> > > 	unsigned long i;
> > > 
> > > 	pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> > > 						     ^^^^^^^^^^^^^^^^^^^
> > > 						     It's necessary ?
> > > 						     x86 & arm don't use
> > > 						     it.
> > > 	if (!pte)
> > > 		return NULL;
> > 
> > That depends on whether you want OOM killer to be triggered for these
> > allocations. If you add the flag then the allocation bails out with a
> > failure rather than kill an oom victim.
> 
> Yes, in page_alloc.c: 
> 	if (gfp_mask & __GFP_RETRY_MAYFAIL)
> 		goto out;
> 	...
> 	if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
>             ^^^^^^^^^^^^^ OOM kill victim
> 	...
> 		if (gfp_mask & __GFP_NOFAIL)
> 			page = __alloc_pages_cpuset_fallback(gfp_mask, order,
> 					ALLOC_NO_WATERMARKS, ac);
> 	}

Btw. we have that nice documentation in gfp.h. I would encourage you to
read through that rather than try to imply the semantic from the
implementation.

> Seems it could affect the behavior of the system which is out of memory.
> OOM killer could help to get_page for current. So keep the same as x86 &
> arm here. I'll remove __GFP_RETRY_MAYFAIL in patch.

OK

-- 
Michal Hocko
SUSE Labs

Re: Linux 5.0-rc1

[Paul Bolle]

Linus Torvalds schreef op zo 06-01-2019 om 18:14 [-0800]:
> Nothing particular stands out, although I do like
> seeing how some ancient drivers are getting put out to pasture
> (*cought*isdn*cough*).

Just to let people know: the gigaset drivers will get my palliative care until
a few weeks before September 1, 2019. Because at that date the Dutch consumer
grade ISDN network (the "BRI" part of ISDN) will be shut down. So expect a
patch to remove me from MAINTAINERS sometime during the v5.2 cycle.

That leaves just Karsten Keil to look after all the ISDN drivers. Karsten's
last activity was in 2016. See commit 1e1589ad8b5c ("mISDN: Support DR6
indication in mISDNipac driver"). Which is also the last commit apparently
resolving an issue noticed by an actual _user_ of one of the ISDN drivers.

Perhaps Karsten could tell us whether there's any point in keeping the ISDN
subsystem in the tree after September 1, 2019, and if so, in what form. I'm in
no position to properly answer that question.


Paul Bolle

Re: Linux 5.0-rc1

[isdn]

Hi all,

Am 09.02.19 um 20:42 schrieb Paul Bolle:
> Linus Torvalds schreef op zo 06-01-2019 om 18:14 [-0800]:
>> Nothing particular stands out, although I do like
>> seeing how some ancient drivers are getting put out to pasture
>> (*cought*isdn*cough*).
> 
> Just to let people know: the gigaset drivers will get my palliative care until
> a few weeks before September 1, 2019. Because at that date the Dutch consumer
> grade ISDN network (the "BRI" part of ISDN) will be shut down. So expect a
> patch to remove me from MAINTAINERS sometime during the v5.2 cycle.
> 
> That leaves just Karsten Keil to look after all the ISDN drivers. Karsten's
> last activity was in 2016. See commit 1e1589ad8b5c ("mISDN: Support DR6
> indication in mISDNipac driver"). Which is also the last commit apparently
> resolving an issue noticed by an actual _user_ of one of the ISDN drivers.
> 
> Perhaps Karsten could tell us whether there's any point in keeping the ISDN
> subsystem in the tree after September 1, 2019, and if so, in what form. I'm in
> no position to properly answer that question.
I still follow the kernel ISDN  patches. I very glad that Paul, Kees,
David and others handle everything without the need to jump in. I still
have some ISDN equipment running behind VOIP lines.
I do not think that here are so much direct users of BRI ISDN left, I
known only very few, but here are at least some.
mISDN is still used in embedded routers to emulate the classic ISDN S0
bus to use ISDN equipment on Internet based lines and last designs for
this usage are not so long ago (less a year ago, I know from questions I
got).
But of course ISDN is in palliative care and finally removing it is
maybe not a bad idea now.

Best
Karsten

Re: Linux 5.0-rc1

[unconditionedwitness]

The copyright owner can rescind. Those saying you cannot are wrong.
Explained. In american vernacular:
Video: http://www.veoh.com/watch/v141917696RbH96XaD
        https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4
Audio: http://ufile.io/sdhpl

If you hit a video about a speedrunner: that's the wrong one.
There ain't no speed-runs through the court system.
(People been trying to give you false links, if it ain't a thug negro
rap God tellin' you the in's and outs of licensing, GPLv2, and linux:
sorry man you at the wrong address.)

Remember: If it is from the streets; you can rest easy regarding the 
veracity of the information given.