Nobody should ever need to patch the kernel!! - Linux

This is a discussion on Nobody should ever need to patch the kernel!! - Linux ; angryatlinux wrote: > Nikolaos D. Bougalis wrote: >>> You cannot enable ACPI without a patch (ok I think now it made into >>> the kernel, but it used to need a patch) >> >> ACPI support required a patch because ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: Nobody should ever need to patch the kernel!!

  1. Re: Nobody should ever need to patch the kernel!!

    angryatlinux wrote:
    > Nikolaos D. Bougalis wrote:
    >>> You cannot enable ACPI without a patch (ok I think now it made into
    >>> the kernel, but it used to need a patch)

    >>
    >> ACPI support required a patch because it was not included in
    >> mainline, until the developers decided it was stable enough to
    >> include. That makes a lot of sense to me. What would you have done, if
    >> it were up to you? Merge it right away, and crash thousands of systems
    >> because of broken ACPI support?

    >
    > Various people replied this thing about ACPI. These people haven't
    > understood what I'm writing! I'm not complaining because there are
    > things available as patch vs directly in the kernel, I'm complaining
    > because there are things available in patches vs in modules!


    And you're missing the point. Somethings just touch entirely too many parts
    of the kernel and cannot be distributed as modules. A good non-ACPI example of
    that fact is SELinux: parts of it simply could not be modularized, and had to
    be distributed as a patch that you applied against your kernel tree.


    > ACPI is one example, Kprobes is another one... ok I was mistaken with
    > the file monitoring and shfs.


    Kprobes, like SELinux, is so "invasive" that distributing it as .c files that
    are compiled into module(s) is simply not feasible. Not to mention that it has
    been in mainline since (off the top of my head) 2.6.8.


    > Patches are a hell to maintain, see my first post for why, useless to
    > repeat here.


    Which is why most patches that offer functionality that will be of use to
    more than one person and have a prospect of an active maintainer do,
    eventually, get rolled into mainline, after any issues with them are resolved.

    -n



  2. Re: Nobody should ever need to patch the kernel!!

    On 13 Oct 2006 21:56:07 -0700 440gtx@email.com wrote:

    | FYI, the DDK has been free for about 5 years. Heck, there is even a
    | free version of visual studio these days. Logo for applications and
    | signing of drivers remains optional to this day. However Vista will
    | have strict signing requirements for x64 drivers. Microsoft believes
    | this will make it more stable and secure, we'll see. But up to now it's
    | been easy to ship drivers, just press the build button and you've got a
    | binary you can give to customers with no required costs or other
    | overhead.

    And you can skip that step with Linux. Just distribute the patch.


    |> So until you do come up with some examples, even hypothetical ones,
    |> I'm just chalking up the above as "blowing more smoke".
    |
    | Ok, let's get to a real example. How about tracing and bus analysis
    | tools? Is that specific enough? There are many productivity products on
    | Windows that log software packets and hardware protocol that are
    | invaluable to firmware and device guys. For linux, people are limited
    | to attaching black boxes to their buses which come with significant
    | tradeoffs, many of them negative. Think of strace, but for low kernel
    | level data structures like block device requests or SCSI protocol. It
    | is not clear to me a module has any way to attach so that it could
    | capture these type things. On the other hand, roll back 10 years and
    | even windows and os/2 already had the concept of filter drivers.

    Windows has that many hooks all over the place? My gawd, no wonder it's
    as secure as swiss cheese.

    If Linux had the ability for a module to do all that, I'd switch to BSD.

    FYI, I deconfigure the ability to even load any module at all from my
    Linux kernels.


    |> It's the wrong way to go about it. There are numerous different operating
    |> systems. But the manufacturer clearly didn't want to make a driver for all
    |> of them. The reason had nothing to do with kernel versions in Linux.
    |
    | Ah, I see you are referring to the proprietary nature of the hardware
    | interface and concur that's typically a bad idea in the long run. As a
    | side note, as someone who accidentally owned a WinModem for a time, it
    | was about the worst hardware experience I have had. The driver had the
    | most horrible side effects on the system. It was very poorly written
    | and the developer should have been shot.

    So I guess we are in agreement that all classes of hardware should have
    universal and open interfaces, and all the priorietary addons should be
    done either in the hardware, or where appropriate, in the application
    running in userland (for specialized hardware that only has some meaning
    to specialized applications).

    But I cannot agree with having a zillion kernel hooks to do software tool
    stuff like tracing the activity on a PCI bus. In such cases, the tool
    can even impact the problem being monitored, such as affecting timing
    issues. The correct way to do that is by using a hardware probe device
    and a second computer to gather and analyze the data via a connection
    between that second computer and the hardware doing the monitoring in the
    first computer.

    I certainly can understand some needs to track what is going on in the
    system. For example, I'd like to have the ability to record all the swap
    events by Firefox to help show that it is way over bloated. Two of my
    computers that get heavily used with less than optimal RAM (because Intel
    didn't want to support more than 512MB in that chipset) end up swapping a
    lot of applications completely out. When things do need to run, swapping
    back in is fairly quick for all ... but ... Firefox, which can at times
    take as long as 2 MINUTES to get swapped back in. Bloat, bloat, bloat.

    But I'm not wanting such a tool as a module. I'll patch and compile.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-10-14-1106@ipal.net |
    |------------------------------------/-------------------------------------|

  3. Re: Nobody should ever need to patch the kernel!!

    440gtx@email.com wrote:
    > It is strange to me because layered drivers have been essential in
    > other operating systems for the last 20 years or so. Even Dos was
    > actually nice in that regard and everyone had their favorite cool
    > tsr's.


    Most computer people who are old enough to remember TSR's do not care
    to remember, let alone discuss them. This is even more pathetic than
    harping about some old girlfriend that left you 20 years ago.

    For the benefits of the younger newsgroup readers, TSR's were
    interrupt-time hacks which rudely patched themselves into the interrupt
    vector (due to the system having no security whasoever) and peeked at
    undocumented memory locations in DOS to determine whether it was safe
    to call into it from interrupt time. They were not "layered drivers",
    nor anything "in that regard", and were far from "cool". Stupid, more
    like. I used DOS, but didn't run a single TSR, ever. Nobody in their
    right mind ran these programs, which compromised whatever stability the
    system might have had. TSR's were so flaky that the order in which they
    were loaded affected stability due to "conflicts".

    The TSR technique was widely used by virus writers; quite likely, the
    majority of TSR's were in fact viruses rather than useful programs. A
    virus, embedded into an infected executable, might install a part of
    itself in memory which would stay there after the termination of that
    host program, triggered by interrupts or possibly other operating
    system dispatch hooks.

    > The linux model really strangles creative products.


    Take it to comp.os.*.advocacy, and take that "angryatlinux" dummy with
    you.

    Linux has nothing to do with why your lives turned out the way they
    have.

    If you don't like how it works, don't use it. It's still possible to
    ignore Linux, and make a living doing something in computing, even
    software development. That is, if you actually have real skills outside
    of trolling.

    Linux has never needed washed-up, wannabe kooks who can't fit into the
    computing sphere, though it has attracted them en masse. They typically
    become pissed off and bitter when the openness of Linux doesn't
    magically fix their career problems.


  4. Re: Nobody should ever need to patch the kernel!!

    Kaz Kylheku wrote:
    > Most computer people who are old enough to remember TSR's do not care
    > to remember, let alone discuss them. This is even more pathetic than
    > harping about some old girlfriend that left you 20 years ago.


    > Linux has never needed washed-up, wannabe kooks who can't fit into the
    > computing sphere, though it has attracted them en masse. They typically
    > become pissed off and bitter when the openness of Linux doesn't
    > magically fix their career problems.


    So who is the troll here?

  5. Re: Nobody should ever need to patch the kernel!!

    "Kaz Kylheku" writes:
    > 440gtx@email.com wrote:
    >> It is strange to me because layered drivers have been essential in
    >> other operating systems for the last 20 years or so. Even Dos was
    >> actually nice in that regard and everyone had their favorite cool
    >> tsr's.


    [...]

    > For the benefits of the younger newsgroup readers, TSR's were
    > interrupt-time hacks which rudely patched themselves into the interrupt
    > vector (due to the system having no security whasoever) and peeked at
    > undocumented memory locations in DOS to determine whether it was safe
    > to call into it from interrupt time.


    'TSR' (terminate but stay resident) whas the name of a DOS entry point
    that passed control back to the shell from an executing program
    without marking all of its memory ressources as 'free to be re-used'.
    This was the only way an application could other services to other
    applications in DOS (like the 'print' command, which implemented
    background printing or emm386.exe for access to EMS/ XMS).

    > They were not "layered drivers", nor anything "in that regard",


    What the entity calling itself 'angryatlinux' probably refered to
    was technique used to have multiple TSR hooked into the keyboard
    interrupt to act upon pressing of a 'hotkey', namely, to store the old
    interrupt handler address and to jump to that location if the key that
    had been pressed was not the one the current program was supposed to
    act upon.

    > I used DOS, but didn't run a single TSR, ever. Nobody in their
    > right mind ran these programs, which compromised whatever stability the
    > system might have had.


    On a single-taskin system, a program loaded into memory which does not
    do anything, due to not being active, cannot 'compromise' anyhting,
    either. It's just data.

    BTW, I just turned 34, which, by current standards, is not
    particularly old. What's the age of the audience you are addressing?
    Five?

  6. Re: Nobody should ever need to patch the kernel!!

    angryatlinux wrote:
    > So who is the troll here?


    One way we could answer that question might be to look at posting
    histories. Your throwaway account appears to have no Usenet posting
    history other than this thread, which is off-topic in this newsgroup.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2