[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: D-Link DNS-323 support dropped in Debian stretch



Hello,

On 2018-03-26 11:36, Roger Shimizu wrote:
[ loop debian-kernel ML ]

On Mon, Mar 26, 2018 at 7:05 PM, Martin Michlmayr <tbm@cyrius.com> wrote:
* basti <mailinglist@unix-solution.de> [2018-03-26 12:00]:
Can it be an option to run Stretch with older Kernel from jessie?

I don't know.

And can you please explain why it is dropped, I see that qnap TS-x09 is
still supported.

DNS-323 only has 1.5 MB space for the kernel.  TS-x09 has 2 MB.  We're
constantly pushing against these limits.  1.5 MB wasn't doable in
stretch and 2 MB is no longer doable in buster.

I think with a small amount of effort it can be done.

armel support for sid kernel was (temporally) disabled last month, due
to over size (>2MB).
I just added armel back last weekend by extend the limit from 2MB to
2.7MB, which means it drops support for qnap.

I'm pleased it has returned because I have two Dreamplugs and they load
the kernel from SD and there is no 2MB limitation.  I am using Stock
Debian with a stock kernel and stock u-boot, which I am very pleased about.

There's one possibility that can bring back qnap, or even D-Link DNS device:
- create a new flavour for armel, such as armel-none-mini
- the new flavour will disable many features that other common kernels
have, such as wireless, crypto, etc.

I certainly think that if people are using Debian successfully then some
effort should be expended to continue support if the hardware still works.

I've done this before and these custom kernels tend to be quite tailored
to the device, which may result in quite a few variants. Is that possible?

The question is whether it deserves the effort, not only creating the
new flavour, but also maintaining it during the whole buster period.
So I want to know how many active users for D-Link DNS and QNAP devices now?

Here is a patch that will reduce the size of the kernel a bit and doesn't (in my opinion) make the kernel any less useable (or less "Debian"). I'm not aware of any Marvell devices that would need VT support, is that correct?

-rw-r--r-- 1 leigh leigh 1986320 Mar 23 12:10 vmlinuz-4.16.0-rc6-marvell

Regards,

Leigh.
--

diff --git a/debian/config/armel/config.marvell b/debian/config/armel/config.marvell
index c5703aeeb..7235cb767 100644
--- a/debian/config/armel/config.marvell
+++ b/debian/config/armel/config.marvell
@@ -121,6 +121,7 @@ CONFIG_SUN_PARTITION=y
 ##
 # CONFIG_CRYPTO_FIPS is not set
 CONFIG_CRYPTO_SHA256=m
+CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y

 ##
 ## file: drivers/ata/Kconfig
@@ -633,6 +634,11 @@ CONFIG_FB_XGI=m
 ##
 CONFIG_THERMAL=m
 CONFIG_KIRKWOOD_THERMAL=m
+#
+##
+## file: drivers/tty/Kconfig
+##
+# CONFIG_VT is not set

 ##
 ## file: drivers/tty/serial/8250/Kconfig
@@ -754,6 +760,8 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 ## file: lib/Kconfig.debug
 ##
 # CONFIG_SCHEDSTATS is not set
+# CONFIG_CRC32_SLICEBY8 is not set
+CONFIG_CRC32_SLICEBY4=y

 ##
 ## file: mm/Kconfig


Reply to: