Subject: [alpine-devel] What can we remove from our kernel?

From: Natanael Copa <[email-masked]>
Date: Mon, 23 Jan 2012 16:03:39 +0100

Hi,

I have been looking at upgrading the kernel to 3.2 and I realize that
configuring kernel is a pretty big job. I am struggling with keeping
up with all the new stuff.

This is a request for help in tuning the default kernel config.

In the beginning the strategy was "enable all as module" so users
themselves could decide what to load and not to load. After a while
that didn't really work out because kernel is getting very big (delays
kernel compile, uses diskspace in packages, iso images and on all
places alpine are installed) and there are things that does not make any
sense to include at all.

Disabling new stuff by default and only enable on request is not very
good either. It is nice to boot up alpine on some new hardware and it
just works - no need to nag developers for adding support and wait til
next release.

So I am very interested in things that we *can* disable. Things that
does not make any sense to keep in kernel anymore.

For example: Do we really need PCMCIA support nowdays?

Things to keep in mind:
* We can expect people with older hardware might want run something
  lightweight like Alpine Linux
* Networking and virtualization are some of our strong sides.
* A desktop is nice but lots of desktop things (like flash) will never
  work anyways.
* Gaming on Alpine is limited and will never be "perfect". (so I
  disabled the wii remote driver...)

So, any suggestions about what we can remove?

Thanks!

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Florian Heigl <[email-masked]>
Date: Mon, 23 Jan 2012 22:09:21 +0100

Hi,

> up with all the new stuff.

I'll try to list the kinds of odd stuff that I commonly use or
definitely know be using in advance to keep it in...
(but of course I could also be building my own kernel, it being odd stuff)

