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

On 13 Oct 2006 21:56:07 -0700 440gtx@xxxxxxxxx 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@xxxxxxxx |
|------------------------------------/-------------------------------------|
.