[lkml]   [2002]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Adeos nanokernel for Linux kernel
    On Wed, Jun 05, 2002 at 02:13:19PM -0500, Oliver Xymoron wrote:
    > On Wed, 5 Jun 2002, Daniel Phillips wrote:
    > > > So... an RT .mp3 player task that receives asynchronous signals from a
    > > > non-RT .mp3 player GUI front-end? So, we assume that the .mp3 data
    > > > gets sent from the non-RT file system to the RT task (via the non-RT
    > > > GUI front-end) in its entirety before it begins playing...
    > > > Other than as a play RT project, seems like a waste of effort to me..
    > > Your opinion is noted, however it's also noted that you didn't support it
    > > in any way.
    > Neither have you, at least aside from hand-waving. I've actually built a
    > bunch of systems that were originally spec'ed to be hybrids. Wouldn't be
    > surprised if Mark had too, given his Nortel address.

    I haven't actually (different side of the company). I've talked to a few
    people that have (in Nortel), and done a little research on the side.

    The biggest peave I have against RT is that people think it is the
    solution to everything. The *idea* that somebody would want an RT .mp3
    player for their designer desktop machine causes this feeling I have
    to be quite exaggerated. If I wanted to mock an RT-supporter I would
    have joked "why don't you write a .mp3 player in RT too?" and here I
    see it being presented as a valid application for RT.

    RT is definately useful. This is especially true of any sort of
    dedicated hardware that must serve data at close to full capacity with
    almost zero chance of data loss or lag. (Such as telephone switches)

    It isn't a toy. It is much harder to code an RT application, and the
    fact that hardware is running an RT application ensures that overall
    performance will suffer. The RT requirement is not a natural addition
    to an operating system such as Linux, which is why it is very
    effective to execute Linux as if it was a non-RT task.

    I like the idea of Adeos, and nanokernels. I like the idea of RT, and
    I like the fact that the Open Source community is interested in all of
    these topics. It means that solutions such as VxWorks now have real
    competition, and they will be forced to make their large price tag
    purchase real value for customers, or customers will shop elsewhere.

    Just... an .mp3 player for a desktop environment? This is a
    joke. Maybe the RTOS can perform my compiles too? That way will be
    able to accurately predict how long it will take to compile
    linux-2.4.18 each and every time. A desktop environment has very few,
    if *any* real time requirements, and those that do should be
    implemented in dedicated hardware, and not on the main
    CPU. (i.e. SCSI, hard drives, ethernet cards, ...)

    > > Also, it appears you didn't read the post you responded to. Two
    > > alternatives were presented:
    > > 1) Load the whole mp3 into memory before playing it
    > And that alternative sucks. Think scalability.

    It appears that Daniel didn't read my post that he accused me of composing
    before reading the post that he thinks I didn't read. He doesn't need to
    look far above to see (as quoted):

    > > > non-RT .mp3 player GUI front-end? So, we assume that the .mp3 data
    > > > gets sent from the non-RT file system to the RT task (via the non-RT
    > > > GUI front-end) in its entirety before it begins playing...

    "So, we assume that the .mp3 data gets sent from the non-RT file system
    to the RT task (via the non-RT GUI front-end) in its entirety before it
    begins playing..."

    To me this looks a lot like "Load the whole mp3 into memory before
    playing it", except I bothered to include vague details about how to
    accomplish this.

    The alternative still sucks, and isn't scalable (i.e. none of this
    post is a disagreement with Oliver...), but more than that, it seems
    like a horrible waste of effort except as a proof-of-concept demo like
    "Hello World!". It is a joke that shows the exact feeling that some of
    us have that people think RT solves everything in all of its glory.

    > > 2) Implement a filesystem with realtime response
    > And your shared fs alternative sucks. Think abysmal disk throughput for
    > the rest of the system. Think starvation. Think all the reasons we've been
    > trying to clean up the elevator code times ten. And that's just for the
    > device queue, never mind the deadlock avoidance problems. See "priority
    > inversion".

    Summary: Linux + RTOS should never become VxWorks.

    > > Both approaches have their uses. The second is the one I'm interested in,
    > > if that isn't already obvious. The first is just a quick hack that will
    > > give you guaranteed-skipless audio playback, something that Linux is
    > > currently unable to do.
    > Umm, neither can your CD player. But if you take the proper precautions to
    > avoid it being jostled, clean your discs, and give it decent buffering, it
    > will be more than satisfactory. Can we bring Linux up to the same
    > standard with the pre-empt and low-latency approaches? Yes. Is this a
    > better approach than grafting quixotic kernels onto the side of the box?
    > Definitely.
    > There is a place for hard realtime. But desktop MP3 playing is not it.

    In fact, if fewer people thought that RT was more than a specialized
    solution to a very specific problem domain, I wouldn't have such
    negative feelings for the people that do.

    I have a hammer in my toolbox too. That doesn't mean I use it to fix
    every thing that breaks at my house.


    -- __________________________
    . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
    |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
    | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

    One ring to rule them all, one ring to find them, one ring to bring them all
    and in the darkness bind them...

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:26    [W:0.029 / U:122.196 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site