- infiniband (and mellanox drivers), rdma stuff, ipoib
- solarflare nics (don't actually have one yet)
- scst (generic scsi target)
- ceph filesystem client
- dmvpn / l2tpv3

Another idea more in the spirit of AlpineLinux might be to start by
ticking off all items that are on the Carrier Grade Linux requirements
list, as these will probably apply to many users, and then look into
what else is "nice to have".

Florian

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 24 Jan 2012 11:39:18 +0100

On Mon, 23 Jan 2012 22:09:21 +0100
Florian Heigl <[email-masked]> wrote:

> > I have been looking at upgrading the kernel to 3.2 and I realize
> > that configuring kernel is a pretty big job. I am struggling with
> > keeping up with all the new stuff.
> 

This is the kind of feedback I wanted.
 
> - infiniband (and mellanox drivers), rdma stuff, ipoib
CONFIG_RDS_RDMA is not set

Do you want me enable it?

> - solarflare nics (don't actually have one yet)

Are they enabled?

> - scst (generic scsi target)

Yes, I know there are many that use iscsi. I think we want follow
upstream and use linux-iscsi.org if possible. (meaning linux-scst goes
away in the long run)

> - dmvpn / l2tpv3

DMVPN is one of the reasons Alpine Linux exists in first place and will
not go away.

Please let me know if anything of the above is missing in current
kernel.

> what else is "nice to have".

Yes. I would need help with something like that. I think it would be
nice if we could split the kernel package in 2. -base and -extra. All
the "nice to have" things goes into extra and what the majority use is
in -base.

That'd be a start at least.

Thanks!

-nc

---

---

From: Florian Heigl <[email-masked]>
Date: Fri, 17 Feb 2012 01:37:17 +0100

I had recently written about software storage targets as one of the
odd modules i really need in-kernel, be it a module or statically
compiled. I had mentioned scst and you had pointed me at
linux-iscsi.org.
I had not checked out the link since in the total chaotic mess of
linux iscsi modules i had confused with another one.

today i happened to have a few beers with one of the heads of
risingtide. after some googling later on i finally figured out that
this is "LIO" (or, longer, LinuxIscsiOrg) which is the totally awesome
unified storage target, much like Solaris' COMSTAR) which i was after
the whole time.
So please note you already had done the completely right thing and
included the very best linux has to offer.
LIO is the only target for linux that gets all the important stuff
like error handling and reservations 100% right.

Very happy, case closed,
Florian

---

---

From: Roger Pau Monné <[email-masked]>
Date: Mon, 23 Jan 2012 16:43:22 +0100

> So, any suggestions about what we can remove?

Just a stupid thing, but most distros include the xen event channel
device as a module, Alpine instead compiles it inside the kernel, we
could set:

CONFIG_XEN_DEV_EVTCHN=m

to reduce kernel size a little bit. Apart from that I don't know, it's
been quite a lot of time since I saw a computer with PCMCIA slots, but
I guess some people still use it.

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 24 Jan 2012 11:03:34 +0100

On Mon, 23 Jan 2012 16:43:22 +0100

> device as a module, Alpine instead compiles it inside the kernel, we

This exactly the kind of feedback i wanted.

I will set it to 'm' and done the same with XENFS.

> I guess some people still use it.

Maybe we could create a pcmcia subpackage?

88.0K   ./drivers/char/pcmcia
88.0K   ./drivers/scsi/pcmcia
144.0K  ./drivers/pcmcia
44.0K   ./sound/pcmcia

Does not seem like its worth it...

Thanks!

-nc

---

---

From: Kevin Chadwick <[email-masked]>
Date: Fri, 10 Feb 2012 12:19:50 +0000

On Tue, 24 Jan 2012 11:03:34 +0100

> Does not seem like its worth it...

As you can see from the attached image

DVB takes up 5MB and the experimental staging drivers take up 27MB

You might want nouveau to work with RAWIO disabled and some of the
experimental networking drivers though.

-- 
Kc

---

From: Natanael Copa <[email-masked]>
Date: Tue, 14 Feb 2012 13:29:55 +0100

On Fri, 10 Feb 2012 12:19:50 +0000

> As you can see from the attached image

cool image!
 
> DVB takes up 5MB and the experimental staging drivers take up 27MB

We have most staging drivers disabled.
 
> experimental networking drivers though.

I don't think I will have time to test anything yet. I think we will
want something that can track the module dependencies so that the apk
deps gets right.

-nc

---

---

From: Kevin Chadwick <[email-masked]>
Date: Tue, 14 Feb 2012 13:02:43 +0000

On Tue, 14 Feb 2012 13:29:55 +0100

> > As you can see from the attached image

Konqueror's filesize view plugin.

My favourite filesize tool but getting rarer unfortunately. I don't
think it's compatible with Dolphin and on most of my systems it means
installing 100s of MB of KDE code that I don't use.

-- 
Kc

---

---

From: Kevin Chadwick <[email-masked]>
Date: Mon, 23 Jan 2012 18:05:55 +0000

On Mon, 23 Jan 2012 16:03:39 +0100
Natanael Copa wrote:

> I am struggling with keeping

Would the new LTS 3.0.x be easier or would it miss out required drivers?

I guess as you have RSBAC then you could drop RBAC, though RBAC is
easier to configure.

I wish there was a lean and secure Kernel or even Kernel config but
then I gues it wouldn't be Linux.

More code = more bugs

I just hope the build doesn't break on you. I tried tailoring it to my
machines and disabled wireless/bluetooth and knocked 10 meg off the size
but setting the cpu type and a couple of other things broke the build.
(2.6.32.49 LTS)

Is bluetooth required?

-- 
Kc

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 24 Jan 2012 10:58:07 +0100

On Mon, 23 Jan 2012 18:05:55 +0000

> Would the new LTS 3.0.x be easier or would it miss out required

Ideally we should do both and have a linux-lts-grsec kernel and a
linux-grsec kernel. I don't have resources for that currently.

I think we want the new stuff in new kernels.

> then I gues it wouldn't be Linux.

Exactly. So it would be nice with some ideas what we can do to fight
the kernel bloat.
 
> machines and disabled wireless/bluetooth and knocked 10 meg off the
> size but setting the cpu type and a couple of other things broke the
> build. (2.6.32.49 LTS)
> 
> Is bluetooth required?

This is exactly the kind of question I want help to come up with.

I use bluetooth on my laptop.

Maybe we could have a linux-grsec-bluetooth subpackage with the
bluetooth stuff? How do we create such a subpackage? Can we split by a
dir? There are 2 directories named bluetooth:

$ du -sh drivers/bluetooth net/bluetooth/
172.0K  drivers/bluetooth
316.0K  net/bluetooth

Is that worth a subpackage? probably not.

$ du -sh net/wireless/ drivers/net/wireless/
220.0K  net/wireless/
5.0M    drivers/net/wireless/

This might be worth a subpackage and we could probably stuff in
bluetooth in there as well.

Thanks!

-nc

---

---

From: qnx4ever <[email-masked]>
Date: Tue, 24 Jan 2012 00:45:39 +0400

Just to not make your life easier, it would be great if we can keep
few versions of kernel. I suppose there could be a stripped down
version to be used in the headless servers, routers and NAS devices
without Sound, Video, etc. I believe we still need a "full" loaded
kernel with all devices and yes PCMCIA is needed for older laptops.
Are we running out of CPU on the server to compile packages ?

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 24 Jan 2012 11:25:46 +0100

On Tue, 24 Jan 2012 00:45:39 +0400
qnx4ever <[email-masked]> wrote:

> without Sound, Video, etc.

That would be ideal yes. With different config depending on the task.
It would be nice with a non-smp and/or lowmem config, and a PAE config
etc.

Unfortunally, that adds pretty much workload on maintenance, so that
will not be possible.

Maybe we could have the x86 as lowmem no-smp? If you have multicore
you'd need the x86_64 kernel? Are there many x86-only multicore cpus?

> I believe we still need a "full" loaded

Yes. I think we want split the kernel package into a few smaller ones.
Sound is a good example. The top-level sound/ directory is 7MB. If you
have a NAS you don't need the sound so it would be nice to be able opt
that out.

However, we don't want many of those subpackages and we want some clean
way to create them. We don't want keep a list of modules that needs to
be maintained manually. We don't want users need search though 20
packages to find the driver for his hardware.

~5 kernel packages would be nice. For example:

-base:      the kernel itself + basic libs and drivers
-virtual:   all modules that has to do with virtualization
-sound:     sound supporrt
-wireless:  wifi, irda, bluetooth wimax etc drivers
-media:     dvb, webcam drivers, radio drivers etc
-telephony: ISDN drivers, SIP support etc.
-extra:     the rest

So if you install a vitual guest, all you'll need would be in -virtual
(which pulls in -base as a dependency). I think Suse has something like
base and extra. If its a virtual machine you only need the -base
package.

The biggest challenge is: how do we split it so its easy for end users
and easy to maintain?

For compatibility (and for people who can accept bloat for getting
"just works") we can let the linux-grsec package pull in them all, like
it is today.

When I think of it, it would be nice with only 2 packages: base and
extra.

> Are we running out of CPU on the server to compile packages ?

No. There are lots of things the kernel support that I don't even know
what is. I just want help in deciding what we can strip out of the
kernel to fight the bloat. I don't want keep things we won't ever use.

-nc

---