Workstation product kernel requirements

[Josh Boyer]

On Tue, Nov 5, 2013 at 5:31 PM, Bastien Nocera <bnocera at redhat.com> wrote:
> ----- Original Message -----
>> Hi All,
>>
>> My apologies for sending this out so late compared to the other
>> product queries.  I will simply claim that I hope the current Fedora
>> kernel is already meeting desktop/workstation needs and my delay was
>> partially because of that ;).
>>
>> At any rate, the kernel team would like to know what you see as the
>> requirements for the Workstation product.  Thus far the discussions
>> with the other product groups has mostly centered around packaging
>> changes.  I would imagine Workstation doesn't particularly suffer from
>> anything in the current packaging, and could likely share a common
>> packaging scheme with Server for the most part.  However, if that
>> isn't the case please let us know what you'd like to see from a
>> packaging standpoint, keeping in mind we want a single main kernel
>> package across all 3 products as much as possible.
>>
>> On IRC, Matthias mentioned some issues around interactivity and I/O.
>> If there are other things like that, please speak to those as well.
>
> Is this supposed to be a wishlist, or a list of things that should carry

No, not really a wish list.  That being said, creating a wishlist
isn't a bad idea.

> on working/possible release blockers?

Mostly I'm curious what you find lacking.  I'm not going to say we
personally are going to fix it with the bug backlog we already have,
but it's good to be aware of areas that could use change/improvement.

>
> For the former, on top of my head:
> - Production-ready btrfs with the ability to export those snapshots over
>   the network (I've asked about this before, got no answer)
> or,

Yes, well, the world continues to wait for btrfs in general.  Wish
list item indeed.

> - directory hard link support for ext4 (probably hidden behind a mount option
>   with warnings and bells)
> - "time" changes up the directory chain when something changes (eg. if something
>   changes in /foo/bar/baz, a timestamp on /foo will be changed)
> - Export of "wake reason" when the system wakes up (rtc alarm, lid open, etc.)
>
> These would probably be necessary to implement a highly integrated backup system.

Is there a reason thin dm provisioning isn't suitable here?  I've only
tangentially paid attention to it, but I thought snapshots and backups
were one of the motivating factors for pushing that in Fedora.

> - User-space helper for the OOM killer (http://lwn.net/Articles/552789/)

Will review.

> - Whatever is necessary to implement "LinuxApps" containers (overlayfs would be
>   nice for example: http://lwn.net/Articles/542707/)

overlayfs is something multiple people want, yeah.

> - an hibernation implementation that doesn't use the swap space (interactivity
>   sucking when there's a run-away process, or hibernation? choose...)

Please don't make us look at hibernate.  We cry.

> - memory compression enabled by default on certain classes of hardware (fast enough CPU)

For what purpose?  Also, this is definitely magical wishlist right now.

> - better documentation for waking up machines via USB (how do I wake up a machine
>   using a Bluetooth keyboard? How can I keep a USB socket powered to charge a device, etc.)

OK.  Though bluetooth would probably have to stop crashing every time
a device disconnected unexpectedly first...

> - USB "Gadget" support (using a machine as a WWAN modem, MTP device, or hard disk) for
>   another machine.

For what use case?

> That's a first pass, and more than enough to keep the kernel guys busy for a little while :)

OK, so those are all good things (well, maybe not all of them..), but
they're definitely more upstream issues.  Not everyone is aware of
this, but "Fedora kernel maintainer" usually doesn't translate to
"work on upstream kernel features".  In fact, days where I get to
write a patch for _anything_ are happy days.  Most of our time is
spent on bug fixing, triage, testing, etc.

As I said above though, it's good for us to be aware of these things.
We can keep an eye on them, and talk to the relevant upstreams as they
get developed.  I just don't want anyone to get the impression that
we're going to solve anything rapidly.

josh