Re: armel not to be released anymore? (was: armel/marvell kernel size)

[Paul Wise]

On Wed, Mar 28, 2018 at 3:21 AM, W. Martin Borgert wrote:
> Quoting Ben Hutchings:
>>
>> Still, as armel will not be a release architecture any more, I suppose
>> it can diverge further from the normal configuration.
>
> I didn't know, that this already has been decided.
> Could you point to the emails about this? Thanks!

https://lists.debian.org/msgid-search/20180207184636.ukfil2kybr7jc...@betterave.cristau.org
https://lists.debian.org/msgid-search/20170914024001.kitowt4moob5h...@tack.einval.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[Martin Michlmayr]

* Roger Shimizu  [2018-03-26 19:36]:
> So I want to know how many active users for D-Link DNS and QNAP devices now?

I don't think there were ever many DNS-323 users.  QNAP has an active
user base but the hardware is aging, so I think they will be able to
cope without buster (especially if LTS stretch could be done for
armel).

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: armel/marvell kernel size

[Rogério Brito]

On 2018-03-27 17:29, Rick Thomas wrote:
> On Mar 27, 2018, at 1:04 PM, Rogério Brito  wrote:
>> As a related subject, I could compile a more stripped down version of
>> the armel kernel, put it for people to download and ask people to
>> comment if it works for them, so that we can gauge what people actually
>> need from such a kernel...
> 
> Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test 
> on.

You're welcome. I don't know much about the OpenRD nor about the
SheevaPlug, but are they able to run the -marvell kernels? What was the
last version of the kernel that worked for you?

What filesystems do you use? Do you use any (para)virtualization? What
about addon hardware that you have? Any USB dongles? Anything that you
can think of? Sound?

Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
loaded modules that you have with lsmod would be nice to know.

> Thanks for keeping these old boxes alive!

There's no guarantee, but I may try. Very low probability, but not zero
probability...


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: armel/marvell kernel size

[Rogério Brito]

Hi, Ben and others following the discussion.

On 2018-03-27 16:01, Ben Hutchings wrote:
> On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote:
> [...]
 I will see if all the modules make sense for an embedded system like this
 and I will send a list of options for opinions by others...
>>>
>>> [...]
>>>
>>> As I see it, the point of installing Debian on little NAS boxes is to
>>> break out of the restrictions of an embedded system.  We try to
>>> provide, so far as possible, the same features across all
>>> architectures.
>>
>> It sure makes sense to provide a lot more than some kernels, but I am
>> curious about some features that end up as modules like some
>> framebuffer like the following:
>>
>> (...)
>>
>> Is there any reason why, say, a driver for an S3 card is enabled while
>> not for a Matrox?
> 
> I don't know; that doesn't make a lot of sense.

Running make menuconfig, I can disable it without any visible loss (not
yet run it, but I don't have such hardware on my Kurobox Pro).

If the kernel were only for me, then I would simply kill it, and be done
with it, but, as I wrote to Stefan, the logical consequence would be to
enable everything that could plausibly be used... OTOH, if people
haven't noticed by this time that we need some drivers, perhaps we
shouldn't be enabling such a thing...

(Yes, I know that enabling a given driver can, say, enable some data
structure implementation from the core of the kernel and/or some crypto
algorithm, which would make the kernel potentially bigger).

> The Kirkwood SoCs have external PCIe links and some of the supported
> devices (like OpenRD) provide PCIe expansion slots, so most PCIe device
> drivers should be enabled.
> 
>> Are there real users for those? I know that, as
>> modules, they don't make the kernel bigger, but they sit there on
>> disk, doing nothing (right?).
> 
> They probably don't make a difference.

Right. I suspected this much.

> However there are some cases
> where a modular driver may require (and select) a feature that is
> always built-in.

Oh, yes this I knew.

>> Similarly for wifi cards like those Intel ones like iwlwifi (which is
>> the one that I have in this Core 2 Duo here)...
> 
> Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO

This I didn't know. :-)

>> OK, now to the real meat of my message.  Regarding shrinking the
>> kernel image, I was able to tweak things slightly (drop from 101% down
>> to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the
>> deadline IO scheduler instead of the CFQ and making as modules the
>> ones that you suggested in the original message... Is that acceptable?
> 
> I would really rather we avoided disabling AppArmor, since it is not
> only built-in but also enabled by default on all other architectures.

OK, I will reenable apparmor and see what size I get before sending patches.

> Still, as armel will not be a release architecture any more, I suppose
> it can diverge further from the normal configuration.

I saw your other email. I would like to revert this and I don't know if
(finally, after more than a decade contributing to Debian as a Debian
Maintainer) it is time to step up and become a Debian Developer and
commit to maintain some parts of the kernel...

Yes, that means that if this excursion of mine is fruitful, I will
volunteer... :-) If not, then I just get the learning experience. :-)

