On Mon, 23 Oct 2000, Dennis wrote:
> >
> >o What used to take a month to get working in SunOS, will
> >take a few hours on Linux. Linux has continually improved the
> >resources available to the modules. In the beginning there was
> >a kernel memory allocator. Now we have common resource allocation
> >code for I/O addresses like PCI, common interrupt handlers, common
> >sleep and wake-up routines, etc. Basically, the best ideas of
> >all the driver contributors have been adapted into a kernel-driver
> >interface so that every compliant module gets to share the best
> >code available.
>
> As long as your modules are trivial, you are correct. I agree that writing
> a basic module is fairly easy, and debugging is easy (although if they
> fixed the printk interface it would be easier), but.....
>
Some of the stuff we do is hardly trivial. Could you explan what you
have found wrong with printk()? I have never had any problem with it.
If you are referring to the limited-size buffering of the output, this
is not something that requires a "fix". It is deliberate so that even
and out-of-memory situation can be displayed. Printk()'s buffer is
allocated once and is fixed-length. If you use printk for what it
is supposed to be used for, you will never have any problems.
There are other ways than printk() to write output to the current
task's output. printk() is most useful where there isn't a well-
defined 'current'.
static void print_string(char *str)
{
struct tty_struct *tty = current->tty;
(*tty->driver.write)(tty, 0, str, strlen(str));
(*tty->driver.write)(tty, 0, "\r\n", 2);
}
> "compliance" is difficult without good documentation,and unfortunately most
> of the docs for the linux kernel are in Alan Cox's head (and the like).
> Virtually all books are out of date by the time they hit the shelves (the
> linux "device driver" book had many errors and omissions and proved more
> detrimental than useful). Most of the how-tos are out of date. This,
> understandable, is what you get for free.
>
> Also, the definition of "compliant" keeps changing. the difference between
> a real commercial OS and linux is that linux is a moving target.
>
Look, if you are doing product development, it's counter-productive to
use a __development__ kernel. You can spend too much time keeping up
with the changes. Instead, just like you should never change your tools
during a product design cycle, you should not change the effective
kernel you use.
The "stable" kernel, i.e., 2.2.5 -> 2.2.17 has been kept up-to-date
as far as bug fixes are concerned. My drivers work fine in this
series.
At some later date, when the current development kernel becomes
the "stable" kernel, I will make whatever changes are necessary to
my (at last count) 12 drivers so they work in the new kernel.
This is something that will happen during the normal product lifetime,
not before the products are being shipped.
> While they might brag about LINUX being "fast moving", it is also the main
> reason that it is continuously unstable and the hopes of true stability
> any time soon is questionable. Until they stop hacking core elements and
> redesigning interfaces on the fly there will be no change. Just lots of new
> features that almost work as long as you use them in a particular way.
>
> theres a lot to be said for doing something right the first time and
> sticking with it even if it isnt perfect. Unfortunately many of the
> original linux designs were so poorly thought out that they need to be
> completely redesigned.
>
Not true. You can't have reviewed or understand any of the kernel code if
you believe this. All major elements are modular. When somebody comes
up with better memory management, it's encorporated, better scheduling,
it's encorporated, etc. This is what development kernels are for.
Bugs that were found when changing the design of various kernel
procedures, have been back-ported to the stable kernel series.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST