On Thu, Mar 6, 2014 at 1:45 AM, Kevin Fenzi wrote:
> On Wed, 05 Mar 2014 17:37:42 +0100
> Reindl Harald wrote:
>> in general you need to multiply the wasted space for each instance
Exactly, you usually have hundreds or even thousands of instances
running. Sure, "every MB counts" isn't to be take
On Thu, Mar 6, 2014 at 12:13 AM, Don Zickus wrote:
> On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
>> On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus wrote:
>> > On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
>> > For example, lets start with 100MB package requireme
On Thu, Mar 6, 2014 at 12:08 AM, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann wrote:
>>
>> Hi,
>>
>>> I'm not overly thrilled with having multi-tiered driver packages.
>>> That leads to major headaches when we start shuffling things around
>>> from one driver package to ano
On Wed, Mar 5, 2014 at 3:14 PM, Peter Robinson wrote:
It's generally useful. On other architectures the UDC capable hardware
might
not be very common, but the dummy HCD makes it possible to use such
hardware
for development and emulation of USB gadget driver code.
>>>
>>
>>> It's generally useful. On other architectures the UDC capable hardware might
>>> not be very common, but the dummy HCD makes it possible to use such hardware
>>> for development and emulation of USB gadget driver code.
>>
>> ACK from me
>
> I'm not at all sold on this to be honest. Coverity ju
On Wed, Mar 05, 2014 at 10:08:04AM -0500, Josh Boyer wrote:
> > Depends on what is targeted. Strictly cloud? Or also someone running
> > Fedora as a guest in virt-manager / boxes?
> I'm of the opinion the latter is probably what we should shoot for.
> It's going to be the broadest target that is
On Wed, Mar 05, 2014 at 11:33:57AM -0600, Justin M. Forbes wrote:
> On Wed, 2014-03-05 at 10:59 -0500, Josh Boyer wrote:
> > On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III wrote:
> > > On Wed, Mar 05, 2014 at 10:08:04 -0500,
> > > Josh Boyer wrote:
> > >>
> > >>
> > >> So you agree multi-tier
On Wed, 2014-03-05 at 10:59 -0500, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III wrote:
> > On Wed, Mar 05, 2014 at 10:08:04 -0500,
> > Josh Boyer wrote:
> >>
> >>
> >> So you agree multi-tiered subpackages is a bad idea, but then you
> >> propose a netfilter specific sub
Am 05.03.2014 17:45, schrieb Kevin Fenzi:
> On Wed, 05 Mar 2014 17:37:42 +0100
> Reindl Harald wrote:
>
>> Am 05.03.2014 17:28, schrieb Kevin Fenzi:
>>> On Wed, 5 Mar 2014 10:16:21 -0500
>>> Don Zickus wrote:
>>>
Also, I just arbitrarly threw out 100MB, if we should start
higher, say
On Wed, 05 Mar 2014 17:37:42 +0100
Reindl Harald wrote:
>
>
> Am 05.03.2014 17:28, schrieb Kevin Fenzi:
> > On Wed, 5 Mar 2014 10:16:21 -0500
> > Don Zickus wrote:
> >
> >> Also, I just arbitrarly threw out 100MB, if we should start
> >> higher, say 150MB, then it doesn't matter to me. :-)
>
Am 05.03.2014 17:28, schrieb Kevin Fenzi:
> On Wed, 5 Mar 2014 10:16:21 -0500
> Don Zickus wrote:
>
>> Also, I just arbitrarly threw out 100MB, if we should start higher,
>> say 150MB, then it doesn't matter to me. :-)
>
> This entire disk size optimization seems kind of weird to me.
in cas
On Wed, Mar 05, 2014 at 09:28:45AM -0700, Kevin Fenzi wrote:
> On Wed, 5 Mar 2014 10:16:21 -0500
> Don Zickus wrote:
>
> > Also, I just arbitrarly threw out 100MB, if we should start higher,
> > say 150MB, then it doesn't matter to me. :-)
>
> This entire disk size optimization seems kind of we
On Wed, 5 Mar 2014 10:16:21 -0500
Don Zickus wrote:
> Also, I just arbitrarly threw out 100MB, if we should start higher,
> say 150MB, then it doesn't matter to me. :-)
This entire disk size optimization seems kind of weird to me.
I just booted a f20 offiical cloud image in our openstack clou
On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus wrote:
> > On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> > For example, lets start with 100MB package requirement for the kernel (and
> > say 2 GB for userspace). This
On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III wrote:
> On Wed, Mar 05, 2014 at 10:08:04 -0500,
> Josh Boyer wrote:
>>
>>
>> So you agree multi-tiered subpackages is a bad idea, but then you
>> propose a netfilter specific subpackage? ... Probably not. They'll
>> likely just be in kernel-co
On Wed, Mar 05, 2014 at 10:08:04 -0500,
Josh Boyer wrote:
So you agree multi-tiered subpackages is a bad idea, but then you
propose a netfilter specific subpackage? ... Probably not. They'll
likely just be in kernel-core.
Couldn't the planned module provides allow something like this to w
Hi,
> > Agree, I don't think it makes much sense to split things into many small
> > pieces.
> >
> >> - Do you need/want a firewall (requires iptables, etc)?
> >
> > I'd say yes by default, but being able to remove it might be useful
> > (kernel-netfilter subpackage)?
>
> So you agree multi-tie
Am 05.03.2014 16:02, schrieb Josh Boyer:
> FWIW, the existing kernel package installed today (a debug kernel
> even) is ~142 MB. 123MB of that is the /lib/modules content. ~6MB of
> that is vmlinuz. The remaining 13MB is the initramfs, which is
> actually something that composes on the system du
On Wed, Mar 5, 2014 at 4:49 AM, Peter Robinson wrote:
> On Wed, Mar 5, 2014 at 9:37 AM, Lubomir Rintel wrote:
>> It's generally useful. On other architectures the UDC capable hardware might
>> not be very common, but the dummy HCD makes it possible to use such hardware
>> for development and emul
On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus wrote:
> > On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> > For example, lets start with 100MB package requirement for the kernel (and
> > say 2 GB for userspace). This
On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann wrote:
>
> Hi,
>
>> I'm not overly thrilled with having multi-tiered driver packages.
>> That leads to major headaches when we start shuffling things around
>> from one driver package to another. The current solution I have
>> prototyped is a kernel
On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus wrote:
> On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> For example, lets start with 100MB package requirement for the kernel (and
> say 2 GB for userspace). This way the kernel team can implement
> reasonable changes and monitor
Hi,
> I'm not overly thrilled with having multi-tiered driver packages.
> That leads to major headaches when we start shuffling things around
> from one driver package to another. The current solution I have
> prototyped is a kernel-core/kernel-drivers split. Here "core" could
> be analogous
On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> > Some drivers are built inside the kernel (for various reasons) so if
> > we keep them in they can't really be modular.
>
> If there are reasons they are built-in (and I think currently nothing
> is being built-in without good
On Wed, Mar 5, 2014 at 2:48 AM, Sandro "red" Mathys
wrote:
> So, in our case hardware drivers are rather unnecessary and the kernel
> experts might know other ways to shrink the footprint for our limited
> use cases. The kernel we require supports all primary architectures
> (i686 and x86_64 right
On Wed, Mar 5, 2014 at 6:58 PM, drago01 wrote:
> On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys
> wrote:
>> Heads-up: I've taken ownership over the Cloud SIG's planned
>> "Cloud-Friendly Kernel Packaging" (aka "Modular Kernel Packaging for
>> Cloud") Change [0].
>>
>> (Sorry for cross-postin
On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys
wrote:
> Heads-up: I've taken ownership over the Cloud SIG's planned
> "Cloud-Friendly Kernel Packaging" (aka "Modular Kernel Packaging for
> Cloud") Change [0].
>
> (Sorry for cross-posting this on the kernel and cloud lists, but both
> the kern
On Wed, Mar 5, 2014 at 9:37 AM, Lubomir Rintel wrote:
> It's generally useful. On other architectures the UDC capable hardware might
> not be very common, but the dummy HCD makes it possible to use such hardware
> for development and emulation of USB gadget driver code.
ACK from me
> ---
> Chang
It's generally useful. On other architectures the UDC capable hardware might
not be very common, but the dummy HCD makes it possible to use such hardware
for development and emulation of USB gadget driver code.
---
Changes since v2:
* Rebased on v3.14-rc4-45-gd2a0476 (fedora package git: 2323b027
29 matches
Mail list logo