Actually, if I succeed, I would be interested in also working to get
powerpc revived, since I have an iBook G3, an iBook G4 and two ppc-based
kuroboxes (but one of them has only 64MB of RAM and I still have to
learn this device tree syntax)...

>> If so, then I will test them on my Kurobox Pro and report what works
>> and what breaks. I just wanted to get things smaller by tackling some
>> lower hanging fruit...
>>
>> Another point: from what I saw in the Debian scripts, not all
>> armel/marvell systems are limited to 2MB (in particular, the Kurobox
>> Pro with which I am most concerned still has 630KB of room)...
> 
> Roger has increased the size limit to 2729712 on the sid branch, which
> is the limit on the Buffalo Linkstation devices.  Check whether that
> matches the Kurobox Pro too.

I didn't know that. I guess that I cloned the repository after he made
that change... Anyway, I will check it, but the kurobox Pro is (in my
understanding) very close to a linkstation...

>> In the
>> very worst case (of course, this is not what we want), if the kernel
>> actually gets much bigger in time for the buster release, we could
>> selectively drop some systems (like what was done with the DNS323)
>> instead of dropping an entire arch... I even think that a new,
>> smaller, alternative flavor of the kernel is possible to provide to
>> support those systems that are limited to 2MB of kernel image... (I
>> can commit to support that, if my initial ideas work and people accept
>> them).
> 
> Either of those seem like reasonable options.

For the moment, I will try to work with 

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 27, 2018, at 1:04 PM, Rogério Brito  wrote:
> As a related subject, I could compile a more stripped down version of
> the armel kernel, put it for people to download and ask people to
> comment if it works for them, so that we can gauge what people actually
> need from such a kernel...

Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test on.

Thanks for keeping these old boxes alive!
Rick

Re: armel/marvell kernel size

[Rogério Brito]

Hi,Stefan.

On 2018-03-27 09:34, Stefan Monnier wrote:
>> Similarly for wifi cards like those Intel ones like iwlwifi (which is
>> the one that I have in this Core 2 Duo here)...
> 
> I can answer this part: yes, you can definitely put an Intel wifi card
> in the mini-pcie slot of an ARM box.

Yes, thanks for that hint (which Ben also replied to)...

This means that, in principle, we should enable many modules more to get
as full support as desired in Debian on each and every arch...

OTOH, if nobody has asked for that before, maybe there's nobody missing
such support (or they are compiling their own kernels).

As a related subject, I could compile a more stripped down version of
the armel kernel, put it for people to download and ask people to
comment if it works for them, so that we can gauge what people actually
need from such a kernel...


Thanks for your input,

Rogério.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

armel not to be released anymore? (was: armel/marvell kernel size)

[W. Martin Borgert]

Quoting Ben Hutchings :

Still, as armel will not be a release architecture any more, I suppose
it can diverge further from the normal configuration.


I didn't know, that this already has been decided.
Could you point to the emails about this? Thanks!

Re: armel not to be released anymore? (was: armel/marvell kernel size)

[Ben Hutchings]

On Tue, 2018-03-27 at 21:21 +0200, W. Martin Borgert wrote:
> Quoting Ben Hutchings :
> > Still, as armel will not be a release architecture any more, I
> > suppose
> > it can diverge further from the normal configuration.
> 
> I didn't know, that this already has been decided.
> Could you point to the emails about this? Thanks!

I don't know about emails, but the status page says it is not a
candidate: https://release.debian.org/buster/arch_qualify.html

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


signature.asc
Description: This is a digitally signed message part

Re: armel/marvell kernel size

[Ben Hutchings]

