RE: RT patch acceptance

From: Zwane Mwaikambo (zwane_at_arm.linux.org.uk)
Date: 05/30/05

  • Next message: Valdis.Kletnieks_at_vt.edu: "Re: 2.6.12-rc5-mm1 - missing #define SECTIONS_SHIFT in sparsemem"
    Date:	Mon, 30 May 2005 10:33:14 -0600 (MDT)
    To: kus Kusche Klaus <kus@keba.com>
    
    

    On Mon, 30 May 2005, kus Kusche Klaus wrote:

    > I didn't state that a hard-RT linux is simpler, technically
    > (however, personally, I believe that once RT linux is there, *our*
    > job of writing RT applications, device drivers, ... will be simpler
    > compared to a nanokernel approach).

    I can't quite see how, in my experience they involve the same
    effort, but i guess that's personal opinion.

    > I just stated that for the management, with its limited interest and
    > understanding of deep technical details (and, in our case, with bad
    > experiences with RT plus non-RT OS solutions), a one-system solution
    > *sounds* much simpler, easier to understand, and easier to manage.
    >
    > Decisions in companies aren't based on purely technical facts,
    > sometimes not even on rational arguments...

    But decisions for the Linux kernel must always be rational and technical.
    Regarding ease of maintenance, debugging/maintaining an application on a
    nanokernel (ie isolated) is a lot easier than something as large and
    complex as the Linux kernel. This also applies for QA and general
    verification.

    > And concerning support:
    >
    > * If we go the "pure linux" way, we may (or may not) get help from
    > the community for our problems (it did work quite well up to now),
    > or we could buy commercial linux support.

    Considering how controlling your management is, i'm surprised you'd stake
    your business on something as non deterministic as the Linux kernel
    mailing list.

    > * If we go the "nanokernel plus guest linux" way, we will not get
    > support from the nanokernel company for general linux kernel issues,

    I find that hard to believe literally any company which sells you
    operating system software will be more than willing to provide you support
    for the supplied components, obviously at a price but they are after all
    in the business of making money.

    > the community help will also be close to zero, because we no
    > longer have a pure linux system, and the community is not able to
    > reproduce and analyze our problems any longer (in the same way lkml
    > is rather unable to help on vendor linux kernels or on tainted
    > kernels), and the same holds for most companies offering commercial
    > linux support.

    A volunteer supported public forum as a means of handling technical issues
    for a company doesn't sound like a good idea.

    > Hence, w.r.t. support, the nanokernel approach looks much worse.

    I can't quite see how you drew that conclusion. The fact is, pay someone
    and they'll resolve your problems.

    Regards,
            Zwane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Valdis.Kletnieks_at_vt.edu: "Re: 2.6.12-rc5-mm1 - missing #define SECTIONS_SHIFT in sparsemem"

    Relevant Pages

    • [patch 17/18] m68k: Update defconfigs
      ... # Automatically generated make config: don't edit ... -# Linux kernel version: 2.6.25-rc8 ... -# Other IDE chipsets support ...
      (Linux-Kernel)
    • Re: [BUG] soft lockup detected with ipcs
      ... I'm striping down the config to hopefully find out the cause... ... # Linux kernel version: 2.6.24.3 ... # Device Drivers ... # PCI IDE chipsets support ...
      (Linux-Kernel)
    • 2.6.22-git10 compile error
      ... Just for the record - linux kernel version 2.6.22-git10 fails to build ... Plamen Petrov, network administrator ... # Firmware Drivers ... # ACPI Support ...
      (Linux-Kernel)
    • EIP is at device_shutdown+0x32/0x60
      ... .config one of them: ... # Linux kernel version: 2.6.24-rc2-mm1 ... # SCSI support type ... # Input Device Drivers ...
      (Linux-Kernel)
    • [PATCH 11/20] Blackfin arch: update defconfigs
      ... -# Linux kernel version: 2.6.19.3 ... +# Infrared-port device drivers ... +# Old Serial dongle support ...
      (Linux-Kernel)