On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote:
[...]
> > > I will see if all the modules make sense for an embedded system like this
> > > and I will send a list of options for opinions by others...
> > 
> > [...]
> > 
> > As I see it, the point of installing Debian on little NAS boxes is to
> > break out of the restrictions of an embedded system.  We try to
> > provide, so far as possible, the same features across all
> > architectures.
> 
> It sure makes sense to provide a lot more than some kernels, but I am
> curious about some features that end up as modules like some
> framebuffer like the following:
> 
> (...)
> # CONFIG_FB_MATROX is not set
> # CONFIG_FB_RADEON is not set
> # CONFIG_FB_ATY128 is not set
> # CONFIG_FB_ATY is not set
> CONFIG_FB_S3=m
> CONFIG_FB_S3_DDC=y
> # CONFIG_FB_SAVAGE is not set
> # CONFIG_FB_SIS is not set
> # CONFIG_FB_NEOMAGIC is not set
> # CONFIG_FB_KYRO is not set
> CONFIG_FB_3DFX=m
> # CONFIG_FB_3DFX_ACCEL is not set
> CONFIG_FB_3DFX_I2C=y
> # CONFIG_FB_VOODOO1 is not set
> (...)
> 
> Is there any reason why, say, a driver for an S3 card is enabled while
> not for a Matrox?

I don't know; that doesn't make a lot of sense.

The Kirkwood SoCs have external PCIe links and some of the supported
devices (like OpenRD) provide PCIe expansion slots, so most PCIe device
drivers should be enabled.

> Are there real users for those? I know that, as
> modules, they don't make the kernel bigger, but they sit there on
> disk, doing nothing (right?).

They probably don't make a difference.  However there are some cases
where a modular driver may require (and select) a feature that is
always built-in.

> Similarly for wifi cards like those Intel ones like iwlwifi (which is
> the one that I have in this Core 2 Duo here)...

Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO

> OK, now to the real meat of my message.  Regarding shrinking the
> kernel image, I was able to tweak things slightly (drop from 101% down
> to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the
> deadline IO scheduler instead of the CFQ and making as modules the
> ones that you suggested in the original message... Is that acceptable?

I would really rather we avoided disabling AppArmor, since it is not
only built-in but also enabled by default on all other architectures. 
Still, as armel will not be a release architecture any more, I suppose
it can diverge further from the normal configuration.

> If so, then I will test them on my Kurobox Pro and report what works
> and what breaks. I just wanted to get things smaller by tackling some
> lower hanging fruit...
> 
> Another point: from what I saw in the Debian scripts, not all
> armel/marvell systems are limited to 2MB (in particular, the Kurobox
> Pro with which I am most concerned still has 630KB of room)...

Roger has increased the size limit to 2729712 on the sid branch, which
is the limit on the Buffalo Linkstation devices.  Check whether that
matches the Kurobox Pro too.

> In the
> very worst case (of course, this is not what we want), if the kernel
> actually gets much bigger in time for the buster release, we could
> selectively drop some systems (like what was done with the DNS323)
> instead of dropping an entire arch... I even think that a new,
> smaller, alternative flavor of the kernel is possible to provide to
> support those systems that are limited to 2MB of kernel image... (I
> can commit to support that, if my initial ideas work and people accept
> them).

Either of those seem like reasonable options.

Ben.

> Of course, if we could make some real magic and make our kernels much,
> much smaller to support back the DNS323, that would be amazing... :-)
> 
> I guess that I will look into those LTO patches in the future...
> 
> OK, I am sending this to see if those ideas make sense, to offer my
> help and, of course, to get some feedback.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


signature.asc
Description: This is a digitally signed message part

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

[Aaro Koskinen]

Hi,

On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote:
> 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.

Disable all other features, except what's needed for disk access and kexec
(perhaps still leave serial console :)). Then with simple scripting boot
the full featured kernel from external storage using kexec. Such minimal
kernel should be fairly stable from maintenance point of view.

A.

Re: armel/marvell kernel size

[Stefan Monnier]

> Similarly for wifi cards like those Intel ones like iwlwifi (which is
> the one that I have in this Core 2 Duo here)...

I can answer this part: yes, you can definitely put an Intel wifi card
in the mini-pcie slot of an ARM box.


Stefan